Original Article

Proc IMechE Part C:

J Mechanical Engineering Science
A state–behavior–function model 2019, Vol. 233(7) 2302–2317
! IMechE 2018

for functional modeling of Article reuse guidelines:

sagepub.com/journals-permissions

multi-state systems DOI: 10.1177/0954406218791640

journals.sagepub.com/home/pic

Meng Zhao1 , Yong Chen2, Linfeng Chen3 and Youbai Xie1

Abstract
Since functional modeling can be very useful in conceptual design, it has received considerable attention from engineering
design community. However, existing functional models still cannot effectively assist designers in analyzing the function-
alities of multi-state systems during conceptual design. As a result, designers often have to manually carry out function-
ality analysis according to their experiences, which are not only tedious, but also error-prone. Therefore, this paper
proposes a state–behavior–function model for functional modeling of multi-state systems, which can provide designers
with automated functional analysis support. The approach involves not only a state–behavior–function model for
representing components, but also a model for representing the functionalities of multi-state systems. A prototype
software is then developed for demonstrating the proposed model, with the functional modeling of a peeler centrifuge as
an example to illustrate the proposed functional modeling approach.

Keywords
Conceptual design, computer-assisted design, mechanical design, modeling, system modeling, complex systems

Date received: 7 March 2018; accepted: 29 June 2018

merely employ a single functional diagram to repre-

Introduction
Functional modeling usually refers to the design activ-
ity of developing the models of products or systems
based on their functionalities and the functionalities
of their components.1 It is widely acknowledged that
functional modeling can play a significant role in con-
ceptual design,1–3 since functional models not only
allow engineers to share and communicate design con-
cepts across various disciplines, but also can assist
them in achieving concept generation and design syn-
thesis. Therefore, considerable functional modeling
research has been carried out in recent decades, with
a result of many valuable outcomes.4–13
It is found that most of the existing functional
modeling research has been focused on functional
synthesis, e.g. how to generate solution concepts via
functional reasoning. In recent years, researchers are
increasingly realizing the significance of how to pro-
vide designers with effective support for function-
based design analysis.12,14,15 However, existing
functional modeling approaches often represent the
functional structure of a system with a static dia-
gram,15 resulting in that it is often difficult for a com-
puter-based tool to recognize the objects in the
diagram and to reason about the functionalities of
the whole system. In addition, existing approaches
sent the functionalities of a system, resulting in that
they cannot be used to establish explicit functional
models for multi-state systems. Hereby, a multi-state
system refers to a multi-function system that can
achieve different functions at different operation
(working) states. A simple example of a multi-state
system is a hair-dryer, which usually has two oper-
ation states. One is the state of blowing air, which
includes one function, i.e. the hair-dryer accelerates
air, and the other is the state of blowing and heating
air, which includes another function, i.e. the hair-
dryer accelerates and heats air. Note that a multi-
state system usually relies on different topological
structures to achieve different functions.
In this paper, we are primarily concerned with the
development of a functional modeling approach that
1
School of Mechanical Engineering, Shanghai Jiao Tong University,
Shanghai, China
2
School of Aeronautics and Astronautics, Shanghai Jiao Tong University,
Shanghai, China
3
College of Chemistry, Sichuan University, Sichuan, China
Corresponding author:
Yong Chen, School of Aeronautics and Astronautics, Shanghai Jiao Tong
University, 800 Dongchuan Road, Shanghai 200240, China.
Email: mechenyong@sjtu.edu.cn
Zhao et al.
can be used to achieve automated functional analysis
for multi-state systems. Note that functional analysis
is often a critical task for the development of complex
systems (e.g. civil aircrafts), since it can fundamentally
determine the safety characteristics of complex sys-
tems. However, due to the lack of an automated ana-
lysis tool, designers often have to manually fulfill
such complex functionality analysis tasks, which are
not only time-consuming, but also error-prone.
In this research, a state–behavior–function-based
approach is proposed for the functional modeling of
multi-state systems. A basic assumption is that the
solution concept (i.e. system concept) of a multi-state
system has been generated, and the aim of our func-
tional modeling research is to provide a methodology
for designers to establish a formal model for represent-
ing the functionalities of the whole system concept.
This paper is organized as follows. The upcoming
section reviews the related work. Next section pro-
poses a state–behavior–function model for the func-
tional modeling of system components. Subsequently,
a state–behavior–function model is developed for rep-
resenting the functionalities of a system. With a peeler
centrifuge as an example, later section illustrates how
the proposed approach can be used to achieve
the functional modeling of a multi-state system. The
final section concludes this paper.
Related work
Due to its significance, a large body of functional
modeling-related research has been carried out in
recent decades, with a result of many valuable out-
comes, which can be found in some recent reviews.1,13
Note that in some artificial intelligence
research,10,16,17 functional modeling is also called
functional representation, which is focused on how
to model the working processes (i.e. functionalities)
of a system for achieving desired functions. Due to
limited space, only some significant approaches
related to functional modeling are reviewed here.
Depending on different purposes, existing research
primarily falls into two categories, i.e. the synthesis-
oriented research and the analysis-oriented research.
The synthesis-oriented research on functional mod-
eling is aimed at the approaches for transforming a
desired function into a solution concept. Besides the
function–behavior–structure model,5 and the state–
behavior–function model,10 most of such synthesis-
oriented research is rooted in the systematic approach
of engineering design,15 where functional modeling
primarily refers to the process of decomposing an
overall function into sub-functions (and even sub-
sub-functions if necessary), that of searching for suit-
able solution principles for the sub-functions, and that
of combining the solutions of sub-functions into a
whole solution concept to address the overall function.
For example, Umeda et al.6 have proposed the func-
tion–behavior–state model, based on which solution
2303
alternatives can be retrieved from a knowledge base.
In addition, researchers have developed some auto-
mated approaches for assisting designers in generating
solution concepts for electro-mechanical or mechan-
ical systems,7,11,18–22 which are also regarded as a
stream of functional reasoning research.13
The analysis-oriented research is often aimed at the
functional modeling approaches for analyzing and
verifying a solution concept intended to fulfill a func-
tion. A pioneering work in this area is undertaken by
Stone et al.,23 who have developed an approach for
predicting failure modes based on a function-failure
knowledge base. Kurtoglo and Tumer9 have proposed
a framework for identifying functional failures and
their propagations9 where a behavior simulation is
performed on the basis of function structures and con-
figuration flow graphs. Aurisicchio et al.22 have pro-
posed a function analysis diagram to model system
functions together with structure,22 which, however,
cannot support automated functional analysis. Sen
and Summers15 have proposed an approach for for-
malizing function structure graphs so that a computa-
tional reasoning tool can be developed to support the
analysis of a solution concept. Aimed at addressing
failures that originate from the interaction of physical
and software subsystems, Mutha et al.12 have pro-
posed a multi-domain failure analysis approach
through extending the functional-failure identification
and propagation framework. Jensen et al.24 have
applied data clustering methods to functional failure
analysis, which allows a computational tool to reason
about system-level failure behaviors based on the fail-
ures at the component level. In the systems engineering
area, researchers have developed some SysML-based
approaches to assist engineers in modeling and verify-
ing the functionalities of complex systems.25,26
It can be found that the synthesis-oriented
approaches are largely for generating solution con-
cepts, which are not suitable for design analysis,
while the analysis-oriented approaches have neglected
the fact that a multi-state system can change its topo-
logical structures to achieve different functions,
which, therefore, cannot effectively analyze function-
alities of a multi-state system. In addition, it should be
noted that the concept of state or state transformation
in existing functional modeling research is largely dif-
ferent from that in our research. For example, in the
function–behavior–state model6 a state of an entity is
defined by the attributes of the entity (e.g. weight) and
its relations with external entities. In contrast, our
concept of state, as defined later in this paper, is
more concerned with the internal topology of an
entity (e.g. component), i.e. how the internal elements
of an entity are connected with each other. Since
multi-state systems are very common in complex sys-
tems, it is then necessary to develop a formal
approach for achieving the functional modeling of
multi-state systems, so as to achieve automated func-
tional analysis of multi-state systems.
2304
Functional modeling of components
A system can usually be regarded as an aggregate of
components. To achieve the functional modeling of a
system, it is indispensable to have a model for repre-
senting the components that constitute the system. In
this research, a component is modeled as an object
that may have multiple states, and at each state, the
object can achieve a specific function. Therefore, a
state–behavior–function model is developed here for
representing the functionalities of a component.
Component
In our functional modeling research, a component is
regarded as a basic object of a system, which has a
name and a set of attributes to indicate what the com-
ponent is. Note that a component can be physically
disassembled into some primitive elements, which,
however, are not discussed here since they are not
the concern of functional modeling. For example, a
light bulb is often treated as a basic component in the
functional modeling process, which, however, can
actually be disassembled into some primitive elements
such as wire filament, glass cover, etc. In addition, it
should be noted that the physical form (i.e. appear-
ance) of a component is also not considered in this
research, since the form representation is also not
necessary for functional modeling.
To allow functional modeling, the representation
of a component also has some ports to receive input
flows and to release output flows. According to Pahl
et al.,27 the input or output flows here can be classified
as material, energy, and (or) information flows. Note
that a component probably does not have a real port
(such as a hole in a pipe), which means that a port of a
component may just be fictitious for the convenience
of representing the functionalities of the component.
For example, a gear box does not have real ports for
transmitting torque, where its input or output port
actually corresponds to the input or output shaft.
Component state
A state of a component refers to the conceptualization
of a configuration of the elements in the component,
which involves not only what elements the component
has, but also the connection relations among these
elements, as well as the physical states of these elem-
ents. Therefore, a state here can also be called a con-
figuration state. For example, an electrical switch can
have two states, i.e. on and off, while the internal con-
nection relation among the elements of the switch in
the on state is obviously different from that of the
switch in the off state.
In this research, a state of a component is repre-
sented as a state attribute of the component,
i.e. sa(c) ¼ val, where c refers to the component,
sa denotes the state attribute, and val is the state
value. As a result, it is then possible to represent the
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
multiple states of a component as a set of state values.
For example, the switch of a hair-dryer often has three
states, i.e. off, on_1, and on_2. When the switch is in
state on_1, at which the hair-dryer merely blows air,
its state can then be represented as: sa(c_s-
witch) ¼ ‘‘on_1’’; when the switch is in state on_2, at
which the hair-dryer can both blow and heat air, its
state can then be represented as: sa(c_switch) ¼ ‘‘on_2’’.
Note that the concept of state here is different from
that in the function–behavior–state model,6 where a
state of an entity is defined by the attributes of the
entity (e.g. weight) and its relations with external enti-
ties. In contrast, the concept of state in our research is
regarded as an abstraction of the internal configur-
ation of an entity, which has no relation with external
entities. In addition, the concept of state in this
research is also different from that in the structure–
behavior–function model,10 where state is employed
to refer to the state of a functional flow, rather than
that of a component. Since a multi-state system relies
on different states of components to achieve different
functions, it is necessary to represent the states of a
component in a system.
Component behavior
In this research, a behavior of a component refers to a
change of a component from one state to another. In
a technical system, a component behavior is often
related to a control input, which can be called as a
trigger. For example, a behavior of a solenoid (i.e.
electromagnetic) valve (as shown in Figure 1) can
change from the state closed to the state left_open,
when the left solenoid of the valve receives electricity
as a trigger. Note that a trigger of a component
cannot be treated as a functional input flow of the
component, since the trigger, instead of being changed
by the component, merely leads to the change of the
state of component. In contrast, the traditional func-
tional modeling approaches do not differentiate the
control inputs of a component from the functional
inputs, resulting in that they cannot explicitly repre-
sent the state changes of the component.
Based on the above analysis, a component behav-
ior, b, can then be represented as a triple, <t, sai, saf>,
where, t refers to the trigger, sai denotes the initial
state of the component, and saf indicates the final
Figure 1. The behavior of a solenoid valve.
Zhao et al.
state. Note that it is possible that a component may
allow multiple triggers, each of which corresponds to
a different component port to receive an independent
control input. Therefore, it is more reasonable to rep-
resent a behavior as a quadruple, i.e. < t, pb, sai, saf > ,
where pb refers to a behavior-related port for receiving
a trigger (i.e. a control input). With the aforemen-
tioned solenoid valve as an example, a behavior of
the component can then be represented as <t_DC,
p_EleLeft, s_Closed, s_LOpen>, which means that
when the valve receives a trigger t_DC from port
p_EleLeft (i.e. the electrical port at the left side), its
state will change from the state s_Closed to s_LOpen
(i.e. left open).
Note that the concept of behavior here is funda-
mentally different from those in the existing func-
tional modeling research. For example, in the
structure–behavior–function model,10 a behavior
refers to a state change of a functional flow, which
is not directly related to a component. In contrast, the
concept of behavior in our research refers to the state
change of a component itself, which does not involve
a functional flow. With an electrical switch as an
example, the behavior concept in the structure–behav-
ior–Function can be represented with the location
change of electricity (i.e. the functional flow), while
the behavior of the switch in our research is repre-
sented as the state change from off to on or from on
to off. It is evident that our behavior concept allows
the representation of the state transition of a compo-
nent, which is necessary for the functional modeling
of multi-state systems.
Component function
According to Pahl et al.,27 a component function can
be regarded as an abstract action that a component
imposes on one or multiple flows to change the flow(s)
from input to output. The (functional) flows here can
often be classified as material flows, energy flows, or
information flows. Note that unlike a material flow,
an energy or information flow may often be an
abstract flow and, therefore, cannot be directly
observed. For example, although the function of a
gear box is often regarded as to transmit torque,
what can be directly observed is the rotation of the
input shaft and that of the output shaft, rather than
the torque.
Based on the above understanding, a function of a
component can then be represented as a binary,
i.e. < I, O>. Here, I represents a set of functional
flows at the input ports, i.e. {(ik, pk)} (k ¼ 1, 2,. . .,
m), where ik is the kth input flow at port pk, while O
refers to a set of flows at the corresponding output
ports, i.e., {(ot, pt)} (t ¼ 1, 2,. . ., n), where ot is the tth
output flow at port pt. Note that it is often necessary
to further represent a flow with some qualitative attri-
butes and quantitative parameters, which is not ela-
borated here for conciseness.
2305
However, the above component function represen-
tation has not taken into consideration the fact that a
component can have multiple states for achieving dif-
ferent functions. In view of this, all possible functions
of a component should then be represented as a func-
tion set, i.e. {fj}. Hereby, each function, fj, can be fur-
ther represented as a triple, (saj, Ij, Oj), where, saj
denotes the jth value of the state attribute sa (i.e.
the jth state) of the component, Ij represents a set of
input flows at the corresponding state, i.e. {(ijk, pjk)},
and Oj denotes a set of output flows at this state, i.e.
{(ojt, pjt)}. Still with the solenoid valve as an example,
a possible function f can then be represented as
(s_LOpen, {(f_liquid, p_A)}, {(f_liquid, p_L)}), which
means that when the valve is in the state of s_LOpen,
the input flow f_Liquid at port p_A will be transferred
to the output flow f_Liquid at port p_L. Another func-
tion of this valve can be represented as (s_ROpen,
{(f_liquid, p_A)}, {(f_liquid, p_R)}), which means
that when the valve is in state s_ROpen, the input
flow f_Liquid at p_A will be transferred to the
output flow f_Liquid at port p_R. It can be found
that a salient feature of the proposed functional rep-
resentation approach consists in that it allows the rep-
resentation of different functional models of a
component at different states, which is different
from the previous research, where a component
merely has one function.
Schema for representing components
Based on the above analysis, a schema can then be
proposed to represent the state, behavior, and func-
tion of a component, as shown in Figure 2. In the
figure, the aforementioned solenoid valve is also
employed as an example to illustrate the component
representation schema. Figure 3 shows the state–
behavior–function model of a component, where the
component can be in the state of A, B, or C, and can
change its state to deliver different functions (i.e. func-
tion1 and function2).
Note that the concept set for the functional model-
ing of components here is largely different from that
in SysML. Although our concept of state is similar to
that in SysML, the concepts of behavior and function
are fundamentally different from those in SysML. Our
concept of behavior is more like the concept of state
transition in SysML, while SysML does not have a
formal definition for function, which, though, is neces-
sary for functional modeling. In addition, SysML fails
to provide a mechanism to deal with the change of
configuration relations (discussed in the ‘‘System
state’’ section), which is often necessary for represent-
ing the functionalities of a multi-state system.
Functional modeling of systems
A system is an assembly of different components that
work together to achieve a desired function. It should
2306
Figure 2. The schema for representing components.
be noted that in the functional modeling research, it is
usually assumed that the components in a system do
not directly interact with each other, but act on the
flows between these components. Although such an
assumption probably does not accord with the situ-
ation in the physical world, it is often acceptable for
functional modeling and analysis. From the perspec-
tive of functional modeling, the concepts of state,
behavior, and function of a multi-state system are
elaborated as below.
System state
Similar to the state concept of a component, a state of
a system refers to a configuration of the system’s
internal objects (i.e. components or subsystems) in a
specific situation.
Just like a component state, a system state can also
be represented with a state attribute, i.e. sa(sys),
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
where sys represents a system of interest and sa
refers to the state attribute. For example, when a
Lighting System (LS) is in the normal electrical con-
nection state, its state can be represented as:
sa(sys_LS) ¼ ‘‘normal’’.
However, a state attribute alone is often insufficient
to explicitly represent the complete state of a complex
system, which is often an assembly of components and
sub-systems. For the purpose of functional analysis in
conceptual design, a detailed system state should deal
with not only the composition of a system, but also
the state attributes of its components and (or) subsys-
tems, as well as the configuration relations among
these components and subsystems. Therefore, we add-
itionally employ a triple to represent the detailed state
of a system, i.e. (C, SA, R). Hereby, C stands for the
object composition of the system, SA represents the
state attribute set of the related objects, and R refers
to the configuration relation set.
Zhao et al.
Figure 3. The state–behavior–function model of components.
The object composition (C) of a system means
what objects the system has, i.e. what components
and (or) subsystems are in the system. Note that the
material/energy/information objects that flow
through a system are not treated as a part of the com-
position of a system. Therefore, the composition of a
system can then be represented with the union set of a
component set and a subsystem set, i.e. C ¼ {ci}[{sj},
where ci is a component, and sj is a subsystem, which
can be further decomposed into sub-subsystems and
(or) components. Note that a subsystem probably
does not exist for a simple system. For example, it is
often not necessary to decompose a hair-dryer into
some subsystems for functional analysis. Therefore,
the composition of a hair-dryer can simply be repre-
sented as a component set, i.e. {c_plug, c_switch,
c_motor, c_heater, c_fan, c_wire_1,. . .}.
The state attribute set (SA) is an aggregate of the
state attributes of the objects in a system at a time.
Assuming that a system is decomposed into some
components and subsystems, where the components
do not belong to the subsystems, an object state set of
the system can then be represented as a union set, i.e.
SA ¼ {sa(ci)}[{sa(sj)}, where sa(ci) denotes the state
attribute of component i, and sa(sj) refers to the
state attribute of subsystem j. Note that the state attri-
bute of a subsystem here, should be associated with a
detailed state representation of the subsystem, which
allows a design engineer to understand the detailed
state of the subsystem. Therefore, the state attribute
of a subsystem can also be regarded as a state index of
the complete state representation of the subsystem.
The configuration relation set (R) is a set of rela-
tions that describe how the components of a system
are functionally connected with flows, i.e. from which
component the input flows come, and to which com-
ponent the output flows go. Note that a configuration
relation here is largely different from a structural or
physical connection relation, which the previous
2307
functional modeling research has dealt with.5,15
With a hair-dryer as an example, Figure 4 gives
both a physical structure diagram (the upper one)
and a functional diagram (the lower one) of a hair-
dryer. It can be found that in the upper (i.e. physical)
diagram, the power source (i.e. the plug) is directly
connected with the heater (R) and the motor (M),
and the heater is connected with the motor in a par-
allel manner; however, in the lower (i.e. functional)
diagram, the plug is not directly connected with the
heater and the motor, and the heater is just connected
with the motor in a sequential manner. Therefore, the
configuration relations in a system are often largely
different from the structural or physical relations in a
system, which means that the (configuration) state of
a system is also largely different from a structural
state of a system.
In this research, a configuration relation is repre-
sented as an association, i.e. (<oi, pik>, < oj, pjt>),
where oi denotes the source object that outputs a
flow, pik refers to the source object’s port where the
output flow goes out, oj represents the destination
object of the flow coming from pik, and pjt is the
port of the destination object that the flow comes in.
Here, an object can be a component, a subsystem or
an environmental object of a system. With the config-
uration diagram shown in Figure 4 as an example,
some configuration relations can be represented as:
(<environment, null>, < c_plug, pin>); (<c_plug,
pout>, < c_switch, pin>); (<c_switch, pout>, < c_motor,
pin>); (<c_switch, pout>, < c_heater, pin>);
(<c_motor, pout>, < c_fan, pin_rotation>); (<e_air,
null>, < c_fan, pin_air>); etc. It can be found that the
proposed model can explicitly represent different con-
figuration relations of a multi-state system. In con-
trast, the existing approaches (e.g. SysML) can
merely represent a single configuration relation for a
system, regardless of the system being a single-state
system or a multi-state system.
2308
Figure 4. A comparison of the physical diagram and the functional diagram of a hair-dryer.
Note that it is usually necessary to combine the
state attribute representation and the detailed model
representation together to represent a state of a
system, i.e. (sai, < Ci, SAi, Ri > ). Hereby, sai refers
to the ith value of the state attribute of a system,
which can be treated as a description of the system
state at a higher level, while Ci means the object com-
position of the system at the state sai, SAi represents
the corresponding state attribute set, and Ri denotes
the corresponding configuration relation set. With
such a combined representation, it is then possible
for a computational system to reason from the state
attribute representation of a system to the detailed
state representation of its components, and vice versa.
System behavior
Similar to the concept of component behavior, a
system behavior refers to that a system changes
from one state to another, which is usually induced
by some triggers (i.e. control inputs). Since a system
may have multiple components and (or) subsystems
that have multiple (configuration) states, a system can
have multiple triggers to allow these components and
(or) subsystems to change their states. Therefore, a
behavior of a system can also be represented as a
triple, <T, SI, SF>, where T refers to a set of triggers,
and SI and SF represents the initial state and the final
state of the system, respectively.
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
The trigger set (T) of a system is composed of a set
of triggers. Since a system may have multiple compo-
nents and (or) subsystems, and not all components or
subsystems can accept control inputs (i.e. triggers),
the destination of a trigger needs to be made clear
in a trigger representation. Therefore, a trigger of a
system can be represented as a triple, i.e. (ti,, oi, pBij),
where, ti refers to the trigger, oi represents a system
object (a component or a subsystem) that receives the
trigger, and pBij is the control port of the system object
to receive the trigger. As a result, the trigger set (T) of
a system can be represented as {(ti,, oi, pBij)}. For
example, to start the engine of a car, a driver usually
needs to step on the brake and turns the key to the
start position. Here, the two triggers can be repre-
sented in a set: {(f_force, c_brake, pB_foot),
(h_momentum, c_key, pB_hand)}, where f_force refers
to the force imposed by the foot of the driver, and
h_momentum is the momentum imposed by the hand
of the driver.
Theoretically speaking, the initial state (SI) and
the final state (SF) of a system should be repre-
sented with the state attribute (i.e. sa) and the
detailed state model (i.e. < C, SA, R>). However,
since there is a one-to-one corresponding relation
between the state attribute representation and the
detailed state model, and all possible detailed
states should be represented with the detailed state
representation approach, it is then not necessary to
Zhao et al.
employ the detailed state representations in the
system behavior representation, which means that
the initial state (SI) and the final state (SF) of a
system can then be simplified as two states, i.e. saI
and saF. Therefore, the representation of a system
behavior can then be simplified as a triple, i.e. (T,
saI, saF), where T is a set of triggers of behaviors of
the internal objects of a system. A trigger in T can
be represented as (ti,, oi, pBij), which means that the
object oi can change its state if it receives the trigger
ti at port pBij. When a system receives a set of trig-
gers, i.e. {(ti,, oi, pBij)}, objects in the system can
receive the triggers. These objects can then change
their states according to the component behaviors,
i.e. < ti, pBij, sai_Initial, sai_Final > . Figure 5 illustrates
the relation between a behavior of a system and
behaviors of the objects in the system.
Based on the above analysis, it is then possible to
explicitly represent a behavior of a system. Still with
the hair-dryer mentioned in the previous subsection as
an example, when a person turns on a hair-dryer (i.e.
change the position of the switch from off to on_1, the
behavior of the hair-dryer can then be represented as:
({(h_force, c_switch, pB_hand)}, off, on_blowing), where
{(h_force, c_switch, pB_hand)} refers to a trigger (i.e.
h_force) by a hand force on the switch, off means
that the initial state of the hair-drying system is off,
and on_blowing indicates that the final state of the
hair-drying system is on_blowing. With the system
behavior representation, it is then possible to repre-
sent a behavior of a complex system in a hierarchical
manner, and thus can simplify the behavior represen-
tation of a complex system.
Figure 5. A behavior of a system and behaviors of the objects in the system. (a) The behavior of a system, (b) The behaviors of the
internal objects of the system.
2309
System function
Similar to a component function, a system function is
regarded as an abstract action of a system at a specific
state, which transforms one or multiple input flows
into some output flows. Therefore, a system function,
fj, can also be represented as a triple, (sj, Ij, Oj), where,
sj denotes a specific state of a system, Ij represents a
set of input flows at this state, i.e. Ij ¼ {(ijk, pjk)}, and
Oj denotes a set of output flows at this state, i.e.
Oj ¼ {(ojt, pjt)}. Similar to the system behavior repre-
sentation, the system state (i.e. sj) in the above
representation can also be simplified as a state attri-
bute (i.e. saj). Note that the input and output flows of
a system, i.e. Ij and Oj, need to be further allocated to
the corresponding ports of the internal objects of the
system, which will be elaborated later in the subse-
quent section.
For the analysis of a complex system, the above
functional representation approach allows a design
engineer to simplify the representation of a subsys-
tem’s function as some input flows and output
flows, and thus can avoid representing the complex
interactions among the components in the subsystem.
If a subsystem in itself is very complex and is not the
primary concern of system analysis, such a system
function representation can also alleviate unnecessary
system modeling work. For example, since the power
source of a system often refers to a complex electricity
grid, it is neither necessary nor possible for a system
engineer to explicitly represent the electricity grid;
therefore, the electricity grid can often be simplified
as a subsystem that merely outputs electricity to a
system of interest.
2310
System function allocation
Although the function of a system can be represented
with the model illustrated in the previous section, a
system engineer may also be required to analyze a
system (or a subsystem) at a more detailed level (e.g.
at the component or subsystem level). In such a situ-
ation, it is then necessary to break down the system
into components and (or) subsystems (i.e. open the
black box of a system), and then model the functional
processes about how these components or subsystems
interact with the input flows. Since the representation
of a system function has merely stated the input and
output flows at the system level, it is then necessary to
hierarchically allocate the inputs and outputs of a
system to the component or subsystem level, so that
it is possible for the components or subsystems of the
system to act on the flows.
In this research, such a functional allocation rela-
tion is represented as a binary group, i.e. (sys, ps, f,
obj, po), which means that the flow (f) of the system
(sys) at port (ps), is allocated to the object (obj) at port
po, i.e. f(ps (sys)) ¼ f(po (obj)). Still with the hair-dryer
mentioned before as an example, the system configur-
ation and its breakdown are shown in Figure 6. Here,
Figure 6. The function allocation of a hair-dryer.
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
the allocation relations from the system level to the
component level can be represented as: {(sys_HD, p1,
ele_energy, c_Plug, p1), (sys_HD, p2, air, c_Inlet, p1),
(sys_HD, pc1, h_force, c_Switch, pc1), (sys_HD, p2,
acce&heated_air, s_HD, p2)}. Note that there is also
a simplified system behavior included in the diagram,
i.e. the switch changes from the state of ‘‘off’’ to the
state of ‘‘on’’, which is necessary for the hair-dryer to
work.
With a typical system as an example, Figure 7
shows the state–behavior–function model of the
system, where it is assumed that the system can be
in the state of S0 or S1. As a result of the state tran-
sition from S0 to S1, the function that the system in
Figure 7 fulfills can change, i.e. transforming the input
flow (flow_x) of the system to flow_z, instead of
flow_y.
Test
Based on a commercial software, some customization
development has been carried out to implement the
state–behavior–function-based approach for func-
tional modeling, with the result of a prototype
Zhao et al.
Figure 7. The state–behavior–function model of systems.
software for achieving functional modeling. The
prototype software not only allows designers to
achieve function modeling of multi-state systems,
but also supports functional simulations based on
the models of the systems. It is primarily composed
of three subsystems, i.e., the composition manage-
ment subsystem, which allows engineers to manage
the composition of a multi-state system; the func-
tional modeling subsystem, which is for engineers to
model the states, behaviors, and functions of compo-
nents, as well as those of subsystems that design
engineers are concerned with; and the functional
simulation subsystem, which can perform functional
simulation based on the functional models. A peeler
centrifuge is employed here as an example to demon-
strate how to achieve functional modeling and simu-
lation with the aid of the prototype software.
2311
Functional modeling
Peeler centrifuges are very common in manufacturing
and waste-processing industries, which can separate
solid particles from liquid. A typical peeler centrifuges
can be in five working modes, i.e. feeding, filtrating,
washing, spinning, and discharging. After some liquid
with solid particles is fed into a peeler centrifuge, the
peeler centrifuge will start filtrating, through the high-
speed rotation of the centrifugal subsystem, which
pushes the liquid towards a filter layer (medium). As
a result, the solid particles can be deposited on the
filter layer, but the remaining liquid on the surface
of the solid particles still needs to be eliminated.
Thereafter, the state of washing follows, where deter-
gent is fed into the peeler centrifuge to flush the filter
layer. After the detergent is drained, the peeler centri-
fuge starts spinning to eliminate the detergent.
2312
Finally, in the state of discharging, the solid particles
on the filter medium are scraped with the peeler and
discharged from the peeler centrifuge. In this example,
it is assumed that the solution concept of a peeler
centrifuge has been generated. The primary compos-
ition of the peeler centrifuge is shown in Figure 8.
Among the six subsystems, the hydraulic control
subsystem plays a crucial role in the state transitions
of the peeler centrifuge. Figure 9 shows the allocation
and the configuration relations in which the hydraulic
control subsystem is involved, while the other rela-
tions of the peeler centrifuge are not displayed for
Figure 8. The primary composition of the peeler centrifuge.
Figure 9. The allocation and configuration relations in which the hydraulic control subsystem is involved.
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
conciseness. As shown by the red ellipse in this
figure, the connector between p_PC_Elec and
p_HCS_Elec indicates the allocation relation between
the peeler centrifuge at a higher level and the hydrau-
lic control subsystem at a lower level. This allocation
relation dictates that electrical energy flowing into
peeler centrifuge through p_PC_Elec would be allo-
cated to hydraulic control subsystem at p_HCS_Elec,
which can be represented as (Peeler_centrifuge,
p_PC_Elec, f_Elec, Hydr_control_subsystem, p_HCS_
Elec). As shown by the blue ellipse Figure 9, the con-
nector between p_HCS_Kinetic and p_DS_Kinetic indi-
cates a configuration relation, i.e. (<Hydr_control_
subsystem, p_HCS_Kinetic>, < Discharging_subsys-
tem, p_DS_Kinetic>). This configuration relation
allows the hydraulic control subsystem to provide the
discharging subsystem with kinetic energy, so that the
peeler in the discharging subsystem can work. The con-
figuration relations between the hydraulic control sub-
system and the feeding subsystem indicate that
hydraulic control subsystem can deliver triggers to
the control ports of feeding subsystem, which allows
feeding subsystem to change its state. Likewise, the
configuration relations between the electric control
subsystem and the hydraulic control subsystem indi-
cate that electric control subsystem can deliver triggers,
which set off state transitions of hydraulic control
subsystem.
Within the hydraulic control subsystem, there are
three solenoid valves, each of which has a control port
to receive triggers allocated from the subsystem, as
shown in Figure 10. Each valve fulfills a different
function, as the state of the valve changes as a result
of the trigger. According to the function illustrated in
Figure 2, solenoid valve for inlet can deliver a hydrau-
lic flow through either p_SVI_Mix or p_SVI_Dtg,
depending on the trigger it receives at port
Zhao et al.
Figure 10. The allocation and configuration relations of the hydraulic control subsystem.
Figure 11. The user interface for functional modeling of solenoid valve for inlet.
p_SVI_Control. The user interface for functional mod-
eling of solenoid valve for inlet is illustrated in Figure
11. In this manner, solenoid valve for inlet is intended
to control the feeding subsystem to allow the input of
either the mixture or the detergent. Likewise, solenoid
valve for outlet is intended to allow the output of
either the liquid or the detergent in the discharging sub-
system. Solenoid valve for peeling delivers a hydraulic
flow to Cylinder at either p_C_Forward or
p_C_Backward, so that the cylinder can output a bidir-
ectional translation to enable the peeler in the dischar-
ging subsystem to engage or retract.
Functional simulation
As noted by Tomiyama et al.,14 functional simulation
can be a practical application of functional modeling
research, since computer-based functional simulation
tools can be employed to perform validation during
conceptual design and to identify overlooked design
failures. When the state–behavior–function model of
2313
a multi-state system is provided, functional simulation
can then assist designers in predicting how the system
will operate and when the states of some components
will change. Based on the functional model of the
peeler centrifuge developed above, functional simula-
tion can be carried out to demonstrate how the proto-
type software can support automated system
functional analysis.
The functional simulation begins with setting the
initial state of the system. In this example, the peeler
centrifuge is assumed to be in the state of filtrating,
which means that the centrifugal subsystem rotates
liquid mixed with solid particles and then the dischar-
ging subsystem expels the liquid from the peeler cen-
trifuge. Figure 12 shows the initial state of the peeler
centrifuge, where the blue rectangles refer to the
components of a system or subsystem that are in
operation, while the white rectangles refer to the com-
ponents that are not working. Note that a system or
subsystem in operation is not filled with blue color,
which is different from a component in operation. In
2314 Proc IMechE Part C: J Mechanical Engineering Science 233(7)

Figure 12. The initial state of the peeler centrifuge.

Figure 13. The intermediate state of the peeler centrifuge.

Zhao et al.
Figure 14. The final state of the peeler centrifuge.
this figure, the black lines with arrows indicate how
the flows are transferred from the output ports of pre-
vious objects (components or subsystems) to the input
ports of the following objects. Note that the electric
control subsystem and some components have been
omitted in this figure for conciseness. In this state,
hydraulic control subsystem receives the electric
signal (f_LiqOpen) as a trigger that leaves solenoid
valve for outlet in the state LiqOpen. As a result, the
hydraulic flow (f_Hydr) is sent to the control port
p_DS_contLiq of discharging subsystem, so that the
liquid flow (f_Liq) can be expelled from port
p_PC_Liq.
After the initial state of the peeler centrifuge has
been set, a functional analysis engineer can then
release some triggers to observe how the peeler cen-
trifuge changes its state. In the prototype software, for
example, a designer can simulate the process that the
state of the peeler centrifuge changes to the state of
washing, through sending the electric signal
f_DtgOpen to the control port p_HCS_contOutlet of
the hydraulic control subsystem. Note that the
signal LiqOpen at port p_HCS_contOutlet shown in
Figure 12 has been removed prior to sending signal
f_DtgOpen. The allocation relation between the sub-
system and the solenoid valve enables the signal
f_DtgOpen to arrive at the control port of the com-
ponent solenoid valve for outlet. Once receiving the
signal, solenoid valve for outlet changes its state from
Closed to DtgOpen, since the signal f_DtgOpen is the
2315
trigger of its behavior as shown in Figure 11. In the
state DtgOpen, the valve delivers hydraulic energy
f_Hydr through the port p_SVO_Dtg. The configur-
ation and allocation relations can then be employed to
transfer this hydraulic flow to the control port of the
component hydraulic valve for out_Dtg. As a result,
the component hydraulic valve for out_Dtg changes its
state from Closed to Open, thus activating the func-
tion of transferring a liquid flow from input to output.
In this manner, the signal f_DtgOpen makes the peeler
centrifuge to change to an intermediate state between
filtrating and washing, as shown in Figure 13.
Thereafter, the functional analysis engineer can also
send another trigger to enable the prototype software
to simulate a subsequent state transition of the peeler
centrifuge. For example, when the engineer sends an
electric signal flow f_DtgOpen to the port
p_HCS_contInlet of hydraulic control subsystem,
which is then allocated to the control port of the com-
ponent solenoid valve for inlet, the state of the solenoid
valve is then changed as DtgOpen. As a result, the func-
tion of this valve is activated, which means that
hydraulic control subsystem then outputs hydraulic
flows through the port p_HCS_inDtg, as well as the
port p_HCS_outDtg. Thereafter, the component
hydraulic valve for in_Dtg, whose trigger is a hydraulic
flow, changes its state from Closed to Open, so that
centrifugal subsystem receives the flow of detergent.
Finally, the component hydraulic valve for out_Dtg ful-
fills the function of transferring flows from input to
2316
output, as shown in Figure 14. At this time, peeler
centrifuge outputs the flows of detergent and liquid
(f_Dtg & f_Liq), which means that the state of the
peeler centrifuge changes to washing as a result of the
signal f_DtgOpen sent by the functional analysis
engineer.
From the above example, it can be found the
prototype software can simulate how a multi-state
system changes its state to deliver different functions
when the system receives some external triggers
(i.e. control signals). It can also be found that the
proposed state–behavior–function approach allows
designers to model the functionalities of a system in
a hierarchical way, so that the functional simulation
process can either work on the system level or on the
component level.
Conclusions
Since functional models can be very useful for con-
ceptual design, a large amount of research has been
undertaken in the functional modeling area. However,
little research has been carried out on how to assist
designers in achieving the functionality analysis of
multi-state systems during conceptual design.
Therefore, this research attempts to develop a state–
behavior–function model for achieving the functional
modeling of multi-state systems.
Since a system can be regarded as an assembly of
components, it is indispensable to achieve functional
modeling of the components first. With the proposed
approach, the states, behaviors, and functions of
components can be explicitly represented, establish-
ing functional models that allow components to be
in different states and achieve different functions.
Based on the functional models of components, con-
figuration relations between components (subsys-
tems), along with allocation relations between
systems (subsystems) and components have been
employed to establish functional models of multi-
state systems, so that the states, behaviors and func-
tions of the systems can be explicitly represented. As
demonstrated by the example of the peeler centri-
fuge, the state–behavior–function models above
allow a computer-aided tool to perform a functional
simulation to support functionality analysis of multi-
state systems.
A potential use of the state–behavior–function
models involves functional failure analysis during
conceptual design. If a functional failure occurs to a
component (subsystem) within a system, a functional
simulation can be conducted based on the functional
model of the system, so as to support the analysis of
the impact of the failure on the functionality of the
whole system. Note that the proposed model does not
consider the fact that the states of a component can
change as a result of physical phenomena that occurs
within the component, which is also a drawback of
the current work. For example, the state of a
Proc IMechE Part C: J Mechanical Engineering Science 233(7)
component can change over time if the component
has a timer in it. To address this issue, our future
work will incorporate a time-dependent model into
the state–behavior–function model reported in this
research.
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with
respect to the research, authorship, and/or publication of
this article.
Funding
The author(s) disclosed receipt of the following financial
support for the research, authorship, and/or publication
of this article: This work was supported by the Ministry
of Industry and Information Technology of the People’s
Republic of China.
ORCID iD
Meng Zhao http://orcid.org/0000-0002-5302-8272
References
1. Erden MS, Komoto H, Van Beek TJ, et al. A review of
function modeling: Approaches and applications. AI
EDAM 2008; 22: 149–169.
2. Kuttig D. Potential and limits of functional modelling
in the CAD process. Res Eng Des 1993; 5: 40–48.
3. Maarten Bonnema G and Van Houten FJ. Use of
models in conceptual design. J Eng Des 2006; 17:
549–562.
4. Hunt JE, Pugh DR and Price CJ. Failure mode effects
analysis: A practical application of functional modeling.
Appl Artif Intell 1995; 9: 33–44.
5. Qian L and Gero JS. Function–behavior–structure
paths and their role in analogy-based design. AI
EDAM 1996; 10: 289–312.
6. Umeda Y, Ishii M, Yoshioka M, et al. Supporting con-
ceptual design based on the function-behavior-state
modeler. AI EDAM 1996; 10: 275–288.
7. Chakrabarti A and Bligh TP. A scheme for functional
reasoning in conceptual design. Design Stud 2001; 22:
493–517.
8. Campbell MI, Cagan J and Kotovsky K. The A-Design
approach to managing automated design synthesis. Res
Eng Des 2003; 14: 12–24.
9. Kurtoglu T and Tumer IY. A graph-based fault identi-
fication and propagation framework for functional
design of complex systems. J Mech Des 2008; 130:
051401–8.
10. Goel AK, Rugaber S and Vattam S. Structure, behav-
ior, and function of complex systems: The structure,
behavior, and function modeling language. AI EDAM
2009; 23: 23–35.
11. Chen Y, Liu Z-L and Xie Y-B. A knowledge-
based framework for creative conceptual design of
multi-disciplinary systems. Comput-Aid Des 2012; 44:
146–153.
12. Mutha C, Jensen D, Tumer I, et al. An integrated multi-
domain functional failure and propagation analysis
approach for safe system design. AI EDAM 2013; 27:
317–347.
Zhao et al.
13. Eisenbart B, Gericke K and Blessing L. An analysis of
functional modeling approaches across disciplines. AI
EDAM 2013; 27: 281–289.
14. Tomiyama T, Van Beek TJ, Alvarez Cabrera AA, et al.
Making function modeling practically usable. AI
EDAM 2013; 27: 301–309.
15. Sen C, Summers JD and Mocko GM. Physics-based
reasoning in conceptual design using a formal represen-
tation of function structure graphs. J Comput Inform
Sci Eng 2013; 13: 011008–12.
16. Iwasaki Y and Simon HA. Causality in device behavior.
Artif Intell 1986; 29: 3–32.
17. Chandrasekaran B and Josephson JR. Function in
device representation. Eng Comput 2000; 16: 162–177.
18. Bracewell RH and Sharpe J. Functional descriptions
used in computer support for qualitative scheme
generation—‘‘Schemebuilder’’. AI EDAM 1996; 10:
333–345.
19. Campbell MI, Cagan J and Kotovsky K. Agent-based
synthesis of electromechanical design configurations.
J Mech Des 2000; 122: 61–69.
20. Sridharan P and Campbell MI. A study on the gram-
matical construction of function structures. AI EDAM
2005; 19: 139–160.
21. Kurtoglu T, Swantner A and Campbell MI. Automating
the conceptual design process: ‘‘From black box to
component selection’’. AI EDAM 2010; 24: 49–62.
2317
22. Aurisicchio M, Bracewell R and Armstrong G. The
function analysis diagram: Intended benefits and coex-
istence with other functional models. AI EDAM 2013;
27: 249–257.
23. Stone RB, Tumer IY and Van Wie M. The function-
failure design method. J Mech Des 2005; 127: 397–407.
24. Jensen DC, Bello O, Hoyle C, et al. Reasoning about
system-level failure behavior from large sets of func-
tion-based simulations. AI EDAM 2014; 28: 385–398.
25. Mhenni F, Choley J, Riviere A, et al. SysML and safety
analysis for mechatronic systems. In: 9th France_Japan
& 7th Europe_Asia Congress on mechatronics and
research and education in mechatronics (REM), 2012,
pp.417–424. New York: IEEE.
26. Cao Y, Liu Y, Fan H, et al. SysML–based uniform
behavior modeling and automated mapping of design
and simulation model for complex mechatronics.
Comput–Aid Des 2013; 45: 764–776.
27. Pahl G, Beitz W, Feldhusen J, et al. Conceptual design.
In: Engineering design: A systematic approach. 3rd ed.
London: Springer, 2007, pp.159–225.