1. INTRODUCTION
Design research proposes function modeling as a means to support the development of early design concepts (see, e.g., Chakrabarti & Bligh, Reference Chakrabarti and Bligh2001; Crilly, Reference Crilly2010; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016a , for an overview). Function modeling is commonly used to describe a system at an abstract level in terms of its distinct effectual causes and relationships, in order to achieve a desired overall behavior, purpose, or task (cf. Warell, Reference Warell1999; Chiang et al., Reference Chiang, Pennathur and Mital2001; Maier & Fadel, Reference Maier and Fadel2001; Chandrasekaran, Reference Chandrasekaran2005, Ericson & Larsson, Reference Ericson and Larsson2005; Crilly, Reference Crilly2010; Aurisicchio et al., Reference Aurisicchio, Eng, Ortiz, Childs and Bracewell2011). Scholars highlight its potential to facilitate concept development through providing means for the representation of the numerous required functions and their dependencies. Furthermore, function modeling helps to ensure all these functions are addressed in the design process and provides a more systematic approach for gradual solution space exploration and attendant solution synthesis (Blessing & Upton, Reference Blessing and Upton1997; US Department of Defense, 2001; Gausemeier et al., Reference Gausemeier, Frank, Donoth and Kahl2009; Caldwell et al., Reference Caldwell, Sen, Mocko and Summers2011; Sen et al., Reference Sen, Summers and Mocko2013, Tomiyama et al., Reference Tomiyama, van Beek, Alvarez Cabrera, Komoto and D'Amelio2013). Later on in the process, it can support the analysis of function and requirement fulfillment by the design concept. This latter benefit is valuable not only for emergent design solutions but also even more so when making sense of and trying to adapt an existent design, such as in redesign or variant design projects (Maher & Tang, Reference Maher and Tang2003; Far & Elamy, Reference Far and Elamy2005; Andreasen et al., Reference Andreasen, Hansen and Cash2015; Eisenbart, Gericke, et al., Reference Eisenbart, Gericke and Blessing2015). More recently, researchers have started discussing an additional benefit of function modeling, namely, that it assists in establishing a shared understanding between collaborating designers from different disciplines, as it is intrinsically abstract and thus discipline unspecific. Erden et al., in particular, suggest that “the barriers between … disciplines can be overcome by using [a] common language of functionality” (Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008, p. 147, see also Tukker et al., Reference Tukker, van den Berg, Tischner, Tukker and Tischner2006; Müller et al., Reference Müller, Schmidt-Kretschmer and Blessing2007; van Beek & Tomiyama, Reference van Beek and Tomiyama2009). There is initial empirical evidence for the suggested benefits of function modeling to engineering design practice (see Kurfman et al., Reference Kurfman, Stone, Rajan and Wood2001, Reference Kurfman, Stock, Stone, Rajan and Wood2003; Caldwell et al., Reference Caldwell, Sen, Mocko and Summers2011; Srinivasan et al., Reference Srinivasan, Chakrabarti and Lindemann2012; Sen et al., Reference Sen, Summers and Mocko2013). Yet scholars have noted that function modeling has not been widely taken up in industry (see, e.g., Aurisicchio et al., Reference Aurisicchio, Bracewell and Armstrong2012; Tomiyama et al., Reference Tomiyama, van Beek, Alvarez Cabrera, Komoto and D'Amelio2013). The very characteristic that makes it applicable across disciplinary barriers, that is, its abstract nature, seems to also raise doubts about its practical applicability, deterring companies or individual designers from adopting it in their daily practices (as suggested by Tomiyama et al., Reference Tomiyama, Gu, Jin, Lutters, Kind and Kimura2009; Booth et al., Reference Booth, Reid, Eckert and Ramani2015; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016b ). Moreover, existing function modeling approaches incorporate different levels of abstraction and viewpoints in their descriptions of functionality (see Erden et al., Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008; Crilly, Reference Crilly2010; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2013a , for an overview). The differences provide evidence of how versatile the (intended) utilization of function modeling can be. We agree with various scholars contributing to this Special Issue that each function model has its particular advantages and shortcomings. Industrial practice is excessively diversified in terms of contextual requirements, aims, and adopted processes; this automatically begs the question which of the extant models should be selected for application in a specific situation. Here is where benchmarking between function modeling approaches can provide a vital contribution to designers in making a well-founded choice on which model(s) to select (Summers et al., Reference Summers, Eckert and Goel2013).
This article contributes to this discussion in two ways. First, we explain a new function modeling approach, the integrated function modeling (IFM) framework, which specifically aims to integrate and interlink a large part of the diverse contents and concepts of function modeling from different fields of study (see Section 2). Second, in Section 4, we comparatively investigate the IFM framework's respective capabilities in relation to function structures (as proposed by Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007). These are used as reference for this analysis as they represent one of the most widespread function modeling approaches in research and practice. Both function structures and the IFM framework are exemplarily applied for function modeling of a glue gun. The specific application of the function models in the given example is compared with respect to the benchmarking protocol by Summers et al. (Reference Summers, Eckert and Goel2013), which has been used earlier in relation to this Special Issue, in order to enhance comparability. Section 5 discusses the models, their strengths and weaknesses, and implications for their use in practice. The identified characteristics of the IFM framework will be used to guide future work that aims to improve the framework and its uptake by industry. Section 7 concludes the paper and suggests implications for further advancement of this research.
2. FUNCTION MODELING
Research has produced a plethora of function models over the years (see Erden et al., Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008; Crilly, Reference Crilly2010; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2013a ; Crilly, Reference Crilly2015, for an overview). However, one of the most common representations is the use of verb/noun combinations in relation to flows of operands (i.e., the nouns) and their transformation (the verbs) between the input and the output of a system. This is incorporated, for instance, in the widespread function structure after Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007, see Fig. 1).Footnote 1
Fig. 1. Schema of function structures after Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007).
The underlying paradigm has been widely adopted in mechanical engineering literature (see, e.g., Roozenburg & Eekels, Reference Roozenburg and Eekels1995; Stone & Wood, Reference Stone and Wood2000; Ulrich & Eppinger, Reference Ulrich and Eppinger2008; Ullman, Reference Ullman2010) and in certain interdisciplinary design approaches (see, e.g., VDI, 2004; Cross, Reference Cross2008; Gausemeier et al., Reference Gausemeier, Frank, Donoth and Kahl2009). Function modeling in disciplines like software development, service development, and product-service system (PSS) design predominantly builds on the flow in time (instead of operands) in order to depict procedural relations between individual functions and/or service activities (see, e.g., Shostack, Reference Shostack1982; US Department of Defense, 2001; Kruchten, Reference Kruchten2004; Weilkiens, Reference Weilkiens2008; Watanabe et al., Reference Watanabe, Mikoshiba, Tateyama, Shimomura and Kimita2011). Electrical engineering, as a final example, tends to focus on distinct states and their transitions to deduce their logical devolution and implementation in the final design (see, e.g., Dewey, Reference Dewey and Dorf2000; Scheffer et al., Reference Scheffer, Lavagno and Martin2006). What this shows is that function modeling is fairly diverse and can vary quite noticeably between disciplines, especially when it comes to the content of each approach (discussed in detail by Eisenbart et al., Reference Eisenbart, Gericke and Blessing2013a ).
Scholars such as Erden et al. (Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008), Vermaas (Reference Vermaas2011, Reference Vermaas2013), Carrara et al. (Reference Carrara, Garbacz and Vermaas2011), and Garbacz et al. (Reference Garbacz, Borgo, Carrara and Vermaas2011) argue that the multifariousness of function models in itself indicates the vast interest of the research community in the topic. Due to this diversity, however, finding a common theorization of what function and function modeling really entails in design is no easy task. Such a variety of definitions of function can be found in the literature that we will focus here on drawing upon prior work comparing them (see, e.g., Warell, Reference Warell1999; Chandrasekaran & Josephson, Reference Chandrasekaran and Josephson2000; Chiang et al., Reference Chiang, Pennathur and Mital2001; Maier & Fadel, Reference Maier and Fadel2001; Deng, Reference Deng2002; Chandrasekaran, Reference Chandrasekaran2005; Ericson & Larsson, Reference Ericson and Larsson2005; Vermaas, Reference Vermaas2009; Crilly, Reference Crilly2010; Aurisicchio et al., Reference Aurisicchio, Eng, Ortiz, Childs and Bracewell2011; Carrara et al., Reference Carrara, Garbacz and Vermaas2011; Goel, Reference Goel2013; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016a , for comprehensive discussions of the different meanings of function conveyed in engineering design). Many of these scholars sought to find a common denominator in extant definitions of function in an attempt to unify or relate between them, respectively. More recently, however, scholars have started to accept or even embrace that function “is a term that has a number of co-existing meanings, which are used side-by-side in engineering” (Vermaas, Reference Vermaas2011, p. 98, see also Carrara et al., Reference Carrara, Garbacz and Vermaas2011). Each definition has its specific place in design insofar as it relates to its originators’ interpretation of and viewpoint on function as a concept (cf. Chittaro & Kumar, Reference Chittaro and Kumar1998; Chandrasekaran & Josephson, Reference Chandrasekaran and Josephson2000; Deng, Reference Deng2002; Chandrasekaran, Reference Chandrasekaran2005). Vermaas (Reference Vermaas2009, Reference Vermaas2013) goes on to derive a set of three notions of function that he considers to be archetypical and present in some way in any (formal) function modeling or reasoning approach:
-
1. behavior-related notion: function as the intended behavior of an entity
-
2. outcome-related notion: functions as the desired effects of the behavior of an entity
-
3. task- or goal-related notion: function as the purpose for which an entity is designed
An entity's behavior may serve a specific, envisaged purpose. Yet, in many cases, it may contribute to entirely different, unforeseen use plans (cf. Houkes & Vermaas, Reference Houkes and Vermaas2010), which are related to so-called affordances (cf. Maier & Fadel, Reference Maier and Fadel2001). Affordances cover the entirety of uses that a system can be put to due to its specific characteristics (after Weber, Reference Weber2007), though these uses may not have been originally intended as such by the designers (Brown & Blessing, Reference Brown and Blessing2005).
We follow the idea of Vermaas and others that different views or notions of what function is exist side by side. We already discussed how existing function models vary in terms of content and morphology and thereby reflect coexisting notions and viewpoints. Although this variety is well known, practitioners cannot take advantage of this, as the respective advantages of these modeling approaches have not been explicated. This paper contributes to this gap, by comparing function structures after Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007) with the IFM framework. Function structures are considered to be well known and will therefore not be described in detail here. The IFM framework is still relatively new and is thus briefly described in the following.
3. THE IFM FRAMEWORK
The IFM framework draws from comprehensive reviews of existing function modeling approaches found in textbooks and industrial practice (see Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016a ). It sets out to contribute to design practice by linking diverse contents addressed in function modeling approaches across disciplines, while allowing for flexible adaptation (augmentation or tailoring). This means that designers can focus on the contents required for a specific design task, while disregarding other contents. Hence, modeling efforts and complexity can be adapted to the requirements of a specific project. Specific adaptations to match different needs in function modeling are discussed by Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2013b ) from an ontological viewpoint.
The IFM framework is a representational approach that is set up as a combination of modular dependency structure matrices (see Kreimeyer & Lindemann, Reference Kreimeyer and Lindemann2011) and flow modeling. An overview of the framework is provided in Figure 2. In its kernel, the framework consists of adjacently placed and inherently linked views. A specific instance of the IFM framework is called an integrated function (IF) model. An IF model can consist of either all views described by the IFM framework or a subset thereof, depending on which specific entities comprising the framework are relevant in a concrete modeling endeavor. The different views are briefly described in Table 1.
Fig. 2. Schema of the integrated function modeling framework.
Table 1. Associated views in the IFM framework
Note: Adapted from Eisenbart, Gericke, et al. (Reference Eisenbart, Gericke and Blessing2015).
The framework is centered around the process flow view (see Fig. 2), which presents the qualitative flow of different types of processes. This was found to be a central representational approach cutting across many disciplinary boundaries in function modeling; it thus serves as a vantage point for an integrative modeling approach (see Eisenbart et al., Reference Eisenbart, Gericke and Blessing2013a ). Such processes can be transformational (which is, for instance, intrinsic to function structures after Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007, and other modeling approaches), but also address interaction processes, human activities, and other major aspects of software, services, and related disciplines, as discussed before. The remaining views complement a function model generated with the IFM framework and eventually arrive at a comprehensive description of the functionality of a modeled entity. Detailed descriptions of the framework and its practical application are provided in Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2013a , Reference Eisenbart, Gericke and Blessing2016a ).
The entities encompassed in the IFM framework comprise use cases, transformation and interaction processes, effects, states, operands, and actors. Use cases represent different scenarios of applying the technical system for a specific purpose (e.g., fulfilling a goal, changing the state of the system or user). For every relevant use case, a new set of views is created. Transformation processes specify technical and/or human processes that (may) cause a change of state of operands or actors. Therein, processes rely on their underlying physiochemical effects. Operands (as with the Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007, approach) are specifications of energy, material, and signals. Actors comprise stakeholders (referring to any human or other animate being), technical (sub)systems (which may be hardware and/or software), and parts of the environment that actively or passively contribute to function fulfillment. Finally, interaction processes describe “cross-boundary” interactions between different actors jointly contributing to function fulfillment (see Eder & Hosnedl, Reference Eder and Hosnedl2008).
Through its setup, the framework is intended to accommodate the perceiving function as related to the three archetypical notions of function derived by Vermaas (see above). At its core, the framework centers around the representation of processes and their flows (see Fig. 2), incorporating the notion of function as the (intended) behavior of a system. Explicit visualization of the states of operands and actors directly relates to the notion of function as the effects of an exhibited behavior by virtue of linking these to the associated transformation and interaction processes and the specific changes resulting from them. Finally, use cases intrinsically derive from the distinct applications that a system is put to in relation to users and their respective use plan or scenario, which corresponds to the notion of function as the purpose of a system or artifact (cf. Eder & Hosnedl, Reference Eder and Hosnedl2008; Houkes & Vermaas, Reference Houkes and Vermaas2010; Vermaas, Reference Vermaas2013).
4. BENCHMARKING STUDY DESIGN
Most function modeling approaches are meant to support different types of design tasks, for example, original design, evolutionary design, or reverse engineering (Summers et al., Reference Summers, Eckert and Goel2013). The information captured in the models can facilitate different activities along the product life cycle (Gericke, Qureshi, et al., Reference Gericke, Qureshi and Blessing2013). Therefore, benchmarking of function modeling approaches is dependent on the design task and the purpose of its creation and utilization. Summers et al. (Reference Summers, Eckert and Goel2013) provide a protocol for benchmarking of function modeling approaches and propose a categorization of related classification problems by precedence. The proposed protocol aims to support benchmarking of modeling approaches rather than function models (i.e., specific instances of the modeling approaches), and thus supports systematic identification of conceptual improvement potentials in relation to function modeling approaches, and meta-analysis of multiple benchmarks.
The benchmarking study presented in the following aims at comparing two function modeling approaches: function structures as described in Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007) and the IFM framework introduced earlier.
4.1. Benchmarking problem
Design problems can differ in many dimensions such as complexity, novelty, interdependence, and contradictions of goals and requirements (see Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007; Ulrich & Eppinger, Reference Ulrich and Eppinger2008; Gericke, Meissner, et al., Reference Gericke, Meissner and Paetzold2013). In order to allow a systematic comparison of benchmarking studies, a limited set of criteria is required covering a relevant and sufficiently diverse area of real design problems.
The function modeling challenge that is used for benchmarking is a reverse engineering problem of an existing product of low complexity, which has been studied by other scholars in the past, thus facilitating comparability of the obtained insights. The selected case example is a Pattex Hotmelt Glue Gun (see Fig. 3) similar to the one used in the workshop held at the International Conference on Engineering Design in Milan 2015, which seeded this Special Issue.
Fig. 3. The glue gun.
The glue gun uses electrical energy to melt a hot-melt glue stick and a mechanical feed mechanism to control the extrusion rate of the melted glue. The temperature of the thermoplastic adhesive (i.e., the glue stick) affects the achieved bonding strength. Once the melted glue solidifies, it reaches its final bonding strength within a few seconds. The primary application of such glue guns is for crafts, arts, or related activities.
4.2. Benchmarking protocol
As a precondition for later meta-studies, the individual studies need to use the same or similar categories for comparison. Therefore, this study uses the benchmarking protocol proposed by Summers et al. (Reference Summers, Eckert and Goel2013), which is explained in Section 4.2.1. This set of criteria is complemented by a comparison of the modeled content (see Section 4.2.2) that is based on the classification proposed by Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2016a ).
4.2.1. Representation, modeling, cognitive dimension, and reasoning characteristics
Summers et al. (Reference Summers, Eckert and Goel2013) propose a set of criteria covering the following categories: representation characteristics, modeling characteristics, cognitive dimension characteristics, and reasoning characteristics. Representation characteristics cover the used vocabulary and grammar of the modeling approach. Modeling characteristics describe the way a modeler creates a model, for example, considering modeling strategies and tool support. Cognitive dimension characteristics allow the investigation of usability issues of function modeling issues. Cognitive dimension characteristics, used in human–computer interaction research, were adapted to function modelling. Reasoning characteristics expand from cognitive dimension characteristics and model content relating to the ability of function modeling approaches to support contextualization of the modeled system and modeling distribution of system-level functions to multiple elements. Table 2 consolidates the explanations of the characteristics.
Table 2. Criteria for function modeling benchmarking after Summers et al. (Reference Summers, Eckert and Goel2013)
4.2.2. Perspectives in function modeling approaches
The reasoning characteristics as defined in Table 2 do not cover all entities and modeling characteristics that have been identified to be represented in function modeling approaches. We will use the original set of reasoning characteristics as proposed by Summers et al. (Reference Summers, Eckert and Goel2013) but expand the analysis with a comparison of types of content covered by the modeling approaches. We use a set of modeling perspectives in this analysis (see Table 3), which are derived from a comprehensive analysis of function modeling approaches across multiple disciplines by Eisenbart et al. (Reference Eisenbart, Blessing and Gericke2012, Reference Eisenbart, Gericke and Blessing2013a ) building on extant research by Vermaas (Reference Vermaas2013), Eckert (Reference Eckert2013; see also Eckert et al., Reference Eckert, Alink and Albers2010), Erden et al. (Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008), Chandrasekaran (Reference Chandrasekaran2005), and others. Function modeling perspectives encompass the essence of different (types of) content addressed in function models and modeling approaches in bridging a large variety of disciplines. The IFM framework was developed with the goal to incorporate all modeling perspectives; thus, it will perform well with respect to coverage of them. However, we include the extended list of modeling perspectives, first, to point out more clearly the differences in coverage of both approaches, and second, to showcase that this list is a useful amendment to the protocol of Summers et al. (Reference Summers, Eckert and Goel2013). The perspectives are therefore considered appropriate for the purpose of a comparative analysis as intended here.
Table 3. Central function modeling perspectives after Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2013a)
4.3. Benchmarking process
Benchmarking between the two selected function modeling approaches (i.e., function structures and IFM framework) is based on specific models of the same reference product, namely, the glue gun. The respective models were created in a collaborative effort by the authors. Initially, one author created the models alone. Subsequently, the models were evaluated by the second author, discussed, and gradually refined until no further changes were required. As the authors have comprehensive experience with the use of function structures and developed the IFM framework, prior training in the use of the approaches was not necessary. All function structures were created using a tablet computer enabling freehand sketches, which was almost identical to creating a sketch on paper. The models based on the IFM framework were created using standard office spreadsheet software and a basic process modeling tool.
The models were subsequently evaluated individually by both authors based on the benchmarking criteria listed in Tables 2 and 3. The initial evaluation results were discussed until consensus was reached wherever necessary. Based on the individual evaluations, observations during modeling, and reflection on the modeling process, the function modeling approaches were compared regarding their particular strengths and weaknesses.
5. MODELING THE GLUE GUN
The reverse engineering approach taken for this study allowed for functional analysis of the existing product (the glue gun). As a first step preceding the creation of the function models, the glue gun was completely disassembled (see Fig. 3). The resulting single components and distinct assemblies were uniquely named to allow referencing and discussion among the authors. The disassembly was necessary to understand the interactions of assemblies and parts, thus to understand the flow of operands, that is, materials, energy, and signals. The function structure was created first, followed by the creation of the IF model of the glue gun using relevant parts of the IFM framework. Both resulting models and the associated modeling processes are represented in the following subsections.
5.1. Modeling the glue gun using a function structure
Modeling of the function structure followed the original propositions by Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007) and, hence, started by identifying the overall function of the glue gun and articulating a solution-neutral formulation of it. The purpose of the modeling activity was presumed to serve a reverse engineering project with the goal to analyze system functionality and to identify improvement potentials. Therefore, a decomposition of the overall function and a simultaneous analysis of assumptions that constrain the solution space were conducted. For every decomposition and detailing of the model, all assumptions, respectively, decisions that constrain the solution space, were documented complementary to the respective model. The initial overall function was decomposed three times and detailed multiple times. In total, five different models were subsequently created. The final model was then reworked for a better visual appearance (see Fig. 4).
Fig. 4. Modeling process of the function structure.
The solution-neutral formulation of the overall function of the glue gun is “connect parts” (see Fig. 5, left-hand side). The desired outcome of the use of the glue guns are “connected parts” and the input are “unconnected parts.”
Fig. 5. Overall function (left) first version and (right) second version.
An important assumption about the product is the used connection principle. The glue gun connects parts by bonding. Alternatives (on the same level of detail) would be form fit or force fit connections. An advantage of bonding is the absence of additional parts or connecting elements. As gluing, or adhesive bonding respectively, was chosen to connect parts instead of brazing and welding, further assumptions/constraints for the product are that the parts might not be allowed to be exposed to high temperatures, which go hand-in-hand with these processes. An alternative assumption would be that parts are not metallic, thus limiting applicable bonding techniques. Therefore, the overall function was reformulated into “glue parts” (see Fig. 5, right-hand side).
The next decomposition steps of the overall function entailed creating lists of subfunctions and auxiliary functions, and related underlying assumptions constraining the solution in such a way that the design converges into the studied glue gun (see Table 4). In the first step, it became clear that whatever glue is used the flow of material will require storing, application, moving, and dosing of the material (see Table 4, column describing third model). One assumption made at this point that affected the modeling activity noticeably is the definition of the system boundary, that is, excluding the user from the modeled system; thus, users are treated as external to the functional system that constitutes the glue gun.
Table 4. List of functions contributing to overall function “glue parts”
Probably the most important assumption is the choice of the glue, for this example the use of a thermoplastic adhesive formed as a cylindrical stick. The use of this type of glue requires thermal energy to change the state of matter from solid to liquid. Thus, several additional functions are required enabling the gluing of parts (see Table 4, column describing fourth model).
The third and the fourth models show the required functions for the overall function “glue parts” on different levels of details incorporating the assumptions made during each decomposition step. Both models are pure lists of main functions, auxiliary functions, and underlying assumptions that constrain the design. In the next step, the interdependencies (i.e., the flows of matter, energy, and signals) were added, resulting in a function structure. The function structure was modeled starting with what we consider the main operand flow by virtue of the overall function, that is, the flow of glue (material). The remaining flows and activities were modeled succeeding this step. The function structure was discussed between the authors and gradually refined afterward. The resulting function structure is shown in Figure 6. At this stage, the authors decided that further detailing, while being possible, was not expected to provide added benefit. Further detailing would make sense in case a rather specific analysis of the product, the transformation processes, or design alternatives was required by the designers, yet not for the purpose of the comparison shown here.
Fig. 6. (Final) function structure.
5.2. Modeling the glue gun using the IFM framework
For modeling the glue gun, not all of the views/contents in the IFM framework are required. As discussed earlier, depending on demand, only a selection of views may be needed depending on the specific purpose of modeling. For the example of the glue gun, the process flow view, actor view, state view, and interaction view were selected.
In accordance with recommendations by Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2016a ) and Andreasen et al. (Reference Andreasen, Hansen and Cash2015), modeling the glue gun with the IF model (the specific model based on the IFM framework) was set up starting with an identification of central use cases (see Fig. 7). Central use cases comprise the following: “prepare” (unpacking the glue gun and loading a glue stick), “use” (using the glue gun for gluing parts), “maintain” (cleaning the glue gun and checking for damages), and “repair” (disassemble and repair). The list of use cases constitutes the use case view.
Fig. 7. Modeling process of the integrated function model.
The model was detailed by moving from determining the central use cases envisaged to the specific interaction and transformation processes required within them. The process flow view represents the sequence of interaction and transformation processes that constitute a single use case, that is, the interdependencies between individual processes (connectors) and the temporal order (vertical axis) of these processes. For the comparison shown here, the remaining views of the IF model were created only for the use case of “use,” as the most relevant in accordance with the overall function fundamental to the function structure modeled earlier and thus critical to this comparison. Afterward, the process flow view (see Fig. 8) was generated by gradually defining the processes that constitute the selected use case by determining associated flows of operands and the sequence of processes, as well as the states of related operands (state view) until these were logically consistent and complete.
Fig. 8. Process flow view for the glue gun.
For the purpose of reverse engineering, we analyzed the system architecture and mutual impacts of parts in the glue gun, thus constituting the interaction view (see Fig. 9), by adding actors and their interdependencies. Each interaction between actors and operands is indicated with a “1.” The type of interaction is not specified in this model, but could be detailed if required.
Fig. 9. Interaction view.
We linked the interaction view (see Fig. 10) to the process flow view using the actor view and the state view (see Fig. 11). While the creation of the different views was done more or less sequentially, the refinement and check for consistency of the modeled views and (in extension) of the entire IF model was incorporated using the integrated model combining all generated views as shown in Figure 12.
Fig. 10. Expanded actor view.
Fig. 11. Reduced state view.
Fig. 12. Integrated function model of the glue gun.
5.2.1. Adaptation of the IFM framework
The creation of the IF model illustrating the glue gun was facilitated by slight structural adaptations based on the original IFM framework. Adaptation was done along the modeling process to match the needs of this particular modeling activity (see Fig. 13). This encompasses a simplification of the use case view as only one use case was modeled in more detail in the presented study. The interaction view has been placed on the right-hand side, solely because this simplified the manipulation of the model in the used software tool operatively. At the same time, the actors and operands placement in the matrix was swapped as this allows an easier identification of user and operand involvement in the individual processes, thus facilitating the readability of the actor view. The actor view has been expanded to include actors and operands, as involvement of operands in processes was important for the analyzed system. The state view has been reduced by limiting the indication of states to operands and omitting indication of states of actors as the temperature and consistency of the glue is the most relevant state change. These adaptations were perceived useful, as the indication of operands involvement in the actor view seemed necessary for checking consistency of the process flow view while the modeling of state changes of actors in the state view seemed not necessary for this simple example.
Fig. 13. Adaptation of the integrated function modeling framework.
6. COMPARISON AND DISCUSSION OF THE MODELING APPROACHES
The needs of practitioners differ depending on the individual context. Thus, the question remains which modeling approach is best suited to supporting design activities in a particular context. Function modeling approaches can be compared on the basis of numerous characteristics that have a profound influence on their suitability (see Tables 2, 3). Some factors that stand out will be discussed in the following sections.
The discussion comprises two levels (wherever possible). For each main theme, the potential of the function modeling approaches is discussed more generally. Wherever possible, the differences found in the specific generated models of the glue gun, that is, the function structure and the IF model (see Figs. 6, 12), will be discussed in more detail and set into relation to the general discussion. In order to distinguish clearly between modeling approaches and specific models of the glue gun, the approaches are referred to as the IFM framework and function structures (plural), whereas specific models are referred to as the IF model and function structure (singular). Both parts of the discussion contribute to a more holistic comparison of both function modeling approaches. Findings that relate to the modeling approaches are summarized in the tables that relate to the individual sections of the discussion.
6.1. Scope and content
The perspectives taken for function reasoning and function modeling differ between design disciplines (Eisenbart et al., Reference Eisenbart, Blessing and Gericke2012). The type of content addressed in function models varies across disciplines, and therefore most function modeling approaches are only used in one or few particular disciplines. Function structures, most prominently representing transformation processes, primarily meet the needs of mechanical engineers (which is not to say others cannot use them). The IFM framework, in contrast, was designed to integrate contents found in function models across a broad range of (engineering) disciplines and can thus be used in an interdisciplinary context (including mechanical engineering, software design, service design, mechatronics, and PSS design), where it is imperative for designers to overcome limitations of individual disciplines (see Table 5).
Table 5. Comparison of scope and content
In the IF model (see Fig. 12), the vertical direction in the process flow view (see Fig. 8) illustrates the causal flow between transformation processes. The sequence and parallelism between different transformation processes and effects is derived from the chronological succession, in which operands are transformed from system input to output. The concept of causal flows in the process flow view similarly applies to the function structure (see Fig. 6), though here it concerns the flow of operands and changes in aspects other than the temporal sequences.
The IFM framework was developed with the goal of incorporating all modeling perspectives presented in Table 3; thus, it is no surprise that the framework covers all the perspectives listed in Table 5 (lower part of the table). However, the list of modeling perspectives is included in this comparison to more clearly highlight the differences between both approaches.
In function structures, transformation processes and effects are generally not separated, but are interconnected and modeled in the same representation. The IFM framework allows linking additional views such as the effect view to support detailed analyses of specific transformation processes; this was not carried out in the IF model of the glue gun here, but can be added seamlessly in a concrete design project, if required.
6.2. Adaptability and reasoning support
Function structures do not inherently allow for substantial flexibility, that is, modification and adaptation. The literature explicitly recommends the rigorous use of the proposed notations to help users interpret models more easily and consistently. In line with this, the created function structure is comprehensive, as per its original conceptualization (see Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007).
The modular and interlinked setup of the IFM framework supports analogue mapping between the different views, and thus between different entities contributing to function fulfillment. Depending on the modeling task, the use of the different views can flexibly be adapted to the specific demands. As only simple modeling notations are used for creating the matrices and flowcharts, interpretation of the content is seamless. Even following adaptation of the IFM framework's structure (see Figs. 12, 13) and morphology, the model supports consistent interpretation by different model users.
The consistent interpretation of function structures depends on the experience of modelers and model users and on the consistent use of the proposed notations during model building. The proposed notations for function structures are per se not flexible, and thus should enable consistent interpretation; however, the morphology of the model is not regulated, which makes it often difficult to derive a consistent interpretation (see Table 6). In the created IF model of the glue gun, we made several slight adaptations to improve its applicability to the given modeling task. The authors are used to working with the model, yet it is aspired that novices adopting the model would be able to learn how to use it rather quickly as well, given that the model is entirely based on well-known matrices and simple flow modeling.
Table 6. Comparison of adaptability and reasoning support
6.3. Visualization and manipulation capabilities
The separation of the modeled entities into different views in the IFM framework and indication of interdependencies facilitates the search for flaws and missing information and eases the gradual development of a model, as shown for the glue gun example (see Fig. 7). When modeling, or engaging in function analysis for an existing system, the setup of interlinked matrices visually facilitates logical consistency analysis across views. This can be achieved through deductive logic and continuous comparison of whether the contents in each view are inherently consistent. For instance, in the case of the “heat glue” process, it can be concluded that there must be an associated operand “glue” whose temperature in the input state is lower than in the output state.
Function structures are less rigidly structured, which would help designers to build the model, and thus designers have to scrutinize model content and model structure conjointly. The IFM framework in turn allows designers to focus on modeled content more easily.
Such reasoning supports gradually entering information into the views of the IFM framework concurrently during model generation. It can be similarly applied during change management, for instance, to ensure that the model maintains its logical consistency. Compared to function structures, this facilitates model manipulation, which is supported by the use of matrices for indicating interdependencies, which can be manipulated and compared easily, compared to a purely graphical process model, and indication of interdependencies as done by function structures (see Table 7).
Table 7. Comparison of visualization and manipulation capabilities
6.4. Interconnectedness
Function modeling has been used in multiple stages of the design process (product planning and task clarification, conceptual design, and embodiment design) for different purposes (analysis of the problem, synthesis of the solution, and documentation; Gericke, Qureshi, et al., Reference Gericke, Qureshi and Blessing2013, Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016b ). Hence, the potential benefits yielded by a function model depend to some extent on its ability to be embedded in a meaningful way in the design process, that is, to link function modeling to other design activities (to link the contents to other engineering models/documents) and to use the modeled information in multiple design steps/stages.
The functions modeled in function structures serve as a starting point for the subsequent search for working principles enabling respective functions. Mapping of functions and matching alternative working principles can be supported using morphological charts. A consistency analysis of combined working principles based on the flow of operands as modeled in the function structure may afterward help to identify compatible working principles that can be integrated into a working structure, that is, a solution concept (see Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007).
The interconnectedness of the IFM framework to other engineering models goes beyond this endeavor (see Table 8). It enables adaptation, including adding complementary views, representing additional information such as cost information and risk assessment data. The “open” interface to other models, which can be linked to one of the views via the included entities, enables the application of established analysis methods for dependency structure matrices (see Lindemann et al., Reference Lindemann, Maurer and Braun2009; Eppinger & Browning, Reference Eppinger and Browning2012) to system functionality. These include (but are not limited to; see Eisenbart, Gericke, et al., Reference Eisenbart, Gericke and Blessing2015) the following:
-
• conflict analysis between (mutually dependent/exclusive) entities;
-
• change prediction and effect analysis concerning elaboration on the effects of implementing changes to operands and actors, provided functionality, use case fulfilment, and so on;
-
• evaluating optimization potentials such as modularization opportunities or comparative analysis of solution variants;
-
• criticality and failure effect analysis of functions and actors from system level down to individual elements and their interactions; and
-
• cost analysis and prediction in change management.
The main advantage of the IF model (see Fig. 12) over the function structure (see Fig. 6) for the presented example is the integration of product architecture information (interaction view, Fig. 9) via the actor view (Fig. 10) and state view (Fig. 11). This integration of product architecture information allows the linking of many analyses in later design phases to the functional description of the product (see Eisenbart et al., Reference Eisenbart, Gericke and Blessing2016a ).
Table 8. Comparison of interconnectedness
The different models of the glue gun (see Figs. 6, 12) also show that linking of function models is as important as linking function models to other engineering models. It is important as the modeled content may originate from different disciplines, which prefer to use specific modeling approaches before integrating that information into other models. An example of how the IFM framework enables a discipline-specific model is shown by the possible evolution of the IF model's process flow view (see Fig. 8) out of the function structure (see Fig. 6). Furthermore, it is important as knowledge gain during function modeling itself is a gradual process, and thus information is complemented stepwise. Function structures allow such gradual information accumulation as shown for the glue gun example, but they are limited compared to the IFM framework, as only few perspectives (entities) are included (see Table 5).
6.5. Modeling characteristics
Both modeling approaches allow detailing (decomposing) certain parts of the respective function models, while other parts are modeled at an abstract level (Table 9). The evolution of the function structure starting with the overall function (see Fig. 5) of the glue gun and its stepwise decomposition that results in the function structure shown in Figure 6 illustrate this very well. A similar approach can also be applied for creating an IF model with more or less detail than depicted in Figure 12. However, in this article, only one version of the IF model is shown.
The available tool support for modeling function structures is limited to simple graphical modeling tools or paper-based sketches, making editing a cumbersome activity. The use of spreadsheet software for modeling with the IFM framework allows gradual detailing of parts of the model while keeping other parts more abstract. This reduces the effort for refining and changing the model and hence contributes to the usability of the modeling approach. The effort for creating the IF model shown in Figure 12 compared to the effort for creating the function structure shown in Figure 6 was around four times higher. This is hardly surprising seeing that the IF model contains much more information about the analyzed system, the glue gun, and provides more opportunities for later use during the design process. From our perspective, this justifies the extra effort if the designers intend to use it later. Conversely, if function modeling is mainly used as a means for documentation or an early conversation starter in a design step process, such detail may not be required and function structures might be better suited. Yet, in the concrete benchmark problem addressed here, that is, reverse engineering of the glue gun, the IF model provides additional benefits, as the link between the system's functionality and its product architecture is fully defined. This support for comprehensive analysis should inherently help in making design changes more plannable.
The readability of function structures depends mainly on the number of modeled flows and the organization of the model. More experienced modelers will manage to make a function structure easy to read. As function structures are gradually built, the organization of the modeled elements is often suboptimal in the first version, and thus it is necessary to revise the model to optimize readability, even though this requires extra time. We did the same with the function structure of the glue gun.
In comparison, the complexity and readability of an IF model is determined to a large extent by the level of detail of the interaction view. The number of elements modeled in the interaction view, which basically represents the system architecture, affects the size of the matrix. In order to keep the complexity low and improve readability, modeling at a subsystem level might be sufficient for most modelling purposes. For the glue gun, which is not complex, the interaction view (see Fig. 9) is detailed, representing almost every single part. If required for specific purposes, the granularity of the model can be changed for particular subsystems. Modern spreadsheet software allows balancing the granularity of the model and its readability by allowing partial fading of the model, if desired.
6.6. Effects of premature commitments: Solution-neutral function modeling
Function modeling is a means to support and document the results of function reasoning. This helps designers to reflect on the modeled information, revise and refine content, and gradually complement the model by expanding and detailing it as required (Table 10). This is exemplified for both modeling approaches. The gradual detailing of a function model is shown based on the function structure in Figures 5 and 6 and Table 4 and for the evolving IF model in Figures 8–12.
Completely solution-neutral modeling of the functionality of a system is almost impossible. The model building process requires making assumptions that will constrain the solution space (see Fig. 4). The more detailed the model becomes, the more assumptions need to be made; thus, designers need to balance the level of detail of a model (its granularity) and the constraints for the solution space.
A problem with function modeling is that the documentation of such assumptions is usually not considered to comprise part of a function model, even though the assumptions affect the building and understanding of the model, which we experienced very clearly in setting up the function structure of the glue gun. A consequence of this is that the underlying assumptions often are neither made explicit nor documented, and thus this information is lost even though it is important for understanding the model in the way intended by the modeler. Identifying such assumptions is a crucial part of the reverse engineering process. A clear understanding of assumptions and constraints that are likely to have guided the original design process provides insights for possible design interventions during the redesign/modification of the analyzed system. To ease this process, the shown function structure (see Fig. 6) was created starting with the overall function fulfilled by the glue gun (see Fig. 5).
Whether unconscious assumptions/design decisions affect the design process depends greatly on the modeler (i.e., the designer), the selected function modeling approach, and how the model is used. If the model is understood as a sketch representing one of many alternatives, this will become less of a problem, as the designer (or team) needs to evaluate alternative function models and the convergence of the solution space is based on a comparison of alternatives. If the function model is understood as solution neutral in itself, thus neglecting the constraining effect of unconscious assumptions, the solution space is reduced and design alternatives are excluded in an (probably very often entirely) unconscious manner.
Function structures as described by Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007) do not require the documentation of assumptions as shown in Figure 4 and included in Table 4. We documented said tacit knowledge (as per the discussed assumptions) for the glue gun example as a complementing analysis serving the goal of reverse engineering this product. Even though not prescribed in the literature, assumptions can of course be documented, and thus this limitation was overcome. However, it remains challenging to compare alternative function structures because the used modeling notations do not regulate the organization and modeling of flows.
The IF model, while also not being solution neutral, is expected to make the designer more conscious of the gradual convergence of the solution space by virtue of the saliency of allocated solution elements. This is, after all, the manifestation of the decisions made in relation to which components, subsystems, or human actors have been selected by the designers to fulfill the desired functionality.
6.7. Limitations of the comparison
The comparison is limited insofar as it considers only one particular function modeling task, namely, the reverse engineering of a glue gun, a low-complexity product. For a comprehensive comparison of the two selected function modeling approaches, other challenges embedded in the synthesis of original designs or evolutionary design of more complex systems need further attention. Furthermore, a metastudy of multiple benchmarks on different function modeling challenges would enable deriving strengths and weaknesses of further function modeling approaches for comparison purposes.
The benchmarking protocol proposed by Summers et al. (Reference Summers, Eckert and Goel2013) does not provide metrics for the evaluation of the compiled characteristics. Therefore, the presented results are relative by nature and rely solely on our personal observations of their application in the past (in industry workshops and teaching) and on our personal reflection during modeling the glue gun. While we, as the authors and developers of the IFM framework, may have unconsciously looked more favorably onto the IFM framework, we tried to base our evaluation, wherever possible, on the concrete models created. Furthermore, we provided references to complementing studies on the use of the IFM framework where appropriate in order to support our assessments. This includes applications to more complex systems and other types of modeling challenges. We hope to have been able to provide a compelling and critical comparison of both modeling approaches that may trigger interest in the wider research community.
Benchmarking of function modeling approaches is a new endeavor. The currently used benchmarking protocol will need refinement after it has been applied to several modeling approaches. A challenge in using the protocol has been the partial overlap of some characteristics, which belong to different categories, and their explanations, which sometimes leave room for interpretation. We complemented the proposed set of reasoning characteristics by a set of modeling perspectives in order to enable a more precise comparison of the modeled content. During the analysis, we identified further criteria that would be relevant for a benchmark, such as the effort required for learning a particular modeling approach, effort (time) required for creating models, and maintenance of fluency in solution finding (avoiding early fixation). We expect that the use of the benchmarking protocol in other comparisons will provide additional feedback, maybe even contradicting our observations.
7. CONCLUSION
It is possible that no other type of design method has produced such a variety of modeling approaches as function modeling. Each of these approaches has specific merits for modeling or analyzing products, services, or their combination (Wallace, Reference Wallace and Birkofer2011; Daalhuizen, Reference Daalhuizen2014). Yet their specific advantages are rarely made explicit. This begs the question of how designers should choose between approaches when facing a specific design task. Modeling approaches differ in terms of the prevalent design context targeted, novelty or complexity of a design task, as well as stages of a design project in which they are particularly useful (e.g., product planning as opposed to conceptual or embodiment design).
In this article, we present a comparative study of two function modeling approaches; on the one hand, as the probably most widespread approach in engineering design literature, function structures after Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007), and on the other hand, the more recent IFM framework proposed by Eisenbart et al. (Reference Eisenbart, Gericke and Blessing2016a ). Both are exemplarily applied to model the example of a glue gun, which has been similarly used in preceding work seeding this Special Issue. The approaches are compared using the benchmarking protocol by Summers et al. (Reference Summers, Eckert and Goel2013) to enhance comparability of our results with other scholars’ in the context of this Special Issue. Particularly, we comparatively investigated the approaches pertaining to representation, modeling, cognitive dimension, and reasoning characteristics following the protocol. Further points of comparison have been included to add depth to the presented analysis, going beyond the example of the glue gun.
Based on the conducted benchmarking, concrete strengths and weaknesses in applying the approaches were derived. Many of these are expected to similarly apply beyond the given example. It is obvious that the models differ in terms of their comprehensiveness, which directly translates into the modeling efforts and prerequisites for applying them. Function structures have clear advantages over the IFM framework here, as they are less comprehensive in terms of addressed contents and thus can be modeled more quickly. Yet, in turn, the generated IF model incorporates information saliently that is rather intangible in function structures. This particularly pertains to linking it with the (physical) structure of the modeled entity. By extension, the assumptions and implicit decisions made by designers during the design process, which gradually constrain the solution space, can become more visible. These might be crucial to enable others who were not involved in the model generation process to comprehend the model at a later stage. Moreover, the inherent consistency check enforced by the IFM framework, which is almost entirely missing in function structures, triggers a more conscious modeling process and level of abstraction used within the model. This is not specifically supported in function structures and the main, subfunctions, and auxiliary functions can be modeled within the same model indiscriminately. This is something Eckert et al. (Reference Eckert, Alink and Albers2010) and Alink (Reference Alink2010) similarly found and discuss to pose difficulties in the practical application of function structures. Eventually, it has to be noted that while the IFM framework provides advantages in the support of function modeling and analysis for complex, interdisciplinary systems, modeling efforts may increase fairly quickly given that this involves diverse types of information to be modeled. The complexity of the system under development has an impact on the perceived benefit of function modeling. With reference to the example of the glue gun, the level of detail and sheer amount of information incorporated in the IF model may not be necessary for most design purposes. Yet abstract models such as function models unfold their potential, that is, create benefit, primarily when used for modeling complex or highly complicated systems. Therefore, we believe that while function structures provide benefits in terms of simplicity, the IFM framework has the potential to excel over them in terms of support for consistency, comprehensiveness, and analysis options. With this in mind, one may expect function structures to be advantageous whenever information is limited, such as in new design projects, while the IFM framework is particularly valuable for redesign projects that can use existing knowledge about a system as a starting point.
We hope that the comparison presented here will spark interest in the design research community and industrial practice regarding the practical application and respective benefits of the approaches in different application scenarios. From such a discussion, we hope to be able to distill further insight and potential improvement of the IFM framework and function structures. We see vast opportunities for further cross-fertilization in this endeavor with other function modeling approaches discussed in this Special Issue and beyond.
Table 9. Comparison of modeling characteristics
Table 10. Comparison of effects of premature commitments
Kilian Gericke is a Research Scientist at the University of Luxembourg. He attained his PhD in design management at Technische Universität, Berlin. Dr. Gericke's research interests are in design process modeling and management, design methodology, and function modeling.
Boris Eisenbart is a Senior Lecturer in product design engineering at Swinburne University of Technology in Melbourne. He holds a Diploma in mechatronics engineering from Saarland University and a PhD in engineering design from the University of Luxembourg. Before his current role, Dr. Eisenbart was an Assistant Professor in product innovation management at TU Delft and worked as a Postdoctoral Research Associate in design thinking and strategy at the University of Sydney.
