Supporting Interdiciplinary Design Through ...

PhD-FSTC-2014-12 The Faculty of Sciences, Technology and Communication

DISSERTATION Defence held on 05/06/2014 in Luxembourg to obtain the degree of

DOCTEUR DE L’UNIVERSITÉ DU LUXEMBOURG EN SCIENCES DE L’INGENIEUR by

Boris EISENBART Born on 25 July 1985 in Saarlouis (Germany)

SUPPORTING INTERDISCIPLINARY SYSTEM DEVELOPMENT THROUGH INTEGRATED FUNCTION MODELLING

Dissertation defence committee Dr. Lucienne T. M. Blessing, Dissertation Supervisor Professor, Université du Luxembourg, Luxembourg, GD of Luxembourg

Dr. Pierre Kelsen, Vice Chairman Professor, Université du Luxembourg, Luxembourg, GD of Luxembourg

Dr. Timothy C. McAloone Professor, Technical University of Denmark, Lyngby, Denmark

Dr. Holger Voos, Chairman Professor, Université du Luxembourg, Luxembourg, GD of Luxembourg

Dr. Christian Weber Professor, Technical University of Illmenau, Illmenau, Germany

This is a revised version of the original thesis manuscript submitted to the University of Luxembourg library and defended in summer 2014. Revisions include correcting spelling mistakes as well as occasional adaptations of formulations or of the presentation of tables and figures.

Boris Eisenbart, Sydney in September 2015

SUMMARY

Interdisciplinary system development requires the integration of diverse expertise to combine different engineering technologies and – increasingly often – services, in order to provide users with expected value and desired functionality in newly developed products. Failure to achieve an adequate integration of knowledge from involved design disciplines in the development process can result in design errors, which may eventually pose a direct threat to users and to the company. Function modelling is widely considered a suitable means for enhancing the required integration of disciplines early in the development process; however, a large variety of different and often incompatible function models can be found in the different disciplines, which poses a considerable challenge for and my hamper shared, cross-disciplinary function modelling. This thesis reports on comprehensive research into central barriers and enablers for cross-disciplinary function modelling. The presented work follows a general research approach, the Design Research Methodology (DRM), proposed by Blessing and Chakrabarti. Conducted research comprises comprehensive literature reviews of diverse function models and function modelling approaches proposed in disciplinary and interdisciplinary design approaches. This is complemented by empirical research in ten companies developing mechatronic systems and/or Product-Service Systems in diverse market areas. The empirical studies provide compelling insights into the actual application of function models in different disciplines, as well as the specific needs and preferences of practicing designers regarding interdisciplinary function modelling. The conducted research shows that function models from different disciplines are often insufficiently linked, as they frequently address differing contents and use incompatible modelling morphologies (i.e. structure and form). The central contribution of this work is the proposition of the Integrated Function Modelling framework. The framework is a novel modelling approach which is intended to address the identified needs and requirements for the integration of function modelling in order to support interdisciplinary conceptual design in practice. The framework uses interlinked matrices to overcome the barriers of incompatible modelling morphologies and provide the designers with different views onto system functionality that – complementarily – represent all the identified contents addressed in function modelling in different disciplines. The framework is modular and can be flexibly adapted to the specific needs of different disciplines and design contexts. A particular benefit resulting from the matrix-based representation is that it facilitates application of various methods for analysing system functionality. The developed framework is evaluated using feedback from workshops with practitioners in industry and from expert discussions in academia. The evaluation suggests that the framework may indeed provide interdisciplinary design practice with the desired support for shared function modelling and thereby facilitate the integration of different engineering technologies as well as services.

i

ACKNOWLEDGEMENTS

This thesis is the results of my work in the Engineering Design and Methodology Group at the University of Luxembourg. There are a number of people that I would like to express my deepest gratitude to for supporting me in this endeavour. Firstly, I would like to thank the Fonds National de la Recherche (FNR) Luxembourg for funding my research and giving me the opportunity to work independently in a fascinating field of study. Furthermore, I would like to thank my colleagues Dr. Kilian Gericke, Dr. Hubert Moser, and Dr. Ahmed Qureshi for an always pleasant working environment and inspiring discussions. Special thanks go to Dr. Gericke, who – by always giving me honest feedback and constructive advice – particularly contributed to my work and encouraged me to advance. I would like to express my gratitude to my supervisors at the University of Luxembourg, Prof. Dr. Luciënne Blessing, Prof. Dr. Pierre Kelsen, and Prof. Dr. Holger Voos, as well as Prof. Dr. Timothy McAloone from the Technical University of Denmark (DTU) for their continuous guidance and support. During my repeated visits at DTU, Prof. McAloone has been acting as a highly valuable advisor and sparring partner from the field of Product-Service Systems research. Special thanks also go to his colleague Prof. Emeritus Mogens Andreasen who has been facilitating my work through his expertise and by challenging me continuously with his sharp-witted questions. Prof. Blessing has been more than a research supervisor; her expertise and cordial behaviour have strongly influenced me in my professional and personal development. Further thanks go to Prof. Dr. Wolfgang Eder and Dr. Detlef Matzen for valuable discussions as well as to Prof. Dr. Christian Weber, not only for introducing me to the field of engineering design research, but also for spontaneously agreeing to become an external reviewer in my dissertation defence committee. This thesis would also not exist without the commitment and willingness of all participants in my empirical studies. Many of them voluntarily invested much more time than I requested. By openly sharing their experiences and opinions with me, the participants enabled me to acquire valuable insights contributing substantially to my work. Finally, my warmest thanks go to my parents, my sister Miriam, and all my friends who supported and encouraged me throughout the challenging and the delightful moments in this Ph.D. project. To all of you: Thank you very much!

iii

CONTENTS

SUMMARY ........................................................................................................................................................ I ACKNOWLEDGEMENTS ................................................................................................................................... III LIST OF FIGURES .............................................................................................................................................. IX LIST OF TABLES .............................................................................................................................................. XIII 1

INTRODUCTION ....................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5

2

MOTIVATION ............................................................................................................................................. 1 RESEARCH FOCUS ....................................................................................................................................... 2 SCOPE AND RESEARCH QUESTIONS ................................................................................................................. 3 RESEARCH APPROACH .................................................................................................................................. 4 STRUCTURE OF THIS THESIS ........................................................................................................................... 5

FUNCTION IN DESIGN............................................................................................................................... 7 2.1 SYSTEM .................................................................................................................................................... 7 2.2 SYSTEM DEVELOPMENT ................................................................................................................................ 8 2.2.1 Design states and models in system development ............................................................................ 8 2.2.2 Central design states across disciplines ........................................................................................... 10 2.2.3 Conceptual design ........................................................................................................................... 11 2.2.4 Function modelling .......................................................................................................................... 12 2.3 FUNCTION ............................................................................................................................................... 12 2.3.1 Diversity in defining function ........................................................................................................... 12 2.3.2 Archetypical notions of function...................................................................................................... 15 2.3.3 Different types of functions ............................................................................................................. 16 2.3.4 Implications ..................................................................................................................................... 18 2.4 FUNCTION REASONING............................................................................................................................... 18 2.4.1 Function reasoning during conceptual design ................................................................................. 19 2.4.2 Fundamental function reasoning approaches ................................................................................. 20 2.4.3 Comparing different function reasoning approaches ...................................................................... 27 2.4.4 Implications ..................................................................................................................................... 29 2.5 TOWARDS SHARED FUNCTION MODELLING ..................................................................................................... 30 2.5.1 Introducing formalisation in the representation of function ........................................................... 30 2.5.2 Converging to a common representation of function ..................................................................... 32 2.5.3 Studies on function reasoning and function modelling in practice ................................................. 33 2.6 SUMMARY AND DISCUSSION ....................................................................................................................... 35 2.7 REFINED RESEARCH QUESTIONS AND OBJECTIVES ............................................................................................. 36

3

FUNCTION MODELLING APPROACHES ................................................................................................... 39 3.1

ANALYSING FUNCTION MODELS ................................................................................................................... 39

v

3.1.1 Approach ......................................................................................................................................... 40 3.1.2 Function modelling perspectives ..................................................................................................... 43 3.1.3 Modelling morphologies.................................................................................................................. 48 3.1.4 Comparison of identified function modelling perspectives and 5-key-terms .................................. 50 3.1.5 Discussion ........................................................................................................................................ 51 3.2 ANALYSING FUNCTION MODELLING APPROACHES ............................................................................................ 52 3.2.1 Approach ......................................................................................................................................... 52 3.2.2 Mechanical engineering .................................................................................................................. 52 3.2.3 Electrical engineering ...................................................................................................................... 54 3.2.4 Software development .................................................................................................................... 55 3.2.5 Service development ....................................................................................................................... 57 3.2.6 Mechatronic system development .................................................................................................. 58 3.2.7 PSS design........................................................................................................................................ 60 3.2.8 Systems engineering ........................................................................................................................ 62 3.2.9 Comparing function modelling approaches .................................................................................... 63 3.3 DISCUSSION............................................................................................................................................. 67 3.3.1 Potential barriers for shared function modelling ............................................................................ 67 3.3.2 Needs and opportunities for integrated function modelling ........................................................... 68 3.3.3 Possibilities for combining different function modelling perspectives ............................................ 68 3.3.4 Limitations ....................................................................................................................................... 69 3.4 IMPLICATIONS .......................................................................................................................................... 69 4

FUNCTION MODELLING IN PRACTICE – AN EMPIRICAL STUDY ............................................................... 71 4.1 INTENTIONS AND QUESTIONS ...................................................................................................................... 71 4.2 STUDY DESIGN ......................................................................................................................................... 71 4.2.1 Research method selection.............................................................................................................. 71 4.2.2 Study overview ................................................................................................................................ 73 4.2.3 Recruited participants ..................................................................................................................... 73 4.2.4 Data collection ................................................................................................................................ 74 4.2.5 Data analysis ................................................................................................................................... 75 4.3 FINDINGS ................................................................................................................................................ 76 4.3.1 Examples of function models found in practice ............................................................................... 76 4.3.2 General application of function models during the conceptual design stage ................................. 79 4.3.3 Experiences with modelling and exchanging information using function models .......................... 84 4.3.4 Addressed function modelling perspectives and used modelling approaches ................................ 87 4.3.5 Reasons for not using known function models ................................................................................ 91 4.3.6 Experiences made while introducing a new function model or modelling approach ...................... 95 4.3.7 Preferred representation ................................................................................................................. 99 4.3.8 Considered support ....................................................................................................................... 100 4.3.9 Addressed notions of function ....................................................................................................... 104 4.4 SUMMARY AND DISCUSSION OF THE RESULTS................................................................................................ 108 4.4.1 Function and function reasoning in the companies....................................................................... 108 4.4.2 Interdisciplinary function modelling can support collaborative design ......................................... 109 4.4.3 Further integration is expedient .................................................................................................... 110 4.4.4 Limitations ..................................................................................................................................... 110 4.5 CONCLUSIONS FROM LITERATURE REVIEWS AND EMPIRICAL STUDY.................................................................... 111

5

A FRAMEWORK FOR INTEGRATED FUNCTION MODELLING .................................................................. 113 5.1 TOWARDS INTEGRATED FUNCTION MODELLING ............................................................................................. 113 5.2 THE INTEGRATED FUNCTION MODELLING (IFM) FRAMEWORK ........................................................................ 115 5.2.1 Overview........................................................................................................................................ 115

vi

5.2.2 Entities and relations ..................................................................................................................... 116 5.2.3 Different views for representing system functionality .................................................................. 117 5.2.4 A synthesis of views ....................................................................................................................... 123 5.2.5 Hints on the application of the IFM framework ............................................................................ 126 5.2.6 Potentials for supporting function analysis ................................................................................... 129 5.3 COMPARISON OF THE IFM FRAMEWORK WITH EXISTING MODELLING APPROACHES .............................................. 131 5.3.1 Approach ....................................................................................................................................... 131 5.3.2 Adapting the IFM framework to different function modelling approaches .................................. 131 5.3.3 Implications ................................................................................................................................... 135 5.4 SUMMARY AND DISCUSSION ..................................................................................................................... 137 5.5 IMPLICATIONS ........................................................................................................................................ 138 6

INITIAL EVALUATION STUDY ................................................................................................................ 141 6.1 INTENTION AND RESEARCH QUESTIONS........................................................................................................ 141 6.2 STUDY DESIGN ....................................................................................................................................... 141 6.2.1 Research method selection............................................................................................................ 141 6.2.2 Workshops in industry ................................................................................................................... 142 6.2.3 Expert discussions in academia ..................................................................................................... 144 6.2.4 Data analysis ................................................................................................................................. 144 6.3 FINDINGS .............................................................................................................................................. 145 6.3.1 Contents and views considered useful in the IFM framework ....................................................... 145 6.3.2 Benefits and potentials for further improvement ......................................................................... 149 6.4 DISCUSSION........................................................................................................................................... 153 6.4.1 Limitations ..................................................................................................................................... 153 6.4.2 Modularity and possibilities for function analysis are particularly beneficial ............................... 154 6.4.3 Potentials for further improvement .............................................................................................. 154

7

CONCLUSION ....................................................................................................................................... 157 7.1 SUMMARY............................................................................................................................................. 157 7.1.1 Goals and fundamental research questions .................................................................................. 157 7.1.2 Main results ................................................................................................................................... 157 7.2 CONTRIBUTIONS ..................................................................................................................................... 159 7.2.1 Regarding engineering design research ........................................................................................ 159 7.2.2 Regarding function modelling in practice ..................................................................................... 160 7.3 REVIEW OF RESEARCH APPROACH............................................................................................................... 161 7.4 OUTLOOK.............................................................................................................................................. 161

REFERENCES ................................................................................................................................................. 163 APPENDIX A:

CLASSIFICATION OF FUNCTION MODELS PROPOSED IN LITERATURE ................................... 179

APPENDIX B:

PARTCIPANTS OF EMPIRICAL STUDIES................................................................................. 183

I. II.

PARTICIPANTS’ PROFILES – INITIAL EVALUATION STUDY ....................................................................................... 183 PARTICIPANTS’ PROFILES – INTERVIEW STUDY ................................................................................................... 184

APPENDIX C: I. II.

INTERVIEW STUDY – QUESTION CATALOGUE .................................................................................................... 185 EVALUATION STUDY – QUESTIONNAIRE ........................................................................................................... 187

APPENDIX D: I. II.

QUESTIONS FOR EMPIRICAL STUDIES .................................................................................. 185

CONCEPTUAL DESIGN IN PRACTICE ..................................................................................... 193

EXAMPLES OF CONCEPTUAL DESIGN APPROACHES FROM THREE COMPANIES............................................................ 193 INTEGRATION OF SERVICE AND PRODUCTS DEVELOPMENT IN VISITED PSS DESIGN COMPANIES .................................... 196

vii

III.

EXAMPLES OF FUNCTION MODELLING APPROACHES PROPOSED IN COMPANIES......................................................... 197

APPENDIX E: I. II.

FUNCTION MODELS FOUND IN PRACTICE ............................................................................ 199

REFERENCED FUNCTION MODELS .................................................................................................................... 199 EXPRESSED STRENGTHS AND WEAKNESSES........................................................................................................ 200

viii

LIST OF FIGURES

Figure 1-1: Example of a function model of a tensile testing machine proposed by Pahl et al. (2007) . 3 Figure 1-2: Research approach based on the DRM (adapted from Blessing and Chakrabarti 2009)...... 4 Figure 1-3: Structure of this thesis .......................................................................................................... 5 Figure 2-1: General life-cycle model of a system (after Blanchard and Fabrycky 1998)......................... 8 Figure 2-2: General process model for system development (adapted from VDI 1993) ........................ 9 Figure 2-3: Iterative synthesis and evaluation steps during conceptual design (after Chakrabarti and Bligh 2001) ............................................................................................................................................. 11 Figure 2-4: Central terms addressed in the selected definitions of function in relation to the derived archetypical notions of function ........................................................................................................... 16 Figure 2-5: The FBS framework (after Gero and Kannengiesser 2002) ................................................. 20 Figure 2-6: Function decomposition and mapping to function carriers (after Pahl et al. 2007)........... 22 Figure 2-7: Chromosome model and related models (combination of Andreasen et al. 2014 and Eder and Hosnedl 2008) ................................................................................................................................ 23 Figure 2-8: Schema of reasoning from user goals to required function carriers (after Cockburn 2000) ............................................................................................................................................................... 25 Figure 2-9: 5-key-term approach (after Vermaas 2009) ....................................................................... 26 Figure 2-10: Classification of a) FBS framework, b) Pahl and Beitz approach, c) Theory of Domains, and d) Use case-based reasoning ................................................................................................................. 28 Figure 2-11: Function model of a power screwdriver (after Stone and Wood 2000) ........................... 28 Figure 2-12: Comparison by Stone and Wood (2000) of their Functional Basis with the function taxonomies proposed by Pahl et al. (2007), Hundal (1990), and Altschuller (1999) ............................ 31 Figure 2-13: Relation between the notion of function, function modelling, and function reasoning .. 36 Figure 3-1: Examples of a) use case schematic and b) associated activity diagram (adapted from Kroll and Kruchten 2003), c) function tree (adapted from Gausemeier and Möhringer 2001) .................... 39 Figure 3-2: Generic model classification scheme (adapted from Buur and Andreasen 1989) ............. 41 ix

Figure 3-3: Two alternative process structures for an in-flight refuelling probe proposed by Blessing and Upton (1997) .................................................................................................................................. 43 Figure 3-4: Transformation process structure (reprinted from Eder and Hosnedl 2008) ..................... 44 Figure 3-5: Example of customer activity cycle (CAC) for a medical service proposed by Vandermerwe (2000) .................................................................................................................................................... 44 Figure 3-6: Function structure of a hydraulic bearing system (adapted from Pahl et al. 2007) ........... 45 Figure 3-7: Schema of a service process model (after Watanabe et al. 2011) ..................................... 46 Figure 3-8: Example of a Function-Means-Tree of a projector (see Buur 1990) ................................... 47 Figure 3-9: Combined or “hybrid” modelling of functions and solution principles in one model (simplified from Gausemeier and Möhringer 2001) ............................................................................. 47 Figure 3-10: Schema of a hierarchical function list ............................................................................... 48 Figure 3-11: a) Function structure of a power screwdriver proposed by Stone and Wood (2000); b) Service blueprint of a shoe buffing service proposed by Shostack (1982) ........................................... 49 Figure 3-12: Schema of a simple finite state machine (after Belzer et al. 1975) .................................. 55 Figure 3-13: Examples of use case schematic, activity flow diagram, and sequence diagram for a course management software system (adapted from Kroll and Kruchten 2003) ............................................ 57 Figure 3-14: Example of IDEF-0 model of a maintenance service (after US DoD 2001) ....................... 58 Figure 3-15: Different function models proposed by Buur (1990) for the example of a telephone ..... 59 Figure 3-16: Overview of proposed models (adapted from Sakao and Shimomura 2007) .................. 61 Figure 3-17: Schema of a Functional Flow Block Diagram (adapted from US DoD 2001)..................... 62 Figure 4-1: Subject areas and methods for empirical research in social sciences (after Bender et al. 2002)...................................................................................................................................................... 72 Figure 4-2: Schema of "Function Parameter Model" ............................................................................ 76 Figure 4-3: Example of "Service Process model" from Company J (excerpt) ........................................ 77 Figure 4-4: Schema of “Function Cycle Breakdown” ............................................................................. 77 Figure 4-5: Example of Grafcet model from Company A (excerpt) ....................................................... 78 Figure 4-6: Schema of a Function Flow Chart........................................................................................ 78 Figure 4-7: Schema of “Allocation Matrix” ............................................................................................ 79 Figure 4-8: Function modelling on different levels of participation during conceptual design ............ 81 Figure 4-9: Driving reasons (from Group 1 or 2) provided by participants from different discipline ... 93

x

Figure 4-10: Preferred representation of functions (n=21) ................................................................ 100 Figure 4-11: Support considered useful in different companies......................................................... 102 Figure 4-12: Notions of function addressed in the provided answers from the participants ............. 106 Figure 5-1: The Integrated Function Modelling framework ................................................................ 116 Figure 5-2: Class diagram of the IFM framework ................................................................................ 117 Figure 5-3: Schema of a process flow view.......................................................................................... 118 Figure 5-4: Example of process flow view for use case “prepare a cup of coffee” ............................. 119 Figure 5-5: Schema of actor view ........................................................................................................ 119 Figure 5-6: Example of actor view for the use case “prepare a cup of coffee” .................................. 120 Figure 5-7: Schema of the state view – comprising the actor state and operand state matrices ...... 120 Figure 5-8: Example of state view for the use case “prepare a cup of coffee” ................................... 121 Figure 5-9: Effect view with associated partial state view for Process 2 “heat water”....................... 121 Figure 5-10: Example of use case view for the coffee vending machine ............................................ 122 Figure 5-11: Schema of interaction view............................................................................................. 122 Figure 5-12: Example of interaction view for use case “prepare a cup of coffee”.............................. 123 Figure 5-13: Combination of associated views for the use case “prepare a cup of coffee” ............... 125 Figure 5-14: Potential sequence of modelling activities and associated views (only main steps shown, further iterations may occur between any point in the illustrated progression) ............................... 127 Figure 5-15: Rebuilding the example of a function structure from Figure 1-1 with the IFM framework, combining effects and processes in the process flow view ................................................................. 132 Figure 5-16: States and transitions partial model for the example of the telephone proposed by Buur (1990) .................................................................................................................................................. 133 Figure 5-17: Mapping reviewed function modelling approaches to the views in the IFM framework ............................................................................................................................................................. 135 Figure 5-18: Process flow view with potential alternative path P’ “abort drink preparation” ........... 137 Figure 6-1: Assessment of contents addressed in the IFM framework (n=17) ................................... 146 Figure 6-2: Amount of views (max. 6) assessed useful or not useful in the questionnaires (n=14) ... 147 Figure 6-3: Assessments of views encompassed in the IFM framework (n=14) ................................. 147 Figure 6-4: Provided answers to Question 4 (n=17)............................................................................ 150 Figure 7-1: Schema of the developed Integrated Function Modelling framework............................. 159 xi

Figure D-1: Typical sequence of applied models during conceptual design in Company B ................ 193 Figure D-2: Typical sequence of applied models during conceptual design in Company H................ 194

xii

LIST OF TABLES

Table 2-1: Central design states (adapted from Eisenbart et al. 2011, see also Gericke et al. 2013a and Qureshi et al. 2013) ............................................................................................................................... 10 Table 2-2: Examples of models proposed to represent the available information during conceptual design (adapted from Eisenbart et al. 2011) ......................................................................................... 11 Table 2-3: Overview of definitions of function in literature ................................................................. 14 Table 3-1: Exemplary classification of function models after using the classification scheme by Buur and Andreasen (1989) ........................................................................................................................... 41 Table 3-2: Overview of reviewed function models ............................................................................... 42 Table 3-3: Exemplary categorisation of function models presented in preceding sections ................. 49 Table 3-4: Function modelling perspectives associated to the five key-terms ..................................... 51 Table 3-5: Central function modelling steps after Pahl et al. (2007) .................................................... 53 Table 3-6: Central function modelling steps after Hubka and Eder (adapted from Eder 2008) ........... 54 Table 3-7: Central steps related to function modelling after Dewey (2000) ........................................ 55 Table 3-8: Central function modelling steps in the RUP (after Kroll and Kruchten 2003 and Kruchten 2004)...................................................................................................................................................... 56 Table 3-9: Central function modelling steps proposed by Spath and Demuss (2005) .......................... 58 Table 3-10: Central function modelling steps proposed by Buur (1990) .............................................. 60 Table 3-11: Central function modelling steps proposed by Sakao and Shimomura (2007) .................. 61 Table 3-12: Central function modelling steps proposed by Weilkiens (2008) ...................................... 63 Table 3-13: Summary of exemplary function modelling approaches ................................................... 64 Table 3-14: Comparison of function modelling approaches from the different disciplines ................. 66 Table 4-1: Overview of companies involved in the study ..................................................................... 74 Table 4-2: Use of function models and types of design described in the companies ........................... 83

xiii

Table 4-3: Function models used on level 1 and level 2 of participation.............................................. 84 Table 4-4: Function models used on level 3 and level 4 of participation.............................................. 85 Table 4-5: Function modelling perspectives addressed in in-house-developed function models........ 88 Table 4-6: Overview of function modelling perspectives and modelling morphology addressed in the function models used in different disciplines ....................................................................................... 89 Table 4-7: Known but not used function models .................................................................................. 93 Table 4-8: Case 1 – Supporting joint exploration of potential solutions............................................... 95 Table 4-9: Case 2 – Supporting exploration of system context and required functionality ................. 96 Table 4-10: Case 3 – Building a shared reference model ...................................................................... 98 Table 4-11: Examples of provided formal and informal definitions.................................................... 105 Table 4-12: Notions of function addressed in the interviews ............................................................. 105 Table 5-1: Description of entities addressed in IFM framework ......................................................... 116 Table 5-2: Potential modelling activities for applying the IFM framework ......................................... 127 Table 5-3: Mapping between IFM framework and approach proposed by Hubka and Eder (1988) .. 132 Table 5-4: Mapping between IFM framework and approach by Sakao and Shimomura (2007) ........ 133 Table 5-5: Mapping between IFM framework and approach proposed by Weilkiens (2008) ............ 134 Table 5-6: Mapping between IFM framework and modelling approach proposed in Company A..... 135 Table 6-1: Overview of companies and participants involved in the study ........................................ 143

xiv

1 INTRODUCTION

1.1 Motivation Designers strive to generate descriptions of systems which are capable of fulfilling expected functions and requirements in sufficient detail for their implementation (Blessing 1994, Chakrabarti and Bligh 2001). This encompasses determining the characteristics of technical products and processes in terms of their functional, physical, and operational properties (Pahl et al. 2007, Weber 2007). Industry is confronted with ever-changing and increasing demand of customers on global markets for integration of diverse functions into newly developed systems (McAloone and Andreasen 2004). In order to address this issue, companies increasingly often combine different technologies necessitating close collaboration of experts from various disciplines (Blessing 1996, Redenius 2006). A system which insufficiently fulfils the central functions expected from it is likely to fail on the market or may fail during use (Umeda and Tomiyama 1997, Chiang et al. 2001). Eventually, this can pose a direct threat to the users and to the company (Gries 2007, Gericke 2011). The following example is taken from a globally active developer and manufacturer of mechatronic systems. The example illustrates some of the challenges product development in industry is confronted with, due to the increasing need for integration of different technologies in their products. The presented insights originate from personal discussions with involved personnel: Faced with increasing global competition and customer demand for specific new functions, the company started complementing the historically mainly mechanical product with vast amounts of electrical components along with associated control elements and software. As a result, a multitude of complex interlinked functions were complementarily implemented by diverse combinations of components, which were developed in different disciplines and by different departments in the company. During use of the new product, various problems, some of which safety-critical for users, occurred with malfunctioning equipment. Call-backs and required subsequent modifications of the product design caused a considerable loss for the company, both economically and in terms of reputation. Subsequent internal analysis revealed that some of the product’s components did not comply with each other. Some functions had been redundantly implemented in different components or functional interfaces between components were found to be inconsistent. The problems could eventually be traced back to three essential reasons: 

Firstly, designers in different disciplines (and departments) often worked with separate models. Inconsistencies in the represented information between these models were not always recognised, which led to design errors. 1





Secondly, there was no comprehensive documentation of the system functions and which components would implement them. Such a documentation only existed for selected product modules. Hence, individual designers had not been aware of all functional interdependencies between the different components complementarily implementing specific system functions. Finally, because of this missing awareness, direct communication between designers within and across different disciplines (and departments) was neglected and some design errors were not recognised or only very late in the development process.

The example illustrates the need for collaboration and exchange of causal information about system functionality between designers involved in a development project. The developed technical product was essentially a mechatronic system, comprising the integration of disciplines such as mechanical engineering, electrical engineering, and software development. However, the introduction of new types of systems in industry, such as “Product-Service Systems” (hereafter PSS) that integrate services with technical products, extends interdisciplinary development by including further disciplines. Problems in the exchange of information between designers are considered one of the central risks posed to the success of interdisciplinary system development (Badke-Schaub et al. 2011, Gericke 2011). Apart from verbal or textual communication and gestures, exchange between designers is essentially facilitated through different kinds of models as a means of representation and visualisation of information (Latour 1986, Stacy and Eckert 2003, Crilly et al. 2008). Difficulties in understanding models generated in different disciplines are a central cause for error-prone communication. They may result in design errors and additional efforts required to explain models and their contents, in order to make represented information accessible to designers from other disciplines (Maier et al. 2006, Zimmerman 2008, Cabrera et al. 2011). A shared model, which is capable of supporting the exchange of information between disciplines adequately is ultimately expected to increase the quality of the design and thus to foster corporate success (Paredis et al. 2001, Sachse and Leinert 2002).

1.2 Research focus The potential benefit of shared modelling is particularly large during the conceptual design stage, i.e. in the central transition from the problem to a potential solution (Bonnema and van Houten 2006, Ehrlenspiel 2007, INCOSE 2010). This transition requires a joint effort of involved designers (Blessing and Upton 1997, Chakravarthy et al. 2001) and necessitates a continuous exchange of information between them (Buur 1990, Shai and Reich 2004). In order to coordinate individual design activities and facilitate sound decision-making on alternative solution concepts, the designers need to establish a shared understanding of the problem and the emerging solution during conceptual design (Kleinsmann and Valkenburg 2008, van Beek and Tomiyama 2009). This particularly requires clarification in the design team of the requirements, the central expected functions and their dependencies, as well as of the different solution elements foreseen for implementation (Frankenberger et al. 1998, Bender 2004, Alink 2010). Function modelling is considered particularly well suited in terms of establishing the required shared understanding, as it addresses solution finding early in the process and on an abstract level (Chakrabarti and Bligh 2001, Leemhuis 2005). Ahmed and Wallace (2003), for instance, found that in industry, different solution concepts are often exchanged between designers (from different disciplines) and different design projects through expressing them in terms of their function. A large amount of function models originate from German mechanical engineering research in the 1960s and 70s (see e.g. Rodenacker 1970, Pahl and Beitz 1977, and Hubka 1980). They typically define 2

Chapter 1: Introduction function in relation to the expected behaviour of a system, which is intended to fulfil a purpose (Crilly 2010). The models usually represent function as verb/noun combinations related to a transformation of the states of basic operands between the input and output of a system. Operands are typically specifications of material, energy, and information (often also called signals). An example of such a function model is presented in Figure 1-1. These kinds of models have been widely adopted in mechanical engineering literature (see e.g. Ullman et al. 1992, Stone and Wood 2000, and Ulrich and Eppinger 2008) but also in interdisciplinary design approaches (see e.g. VDI 2004 and Cross 2008). ELoad S

Specimen

Change energy into force and movement

Measure force

Sf

Measure deformation

S

Legend: energy material signals Edeformation Specimendeformed

Load specimen

Figure 1-1: Example of a function model of a tensile testing machine proposed by Pahl et al. (2007) Function modelling is also prominent in electrical engineering, software development, and may even be applicable to abstract modelling of biological systems (see e.g. Nagel et al. 2008). Due to this spread of function models to different disciplines, joint function modelling is expected to be capable of supporting the establishment of the required shared understanding across disciplines (Erden et al. 2008, van Beek and Tomiyama 2009). Erden et al. explicitly argue that “the barriers between […] disciplines can be overcome by using [a] common language of functionality” (Erden et al. 2008 p. 147, see also Stone and Wood 2000 and Zafirov et al. 2010). Müller et al. (2007) emphasise that this also applies to the integration of engineering disciplines with service development in PSS design. However, shared, cross-disciplinary function modelling of designers from disciplines typically involved in mechatronic system development or PSS design has not been sufficiently established thus far. One problem could be that while function modelling is widely applied in e.g. electrical engineering and software development, there is little evidence that it is applied to a similar extent in mechanical engineering practice (see e.g. Blessing 1994 and Eckert 2013). A more fundamental problem, however, seems to be that the function models from different disciplines differ in terms of content, terminology, and morphology, which hampers sharing represented information across disciplines. Initially proposed function modelling approaches which try to address this issue are considered to provide only limited support and discipline-specific function models remain to be used in the different disciplines. Hence, in spite of its large potential to facilitate integration in interdisciplinary system development, the “common language of functionality” discussed by Erden et al. has not – or only insufficiently – been attained thus far.

1.3 Scope and research questions The research presented in this thesis is based on the general assumption that an integrated function modelling approach, which can combine or relate between function models from different disciplines, can support the establishment of the required shared understanding between designers during the conceptual design stage and, hence, facilitate collaboration between disciplines. It is aspired that the development of such an integrated function modelling approach will strongly enhance the usefulness 3

of function modelling in interdisciplinary system development and, hence, its use in all disciplines involved. The overall goal is the development of a function modelling approach, which facilitates the integration of disciplines typically involved in the development of systems that are composed of multi-technology products which may be complemented with associated services. Potentially involved disciplines encompass mechanical engineering, electrical engineering, software development, and service development, as well as mechatronic system development, PSS design, and systems engineering. The overall research questions (RQ) are: RQ I. RQ II.

What are barriers for integrated function modelling? How to support integrated function modelling, in order to enhance the establishment of a shared understanding of the interdisciplinary system under development among collaborating designers?

1.4 Research approach For this research project, the Design Research Methodology (DRM, see Blessing 2002 and Blessing and Chakrabarti 2009) was chosen as a general research approach. Figure 1-2 illustrates the DRM framework with the four main stages of Research Clarification (RC), Descriptive Study 1 (DS-I), Prescriptive Study (PS), and Descriptive Study 2 (DS-II), as well as the main outcomes of this research project. Basic means

Literature analysis

Research stages Research clarification (RC)

Literature analysis, Empirical data & analysis

Descriptive Study I (DS I)

Assumption Experience Synthesis

Prescriptive Study (PS)

Empirical data & analysis

Focus

Descriptive Study II (DS II)

Main outcomes of this research project

Goals

• Overview of research field • Research questions

Understanding

• Review of function modelling proposed in literature • Collection & analysis of empirical data on function modelling in practice

Support

• Integrated Function Modelling framework • Recommendations for application

Evaluation

Initial evaluation of proposed framework • Workshops • Expert discussions • Questionnaires

Figure 1-2: Research approach based on the DRM (adapted from Blessing and Chakrabarti 2009) The presented research mainly covers the first three stages. It is complemented with an initial evaluation study (DS-II) of the proposed support. The RC stage aims at obtaining an understanding of the research topic, which leads to formulation and/or refinement of the main research objectives and questions. 4

Chapter 1: Introduction The second stage (DS-I) is intended to provide answers to the first overall research question. It is based on two main studies: a comprehensive review of function models and associated function modelling approaches proposed in literature, as well as an interview study focusing on the application of and experiences with (interdisciplinary) function modelling in industry. Based on the results from both studies, a support for interdisciplinary function modelling is developed in the PS stage: the Integrated Function Modelling framework. The developed framework is intended to support the establishment of a shared understanding of designers from different disciplines. The framework is initially evaluated through workshops with practicing designers in industry and expert discussions with senior researchers in academia. Both PS and DS-II together provide answers to the second overall research question.

1.5 Structure of this thesis Chapter 2 introduces central concepts and themes relevant to the research presented in this thesis. The chapter essentially comprises the results of the RC stage (see Figure 1-3) leading to a refinement of the research questions and objectives at the end of Chapter 2. Chapters 3 and 4 present the results from the DS-I. Chapter 3 provides a comprehensive analysis of function models proposed in literature from different disciplines and interdisciplinary design approaches. Chapter 4 encompasses the second part of DS-I, i.e. the empirical study of function modelling in different companies. The results of both literature and empirical studies in DS-I are consolidated at the end of Chapter 4 and build the basis for the formulation of specific requirements for the development of an integrated function modelling approach. Chapter 5 presents the results from the PS, namely the developed Integrated Function Modelling framework. The developed framework is illustrated based on an example and complemented with a set of recommendations for its application. In Chapter 6, the results of the initial evaluation study (DS-II) are presented. Chapter 7 finalises the thesis with a summary of the results and a discussion of their contributions to engineering design research and practice. 1. Introduction

Research clarification (RC)

2. Function in Design

3. Function Modelling Approaches

4. Function Modelling in Practice

Descriptive Study I (DS I)

5. A Framework for Integrated Function Modelling

Prescriptive Study (PS)

6. Initial Evaluation Study

Descriptive Study II (DS II)

7. Conclusion

Figure 1-3: Structure of this thesis 5

2 FUNCTION IN DESIGN

This chapter introduces function modelling in the context of system development and discusses different concepts related to function, function modelling, and function reasoning found in literature.

2.1 System A system is a set of elements that are related and may interact with one another, in order to fulfil a designated objective (Hall 1962). The specific elements that a system is composed of can be hardware, software, and firmware, but also processes, services, human resources, information or other supporting elements (ECSS‐E‐ST‐10C 2009, INCOSE 2010). A system under consideration can be part of a surrounding system and may itself be composed of sub-systems (INCOSE 2010). The differentiation between elements that are designated to be inside or outside of the system under consideration determines the system boundary (Moser 2014). The elements within a system may have (mutual) relations and dependencies among each other or to elements outside of the respective system (Müller 2013). Relations between elements are composed of flows, which in a technical product typically involve specifications of material, energy, and information (Pahl et al. 2007, Hubka and Eder 1988, Eder and Hosnedl 2008); in a PSS, they may also include monetary flows or other business relations and dependencies (Müller 2013). The aim of system development, the system’s designated objective, and the specific combination of system elements determine their hierarchy, relations, and provided functions (Goedkoop et al. 1999). The presented research in this thesis focuses on design and modelling activities in the context of the development of systems that are composed of technical products which may be complemented with associated services, e.g. in a PSS. PSS are defined as “a system of integrated products and services that companies develop and deliver, in order to fulfil a need with their customers” (Tan 2010, p. 27)1. Technical products can be composed of mechanical, electrical or software systems or can be a combination of these, i.e. a mechatronic system (Torry-Smith 2013). Services encompass any activity chain that is intended to deliver some kind of value to a customer. Services can be implemented by technical products and humans (Müller 2013). A particularly prominent example of an every-day item that combines technical products with associated services are cellular phones. These integrate increasingly complex and interlinked technical functionality in a mechatronic system, namely the phone, with different types of services (Segan 2012). Such services include the fundamental communication services offered by network providers, but also maintenance services, firmware updates, etc. (see e.g. Sager 2012).

1

Related concepts are “functional products” or “total care products” (see e.g. Alonso-Rasgado et al. 2004 and Ericson and Larsson 2005) as well as “service engineering” (Sakao and Shimomura 2007).

7

2.2 System development Interdisciplinary system development confronts designers with a particularly large solution space to be explored. In order to fulfil the system’s objective, required functions may be realised through a combination of diverse solution elements developed in different disciplines (see e.g. Mont 2004, Howard and Andreasen 2013), which may be employed separately, in combination or in exchange for one another (see e.g. Tukker et al. 2006 and Müller et al. 2007). In addition, already during the early stages of system development, designers need to consider the different types of prospective users and their interactions with the system during its life-cycle (see Kim et al. 2011, McAloone 2011). The selected solution concept needs to be respective of these specific relations, particularly in case the prospective system combines technical products with human processes, in order to fulfil the desired functions, e.g. in a PSS (McAloone and Andreasen 2006, Tan et al. 2007). Figure 2-1 presents the central phases in a system’s life-cycle. System development mainly covers the first main phase (“design” in Figure 2-1). System development is typically performed as a project involving different design stages, which comprise a set of design and modelling activities of involved designers (see also Pahl et al. 2007 and Gericke et al. 2013a). Blanchard and Fabrycky (1998, see Figure 2-1) essentially differentiate system development in four central design stages: planning, conceptual design, system-level design, and embodiment/detail design (slightly different breakdowns can be found e.g. in Blessing 1996, Howard et al. 2008, and Gericke and Blessing 2012). Design activities can be performed sequentially or concurrently (Andreasen and Hein 2000, Ehrlenspiel 2007) and usually include iterations (Wynn et al. 2007). In the different disciplines, systematic design approaches are proposed in literature (also often referred to as “(design) methodologies”). They aim to support system development projects by proposing a sequence of concrete steps and activities, as well as associated methods for the designers to apply. Comprehensive reviews of systematic design approaches (from different disciplines) proposed in literature or investigated in practice are discussed e.g. by Wynn and Clarkson (2005), Reyman et al. (2006), Howard et al. (2008), Tan (2010), Gericke and Blessing (2011), Gericke and Blessing (2012), Gericke et al. (2013a), Qureshi et al. (2013), Müller (2013), Gero and Kannengiesser (2013), and Moser (2014).

Design Planning

Conceptual design

System-level design

Realisation Embodiment/ Detail design

Assembly

Production

Operation Test and Qualification

Development and manufacture

Operations

Maintenance & Repair

Disposal

Utilisation

Figure 2-1: General life-cycle model of a system (after Blanchard and Fabrycky 1998) 2.2.1

Design states and models in system development

Design states The successive design activities of designers in the different stages of a development project lead to an increase in knowledge about the problem to be addressed and its potential solution, starting with typically abstract and undetailed knowledge in the beginning, which is gradually concretised and 8

Chapter 2: Function in Design detailed (see Buur and Andreasen 1989). System development can thus be described as a stepwise increase of the knowledge about the addressed problem and the developed solution (see e.g. Browning et al. 2002 and Gries and Gericke 2009). These different states of information that designers pass through in the course of a development project are often referred to as “design states” (see e.g. Dym 1994 and Blessing 1996). Dym defines design states as the “incorporation of all the information about a design [of a system under development] as it evolves” (Dym 1994, p. 34). System development processes, hence, can be regarded to move through a succession of design states until the final design of the system is determined. An example of a generic process model proposing a sequence of design stages and associated design states is illustrated in Figure 2-2. For the different design states in a development project (a set of) specific models can be used by the designers to represent the currently available information. Task

1.Clarify and define task Specification 2.Determine functions and their structures Function structure 3.Search for solution principles and their combinations Principle solution

Design stages

4.Divide into realisable modules Module structure

Design states

5.Develop layouts of key modules Preliminary layouts 6.Complete overall layout Definite layouts 7.Prepare product and operation instructions Product documents Further realisation

Figure 2-2: General process model for system development (adapted from VDI 1993) Models in system development Stachowiak (1973) defines a model to be “an excerpt of reality”, which refers to a natural or artificial object of whom it represents certain aspects and which serves a user for a specific purpose over a limited period of time. Typical models used by designers during system development comprise textual descriptions, function models, drawings, mock-ups, behavioural models, structural representations, as well as sketches, mathematical models or any kind of physical and virtual prototypes (see e.g. Buur and Andreasen 1989, Roozenburg and Eekels 1995, Goldschmidt and Porter 2004, Andreasen 1994, Bonnema and van Houten 2006, and Gausemeier 2006). Modelling is a central activity of designers during system development (Latour 1986, Andreasen 1994). Apart from the support of communication (as described in Section 1.2), models are important means for capture and storage of information generated during a development project (see e.g. Maier et al. 2014). Designers use models to represent the available information about a design and in order to 9

generate new information in the course of a development project. A new level of information – i.e. a new design state – requires new or updated models to represent the available information (Valkenburg 2000). Roth (1986), Andreasen (1992), and similarly Maier et al. (2014) describe system development as an (iterative) progression from one model to another, wherein different models frequently build up on one another. 2.2.2

Central design states across disciplines

A comprehensive review of the models, design stages, and individual activities proposed in methodologies from different disciplines resulted in the identification of a variety of distinct design states addressed in the proposed approaches (see Eisenbart et al. 2011). Depending on the respective authors, up to 18 distinct design states could be distinguished in different methodologies. Ten design states (see Table 2-1) were found to be particularly prominent in methodologies within and across reviewed disciplines. These design states were found both in product development processes proposed in literature (see Eisenbart et al. 2011) as well as in interdisciplinary design practice (see Gericke et al. 2013a and Qureshi et al. 2013). The order of the design states in Table 2-1 reflects the typical sequence in which they are addressed in the development processes proposed in the reviewed design approaches. They start with the abstraction of central problems and needs2 to be addressed and gradually progress towards the final design of the system under development (i.e. the final layout). Table 2-1: Central design states (adapted from Eisenbart et al. 2011, see also Gericke et al. 2013a and Qureshi et al. 2013) Design state

Description

Problem

… typically refers to the central design problem or overall development task associated to a new design project.

Need

… refers to the identification or derivation of the fundamental need of the prospective users or the general market area to be addressed in relation to the new product or service to be developed.

Market

Product idea/proposal

Design objective

… essentially refers to information about competitors’ offers in the targeted market area and design context (which are typically gained from competitor analysis) and the elaboration of general requirements, objectives, and constraints for the product or service and its development process. … typically refers to an initial idea for a new product or service, its main functionalities, an initial set of requirements, as well as a target budget and potential time consumption of a prospective development project. … refers to a determined design target, typically including (values for the) overall goals of the development project (e.g. “cost-reduction”, “quality improvement” or similar).

… contains the specification of information about the required functionality, constraints, and dependencies/ Requirements specification influences related to the system under development and the development project, which are typically derived from the specific demands, needs, and wishes of the users, the market area, etc. System functionality

… contains information about (required) main- and/or sub-functions of the system to be developed, its subsystems and/or eventual involved processes.

Solution concept

… refers to the determined principle solution, its solution elements (such as modules, components and/or humans or other function carriers) and how they may be integrated into a whole.

Preliminary layout

… refers to more detailed information about the solution elements and their integration into one (initial) overall layout.

Layout/production documents

… refers to the final design of the system, i.e. the individual technical components and/or human resources (detailed to completion), allowing for manufacture and/or operation.

2

Although needs are not necessarily explicated as a separate design state in all methodologies, respective authors almost always discuss basic user or market needs to be driving or initiating the development process, respectively, even if they are not explicitly modelled.

10

Chapter 2: Function in Design 2.2.3

Conceptual design

The conceptual design stage (see Figure 2-1) is typically based on the design state of requirements specification and essentially encompasses system functionality and solution concept. Examples from literature in different disciplines of models that can be used to represent these design states are provided in Table 2-2; however, many other models can alternatively be found in text books. Conceptual design contains the central transition from a problem description towards an initial solution concept. Both researchers (see Section 1.2) and practitioners (see Gericke et al. 2013a) consider conceptual design to be the most influential stage for the design of a system and thus for all subsequent design activities. Table 2-2: Examples of models proposed to represent the available information during conceptual design (adapted from Eisenbart et al. 2011) Design state

Mechanical engineering

Electrical engineering

Software design

Service development

Requirements specification

Requirements list

Requirements list

Feature list, release backlog

Requirements list

System functionality

Function structure

Function blocks diagram

Use case modelling

Service blueprints

Solution concept

Parts structure, product architecture

Module structure

System architecture, class diagram

Process structure, detailed service blueprints

A design task is widely regarded to be an “ill-structured problem”, as often neither the problem nor the desired solution are sufficiently defined at the beginning of a project (Simon 1973). Conceptual design therefore cannot directly move from a problem to a solution and is typically characterised by co-evolution: a stepwise increase of information about the addressed problem in parallel to information about the emerging solution (Poon and Maher 1997, Srinivasan and Chakrabarti 2010). It is an iterative process as in analysing, evaluating, and synthesising the potential solution(s) to a given problem, certain features or constraints of that potential solution may require redefinition of the problem (see e.g. Chakravarthy et al. 2001 and Braha and Reich 2003). This iterative character of conceptual design is illustrated in Figure 2-3. Synthesis

First Initial First Initial First Initial Partial Solution 3 Partial Solution 2 Partial Solution 1

Initial Problem Definition Problem Redefinition

Evaluation

Synthesis

Problem RevisedRevised Problem Revised Problem Definition 3 Definition 2 Definition 1

Problem Redefinition

…

Evaluation

Solution Redefinition Second First Partial Solution PartialtoSolution Revised Problem to Revised Problem Definition 2 Definition 1

…

Solution Redefinition

Figure 2-3: Iterative synthesis and evaluation steps during conceptual design (after Chakrabarti and Bligh 2001) Function modelling is proposed in literature to support and guide the reasoning in the transition from a problem to a solution, i.e. support the iterative analysis and evaluation. The specific reasoning of the designers during conceptual design, which is particularly based on function considerations typically 11

including function modelling, is often referred to as “function reasoning”. Function reasoning is further investigated in Section 2.4. 2.2.4

Function modelling

Function modelling includes any activity related to generating models of systems or processes based on their functionality and the functionality of their sub-systems and/or components (see Erden et al. 2008). A function model is a first abstract representation of the system under development, which is expected to facilitate conceptual design, essentially, through providing (Blessing and Upton 1997, US DoD 2001, Paetzold 2006, Erden et al. 2008):    

means for the representation of the required functions and their dependencies, in order to allow for detailed analysis and to support solution synthesis; means for representation of functional dependencies between the selected system elements, in order to support analysis of function fulfilment; support for the exploration of the solution-space, in order to come up with a variety of alternative solutions; potential for the establishment of a shared understanding of the problem and the potential solution between collaborating designers (as already discussed in Section 1.2).

Because of these advantages and the centrality of function to system development, a multitude of researchers strongly recommend the application of function models during conceptual design (see e.g. Stone and Wood 2000, Ehrlenspiel 2007, and Zafirov et al. 2010). Fowler (1998) argues that every designer forms some kind of abstract, conceptual model in the transition towards a solution, even if it remains in the designer’s mind. Function modelling serves as a means for making these considerations explicit and thus to enable discussions about them during joint solution synthesis. The importance of shared function modelling, including all involved disciplines in interdisciplinary system development, seems to be increasing in industry. In a rather recent development, function as a data object is increasingly often included in software systems that aim to support interdisciplinary system development. Prominent examples are, for instance, CATIA V6 (Dassault Systèmes), the “Mechatronic Modeller” by Gausemeier et al. (2009) or the “Connection Modeller” (see Stark et al. 2010). Personal discussions with a product manager in an established company developing such software support systems revealed that demands from their clients for a support for function modelling including all disciplines involved in a development project are noticeably increasing. The modelling approaches used thus far for representing different functions and related aspects of system functionality in these software support systems are derived from established design literature. A comprehensive review of modelling approaches proposed in literature is presented in Chapter 3.

2.3 Function 2.3.1

Diversity in defining function

Function is a central term in system development, both in research and in practice. According to Merriam-Webster (2003) function is “the special purpose or activity for which a thing exists” or “the job or duty of a person”, respectively. In mathematics, a function is a clear relation between a set of inputs and admissible outputs, and terms such as transformation or operator are sometimes used 12

Chapter 2: Function in Design synonymously (see e.g. Halmos 1974). In design literature, a variety of alternative definitions of function can be found. Table 2-3 provides a selection of definitions from different disciplines. They involve terms and synonyms from both the dictionary definition and the mathematical interpretation of function, but also go beyond these. The definitions not only vary in terms of the used terminology, but most importantly with respect to the specific notions of function (i.e. the underlying perception or understanding of and meaning given to function as an abstract concept) that they convey. Central terms reflecting certain notions of function in the definitions are highlighted in bold in the table. Which notion of function is conveyed in the definitions was not found to be specific to single disciplines. Across disciplines, several of the definitions in Table 2-3 refer to function as the ability of a system to achieve a specific goal, e.g. by showing a certain behaviour (see e.g. Roozenburg and Eekels 1995 or Buur 1990). Other definitions refer to an intended or required transformation or conversion of operands (see e.g. Rodenacker 1970, Pahl et al. 2007, Fowler 1998, Cockburn 2000, etc.), which may be associated to an input/output relation of the system (see also Sections 1.2). The respective authors typically associate this transformation-related interpretation of function to the intended behaviour of the system. Definitions of function, which refer to input/output relations thus provide a more abstract point of view, focusing on the transition of the inputs to the outputs created by a system, rather than focusing on how this transition is achieved, i.e. how the system needs to function to create a specific output to an input. Many definitions also refer to the purpose or objective of the system, e.g. to fulfil a goal, a task or to provide some value (see e.g. Hubka and Eder 1988, UsDoD 2001 or Sakao and Shimomura 2007). In some definitions this purpose determines the required functions; however, other authors refer to the purpose of the system to be equal to its function (see e.g. Bucciarelli 2010 or Ullman 2010). The latter interpretation is often discussed as a “teleological” notion of function (see e.g. Kroes and Meijers 2001 and Ropohl 2009). For instance, a car-jack has the purpose of lifting up a car; this purpose may be regarded as its function in a teleological sense (see also Hubka 1984 and Alink 2010). Apart from the definitions that relate function to a purpose or an intended behaviour, in some of the provided definitions, function is not limited to address something intended. Function may also be referred to as an already existing behaviour that serves the designated purpose of the system (see e.g. Walker and Thomas 1985 or Chakrabarti and Bligh 2001) or to be depending on the actual application of a system during use (see e.g. Bucciarelli 2010 or Ullman 2010). The exemplary definitions in Table 2-3 provide a brief insight into the variation of notions of function that can be found in design literature. Definitions frequently overlap, but may also contradict each other, which suggests that function is interpreted quite differently by different authors. The following section discusses central notions of function that can be regarded to be generally co-existing in design literature. Section 2.3.3 gives an insight into the on-going discourse about the alternative notions of function and attempts of various researchers to address this issue.

13

Table 2-3: Overview of definitions of function in literature Reference (Rodenacker 1970), p. 25

Mechanical engineering

(Hubka and Eder 1988)

(Dym 1994), p. 4647 (Roozenburg and Eekels 1995), p. 56 (Koller and Kastrup 1998), p. 6 (Chakrabarti and Bligh 2001), p. 494 Pahl et al. 2007, p. 18

PSS design

Mechatronic system dev.

Software development

Electrical engineering

(Ullman 2010) (Walker and Thomas 1985), p. 454 (Bucciarelli 2010), p. 3

(Fowler 1998), p. 338 (Cockburn 2000), p. 26 (Kruchten 2004), p. 158

(Buur 1990) (Gausemeier et al. 2009), p. 212 (Sakao and Shimomura 2007), p. 592 (Watanabe et al. 2011), p. 4

Proposed definition “The desired transformation of properties [in relation to energy, matter or signals] defines the purpose or the function of the machine to be developed. The function of a machine is to be realised through specific physical effects.” p. 60-61: “[…] the tasks to be performed by the technical system as its output effects, [is referred to as] ‘purpose function’. […] These output effects […] are related to the ‘technical function’ as the means for achieving that aim”. p. 72: “The function is a property of the technical system, and describes its ability to fulfil a purpose, namely to convert an input measure into a required output measure under precisely given conditions.” “[Function] is the most detailed statement of the perceived need that can be made without reference to physical principles, form or embodiment […] or specific artefact types. A Function indicates what must be done without specifying how it is to be achieved”. “The function of a product is the intended and deliberately caused ability to bring about a transformation of a part of the environment of the product”. “Technical systems serve the purpose of realising a desired activity (function). [...] The entirety of what a technical artefact does will be referred to as its “function” in the following”. “[…] function is […] a description of the action or effect required by a design problem, or that supplied by a solution”. “[…] it is useful to apply the term function to the intended input/output relationship of a system whose purpose is to perform a task. […] At this stage there is no need to stipulate what solution will satisfy this […] function [...]”. p. 2: “[Function] is a description of what the product does”. p. 28: “In mechanical engineering, we commonly use the term function, operation, and purpose to describe what the product does”. “The Behavioural Domain describes the behaviour, or functionality, of the design, and contains obvious static and dynamic components”. “A device […] can fulfil different functions, [i.e. it] can be used for different purposes. The function of a resistor depends on how it is used, on context of use, on a use plan. For example, a resistive element may be used to obtain a specified voltage at a specified point in an electrical circuit. It may be used to obtain a specified current through a particular branch of an electrical circuit”. [Function is differentiated in start and outcome function] “Start functions indicate the condition for beginning an action, and outcome functions indicate the targets and side effects.” Functions “describe the behavioural portion [of a Use case, i.e. the steps required to fulfil a user goal]” “[…] we naturally tend to think about those things that the system does on behalf of the user. […] We express these actions as functional, or behavioural, requirements, which specify the actions that a system must be able to perform”. p. 56: "A (purpose) function is the ability of a machine to create an expedient effect […]” p. 73: "The transformation function (or process) of a mechatronic system is the action which changes a process object (material, energy or information) from an input state to a desired output state”. “(Function) concerns the hierarchical subdivision of the functionality. A function is the general and required coherence between input and output parameters, aiming at fulfilling a task”. Function “is a realisation method to provide the value”. Value is defined as “change of a [service] receiver’s state”. Function is “an activity […] of a service“.

Systems engineering

"Functions are discrete actions (use action verbs) necessary to achieve the system’s objectives. […] The functions will ultimately be performed or accomplished through use of equipment, personnel, facilities, software, or a combination". “A function is a characteristic task, action, or activity that must be performed to achieve a (INCOSE 2010), p. desired outcome. A function may be accomplished by one or more system elements 154 comprised of equipment (hardware), software, firmware, facilities, personnel, and procedural data”. Further collections and reviews of definitions of function can be found in e.g. Warell (1999), Maier and Fadel (2001), Chiang et al. (2001), Chandrasekaran (2005), Ericson and Larsson (2005), Crilly (2010), and Aurisicchio et al. (2011). (US DoD 2001), p. 45

14

Chapter 2: Function in Design 2.3.2

Archetypical notions of function

Based on comprehensive reviews, Vermaas (2009, 2010) and Carrara et al. (2011) conclude that despite the centrality of function to system development, there is no common notion of function and, so far, no shared definition of function has been consolidated in research. The authors claim that “[…] function lacks a single precise meaning. It is a term that has a number of co-existing meanings, which are used side-by-side in engineering” (Vermaas 2011). Vermaas and Carrara et al. generally regard functions as something purposeful that is deliberately designed into a system or serves a distinct use plan (see also Houkes and Vermaas 2010 and Bucciarelli 2010). Based on their comprehensive comparisons, Carrara et al. and Vermaas further discuss different notions of function that they consider to be archetypical to design, i.e. specific notions of function that represent the essence of the definitions of function provided by different authors in engineering design research. Carrara et al. (building on the initial research by Vermaas 2009) abstracted essentially three such archetypical notions of function; these include: function as the intended behaviour of a system, function as the desired effect of the behaviour of the system (which refers to the specific impacts that the behaviour of the system creates for its environment), and function as the purpose that the system serves (see Carrara et al. 2011). Vermaas, in recent publications, discusses a slightly different set of notions of function that he considers as central and generally co-existing in system development (see Vermaas 2011, 2013a). He emphasises a capacity-related notion of function, a purpose- or goal-related notion of function, and an intended behaviour-related notion of function. Deriving from the descriptions and comparisons of these co-existing notions by Vermaas, they can essentially be specified in the following way (see Vermaas 2013a):   

(capacity-related) function as the physicochemical capacities of the system that contribute to use the device for a specific purpose and that allows the system to achieve its designated goals; (goal-related) function as a state of affairs that a prospective user intends to achieve with a device or as the purpose for which a system is designed; (behaviour-related) function as the intended behaviour of the system.

The specific way in which these co-existing notions of function are described and differentiated from one another coincides with what the different definitions of function provided in Table 2-3 by and large refer to (as briefly discussed in the previous section). The definitions can effectively be directly mapped onto the central notions of function discussed by Vermaas (2013a). Figure 2-4 arranges the different highlighted terms from the definitions provided in Table 2-3 in correspondence with the three identified co-existing notions of function after Vermaas. Because of the direct correspondence and the conducted comprehensive analyses during the research presented in this work, the three notions of function that Vermaas discusses to be co-existing are regarded to be archetypical notions of function in this thesis (which is a slight shift in terminology compared to Vermaas). Some of the definitions in Table 2-3 combine multiple terms related to different archetypical notions, so that different combinations of the paths 1-6 in Figure 2-4 are addressed in the different definitions of function in design literature (similar findings are discussed e.g. by Crilly 2010 and Goel 2013). However regarding what the definitions essentially refer to, they still correspond to only one of the archetypical notions of function each. This is discussed in the following. 15

Function as referring to… 1

3

2

a (desired) transformation

a purpose

a change of state the ability

an input/output relation

a task

a conversion

of operands

an (intended) behaviour

an overall effect/ outcome a value

an activity

capacity-related

goal-related

behaviour-related

to fulfil/ to provide 4

6 to realise/ to fulfil

5 to fulfil/ to provide

Figure 2-4: Central terms addressed in the selected definitions of function in relation to the derived archetypical notions of function Examples 1-5 in the following illustrate how the specific terms used in the definitions in Table 2-3 correspond to the identified archetypical notions of function (the numbers in the bubbles represent an arrow in Figure 2-4): 1.

② (behaviour-related): function as referring to the intended behaviour or to a transformation of

2. 3.

③ (goal-related): function as referring to a task or a purpose to be fulfilled; ①+④+⑤ (capacity-related): function as referring to the ability to provide intended behaviour,

4. 5.

①+⑥ (capacity-related): function as referring to the ability to provide a value; ②+⑤ (behaviour-related): function as referring to an input/output relation of operands, in order

operands;

in order to fulfil a purpose;

to provide an overall effect. The latter three examples combine terms related to different archetypical notions of function. Nevertheless, Example 3 and 4 still essentially address a capacity-related notion of function, as they focus on the ability of a system to achieve something, namely an intended behaviour related to a purpose or a value, respectively. In contrast, Example 5 addresses a behaviour-related notion of function, as it focuses on the intended input/output relation. Some of the authors in Table 2-3 provide different definitions related to different types of functions. Different types of function therein frequently correspond to alternative archetypical notions of function or may focus on different aspects of the system’s functionality. For instance, Buur (1990) differentiates between “purpose functions” and “transformation functions”, which refer to a capacityrelated notion and a behaviour-related notion, respectively. Distinguishing between different types of function is also proposed by a variety of other researchers. This is investigated in the following section. 2.3.3

Different types of functions

A large amount of the definitions and discussions around function in system development refers to functions of a system in terms of a conversion or transformation of operands intended to fulfil a specific purpose (see Table 2-3). Many of these originate from mechanical engineering research or are 16

Chapter 2: Function in Design adopted from it (as already discussed in Section 1.2). However, the definition of function as a transformation of an input to an output has been repeatedly criticised. Various authors (see e.g. Warell 1999 or Maier and Fadel 2001, 2002) argue that not all functions are effectively associated to transformations, such as e.g. so-called supporting functions (typically provided by bearings, fixations, etc. in a mechanical system). These functions may not necessarily evoke the transformation of an operand, but still provide an essential part of a system’s functionality. For these kinds of functions, the definition of functions as input/output relation does not directly apply and needs to be expanded (Umeda and Tomiyama 1997). Input/output relations are further regarded to be strongly limited to a product-oriented perspective and to widely neglect the user and his/her relation with the system (Warell 1999, Maier and Fadel 2001, 2002). For instance, a car may possess the function of “providing social status” for its owner through the properties it possesses or simply by its brand name (Crilly 2010). These functions, which may directly affect users and their behaviour, can hardly be described through consideration of inputs and delivered output of the system in relation to operands of material, energy, and signals (see e.g. Scheele 2006 and Crilly 2010). Chandrasekaran and Josephson (2000) try to abstract a more universal definition of function and differentiate two types of functions based on the specific perspectives taken. They differentiate between a device-centric and an environment-centric perspective on function. The former is related to any kind of behaviour of the system, whereas the latter refers to any kind of desired external effect or purpose that is realised by the system. The addition of the environment-centric perspective implies an expansion of function e.g. to include user-related aspects. Similar differentiations are proposed e.g. by Deng (2002), Hubka and Eder (1988) or Buur (1990) (see Table 2-3). Crilly (2010) tries to put the different interpretations of function related to technical products and users into a framework. He essentially differentiates three main types of functions: technical functions (related to the actual physical properties and behaviour of a system, which goes beyond input/output relations), social functions (related to overall effects related to a user’s social context), and aesthetic functions (e.g. “convey beauty”). Similar types of functions are also proposed by Aurisicchio et al. (2011). However, the authors further differentiate economic functions (a rather product management or marketing-oriented perspective focusing on the monetary effects of a developed system for a company) and emergent functions, which refer to exhibited behaviour or other behavioural properties of the system that were not deliberately designed into it by the designers. The concept of emergent functions or – more generally – functions that can be performed by a system, without being necessarily related to the specific purpose for which the system was originally designed, is typically addressed in relation to the term “affordances”. Affordances cover the entirety of uses that a system can be put to by a user, due to the specific properties it possesses (see Brown and Blessing 2005). For instance, a shoe can be used for supporting a foot; it may – because of its solid structure – also be used for hammering a pin into a wall (see also Crilly 2010 and Maier and Fadel 2001). Functions and affordances can thus be differentiated in the following way:  

functions are related to the goal or purpose a system is designed for, in comparison, affordances refer to what the system can generally be applied for.

It seems different types of functions proposed by the authors are an attempt of grasping and relating between the different facets function as a concept may address. Each type of function uses a slightly different perspective onto what the function of system is considered to be. Different types of functions may focus on the product, its user, the general environment or their combination. Different types of 17

functions proposed by the same authors may, hence, refer to alternative notions of function, as can be seen in the discussed examples from the different researchers. 2.3.4

Implications

The review of selected definitions of function from different disciplines and the comprehensive discussions by Vermaas suggest that function has a number of co-existing meanings. Different notions of function can be regarded as archetypical irrespective of different disciplines. Some researchers discuss different types of functions, which can be partly overlapping and complementary to each other. This can be seen as an attempt to conciliate between the different notions of function that exist sideby-side. By differentiating functions with respect to what they focus on (e.g. the different perspectives) it seems, the authors strive to provide a framework, in which different notions of function and what they refer to in relation to a system is clearly defined and distinguished from one another (a similar interpretation is discussed e.g. by Crilly 2010, Vermass 2011, and Goel 2013). In light of these discussions, in this thesis, it is thus accepted that function can have different meanings. The provided examples associated to Figure 2-4 illustrate how the different definitions of function in Table 2-3 correspond to the archetypical notions of function derived from the works of Vermaas. In this thesis the differentiation between function and affordances is adopted after Brown and Blessing (2005), i.e. function is regarded as something that is purposefully designed into the system. Functions may be carried out by tangible (e.g. physical artefacts) or intangible function carriers (e.g. software systems or human activities), as discussed in Section 2.1. Associated to the term function, functionality is often used related to the descriptions of technical products and services. Warell (1999) provides a generic definition of functionality that encompasses a large variety of the terms and notions addressed in definitions across disciplines in design literature (see Table 2-3). Thereafter, the functionality of a system is “the combination of all its effects, actions, functions, and properties and their behaviour, that contribute to making the system useful for an intended purpose” (Warell 1999, p. 6). This definition is considered suitable with respect to the discussed archetypical notions of function and terminology used to describe functions in the reviewed definitions from different disciplines. Warell’s definition of functionality is hence adopted in this thesis. In the following, different approaches for function reasoning in conceptual design and their relation to the different archetypical notions of function are investigated.

2.4 Function reasoning “Reasoning” in general is defined as “the process of thinking about something in a logical way in order to form a conclusion or judgment” (Merriam-Webster 2003). It comprises the capability of human beings to make sense of – and verify – facts in problem-solving and decision-making (Kompridis 2000). “Function reasoning” essentially refers to considerations of human beings about the functionality provided by an existing tangible or intangible entity, as well as the elaboration and decision making on which entities (alone or in combination) may be employed in a specific way to implement a desired functionality (see e.g. Chakrabarti 1992). Function reasoning is regarded to be a fundamental part of human reasoning about entities (see e.g. Freeman and Newell 1971 and DiManzo et al. 1989). However, a multitude of “overlapping and partially conflicting” concepts and theories about function 18

Chapter 2: Function in Design reasoning are discussed in literature (Far and Elamy 2005, p. 76)3. In order to derive a consensus in the on-going discourse about what function reasoning essentially entails, various researchers have been comparing and trying to consolidate diverse concepts and theories associated with it (see e.g. Chandrasekaran and Josephson 2000, Chiang et al. 2001, Chakrabarti and Bligh 2001, Far and Elamy 2005, and Howard and Andreasen 2013). Based on a particularly comprehensive, cross-disciplinary comparison, Far and Elamy conclude that function reasoning “is a collective term for a variety of theories and techniques that enable people to explain the presence and function of artefacts in a containing system; to derive the purpose of the artefact, and to explain how the function can be achieved” (Far and Elamy 2005, p. 77). 2.4.1

Function reasoning during conceptual design

In the context of conceptual design, it can be derived from the reviews conducted by Far and Elamy and other researchers that function reasoning essentially encompasses the reasoning towards a potential solution concept based on function considerations. This particular reasoning typically includes the use of function models (Houkes 2006, Bucciarelli 2010) even if they remain in the designer’s mind (as discussed by Fowler 1998). The use of function models is intended to support the analysis and synthesis steps in the reasoning process concurrently. To give an example, Chakrabarti and Bligh (2001, see Section 2.2.3) consider functions to be part of the problem definition in their model of the conceptual design process (see Figure 2-3). The authors explicitly discuss function reasoning to be the essential driver of conceptual design. The described iterations lead to reoccurring reformulation in the representations of the problem to be addressed (thus including reformulation of the required functions) and the emerging solution, until the final design is determined (see also Freeman and Newell 1971 and Chakrabarti 1992). Function reasoning, as described by Chakrabarti and Bligh, thus essentially comprises the comparative analysis of which functions are required and in how far they are fulfilled in the emerging solution that is available at a specific point in time. Based on this comparison, function reasoning further contains the gradual adaptation of the available solution until the desired functions are fulfilled to a satisfying degree (see also Eder 2008). A variety of researchers propose prescriptive function reasoning approaches which are aimed at providing designers with guidance during this particular progression. These proposed approaches typically include a sequence of specific steps and associated function model(s) for the designers to apply, in order to gradually derive a potential solution concept from a given set of requirements (Chakrabarti 1992, Chakrabarti and Bligh 2001). A basic scheme to facilitate the reasoning towards a potential solution during conceptual design, which is adopted in a variety of proposed approaches (see e.g. Freeman and Newell 1971, Hubka and Eder 1988, Chakrabarti and Bligh 2001, as well as Pahl et al. 2007 and related approaches), is simply to decompose the required functionality into smaller pieces, which can be more easily addressed. In other words, the designer is encouraged to discern a given problem into less complex chunks for which adequate function carriers can be more seamlessly allocated. Allotted function carriers (i.e. solution elements) can subsequently be integrated to constitute a coherent, overall solution concept. That means, decomposition is proposed with the intention of “reducing the gap” (Blessing and Upton 1997) between the problem (i.e. the required functions) and the potential solution (i.e. the function carriers).

3

Related terms and concepts are e.g. “functional design” or “function analysis/synthesis”, see e.g. Chakrabarti (1992), Umeda and Tomiyama (1997), Ullman et al. (1992), and Eder (2008).

19

2.4.2

Fundamental function reasoning approaches

In the following, five fundamental function reasoning approaches are exemplarily presented: the Function-Behaviour-Structure framework, the Pahl and Beitz approach, Theory of Domains, and Use cases-based reasoning. The chosen examples are considered particularly interesting, as they are prominent across disciplines4. The presented approaches essentially propose steps guiding the reasoning about the required functions in a system and their dependencies, as well as the determination and evaluation of the function carriers realising them. As will be described in the following, function carriers can be specific tangible or intangible system components or human beings, but may also be specified on a more abstract level, such as in terms of basic physical effects, working principles, etc. Function-Behaviour-Structure framework The Function-Behaviour-Structure (FBS) framework proposed by Gero (1990) aims to explain how individual designers reason from a set of required functions towards a solution (i.e. function carriers). System development is described to serve the purpose of “transforming function F […] into a design description D in such a way that the artefact being described is capable of producing these functions” (Gero 1990, p. 28, see also Figure 2-5). However, it is argued that the direct transition from F to D is hardly possible (for similar reasons as discussed in Section 2.2.3, see also Gero and Kannengiesser 2002). The proposed framework (see Figure 2-5) illustrates how designers are expected to move towards a solution (i.e. a structure S) that implements the required functions (F). Gero quotes a definition of function from Bobrow (1984). Function is hence defined as “the relation between the goal of a human user and the behaviour of a system” (Gero 1990, p. 28). Behaviour is differentiated in expected behaviour (Be) (i.e. expected by the designer) and behaviour of the structure (Bs), which can be directly derived from the structure (S) of the artefact under development. Structure is described as “the artefact’s elements and their relation”.

6

F

5

S

1

3 2

8

Be

Bs

4 7

D F S Be Bs D

Function Structure Expected behaviour Structure behaviour Documentation

 

Derived from Comparison

(1) formulation, (2) synthesis, (3) analysis, (4) evaluation, (5) documentation, (6) reformulation type 1, (7) reformulation type 2, (8) reformulation type 3.

Figure 2-5: The FBS framework (after Gero and Kannengiesser 2002)

4

Other fundamental approaches discussing conceptual design in general are proposed, for instance, in C-K theory (Hatchuel and Weil 2003), Axiomatic design (Suh 2001), TRIZ (Altschuller 1999) or Property Driven Design (Weber 2007). Discussions of these approaches can be found in e.g. Alink (2010) or Chakrabarti and Blessing (2014).

20

Chapter 2: Function in Design Designers are described to reason towards the final design of the system by deriving and formulating (arrow 1 in Figure 2-5) an expected behaviour (Be) from the desired functions (F). From the determined expected behaviour (Be) a structure (S) is synthesised (arrow 2), which is intended to show the expected behaviour. The determined structure is documented (arrow 5). From the determined structure (S) the structural behaviour (Bs) can be derived through an analysis step (arrow 3). Structural behaviour (Bs) is compared with the formulated expected behaviour (Be) in an evaluation step (arrow 4). The comparison of Be and Bs is intended to evaluate the current degree of function fulfilment provided by the determined structure (S). Based on the comparison, a new or adapted structure (S) may be determined, which shows an adapted behaviour (Bs) that is (hopefully) closer to the eventually expected behaviour (Be). This step is referred to as reformulation type 1 (arrow 6). Other types of reformulation concern the specification of the expected behaviour (arrow 7) or of the functions themselves (arrow 8). Gero and Kannengiesser (2002, 2014) discuss different alternatives for designers to move through the proposed framework, depending on the specific design situation at hand. Similar to function reasoning as described by Chakrabarti and Bligh (2001, which was discussed in the previous section), the FBS framework emphasises the iterative character of design. The different steps in the framework are performed until the expected behaviour and the structural behaviour are sufficiently close. The FBS framework originates from mechanical engineering as well as architectural design research, but has also been discussed in software development (see e.g. Kruchten 2005). A critical discussion of the framework is provided by Dorst and Vermaas (2005). Function reasoning approach after Pahl and Beitz Pahl and Beitz started their research on systematic design approaches in the 1960s and 1970s (see e.g. Pahl and Beitz 1977). The proposed approach has been continuously adapted and expanded since. Pahl et al. (2007) define function in terms of the input/output relation of a system that serves the fulfilment of the system’s purpose (see Table 2-3). The proposed function reasoning approach essentially comprises the derivation of the system’s overall function from the requirements specification, as well as the subsequent decomposition of the derived overall function until function carriers may be allocated to each partial function (see Figure 2-6). In contrast to the FBS framework by Gero (1990), the approach after Pahl and Beitz has a stronger prescriptive character and a clear sequence of steps is proposed for designers to apply. In deriving the overall function from the requirements, the designer is initially expected to analyse the requirements list and to derive and formulate the “essence” or “crux” of what the system is intended to do (see Pahl et al. 2007, p. 169). That means the designer is to identify and specify the main problem to be addressed by the system to be developed. This main problem is to be described in a short textual statement, already indicating the main operands (material, energy, and signals) involved. An example of an overall problem formulation is “provide dynamic torque to deform solid objects and measure stresses and strains”, which specifies the essence of what an impulse-loading test rig is intended to do. Based on such an initial textual problem statement, the overall function of the system is determined and modelled. Therefor, the derived overall problem statements is transferred into a representation as a single box indicating the specific inputs and outputs in relation to the flow of operands in the system (see upper left part of Figure 2-6). The relationship between the inputs and outputs of the box is then used to derive a short formulation of the overall function within the box, which describes the 21

specific relationship as precisely as possible. Subsequently, the overall function is decomposed into sub- and auxiliary functions. Therein  

sub-functions directly contribute to the fulfilment of the overall function, whereas auxiliary functions are merely indirectly contributing.

Auxiliary functions enable specific sub-functions. Individual partial functions (i.e. sub- or auxiliary functions) are represented as blocks, which can be combined causally through the inputs and outputs of each block. Through combining the different partial functions, a coherent function structure is determined (see Figure 1-1 for an example). An essential requirement in the proposed approach is a solution-neutral formulation of partial functions using simple verb/noun combinations, such as “transfer torque” (see Figure 2-6). This allows for consideration and allocation of basic physical effects and working principles (i.e. abstract function carriers), which fulfil the intended functions. Through the solution-neutral formulation, designers are expected to avoid early fixation on a specific solution. Each of the decomposed sub-and auxiliary functions is eventually mapped to a function carrier. The designers’ selection of function carriers out of a set of alternatives may be supported by use of morphological charts (see e.g. Zwicky 1989). The essential difference to the FBS framework is the clear separation between function analysis and solution synthesis. In contrast to Gero (1990) and Chakrabarti and Bligh (2001), Pahl et al. propose that only after all the (sub-)functions have been sufficiently decomposed are the designers to select suitable function carriers, not before.

Figure 2-6: Function decomposition and mapping to function carriers (after Pahl et al. 2007) The basic principles of the function reasoning approach proposed by Pahl and Beitz have been widely adopted in mechanical engineering literature (see e.g. Roozenburg and Eekels 1995, Ullman 2010, Ulrich and Eppinger 2008, Stone and Wood 2000, etc.), but also in electrical engineering (Rajan et al. 2003), mechatronic system development (see e.g. VDI 1993, 2004, Gausemeier et al. 2009, and Eigner et al. 2010), and PSS design literature (see e.g. Spath and Demuss 2005, Schneider et al. 2005, Welp et al. 2007, and Sadek-Hassanein 2008). Theory of Domains The Theory of Domains was established by Andreasen (1980, 1992). It incorporates the Theory of Technical Systems by Hubka (1984, Hubka and Eder 1988) into a meta-model: the “chromosome model” (see Figure 2-7). The chromosome model links four central models from the Theory of 22

Chapter 2: Function in Design Technical Systems into a common framework: the transformation process structure, function structure, organ structure, and parts structure. The models correspond to the four domains in the chromosome model: process domain, function domain5, organ domain, and parts domain. The chromosome model makes the causal links between the entities represented in these models explicit (see Figure 2-7). Each domain (and associated model) describes the system under consideration from a different viewpoint and level of abstraction. The entities in the different domains and their relations are described in the following.

Figure 2-7: Chromosome model and related models (combination of Andreasen et al. 2014 and Eder and Hosnedl 2008) The specific relations between the different domains are defined by the capacity-related interpretation of function proposed in the Theory of Technical Systems. In contrast to Pahl et al. (2007), Hubka and Eder (1988) do not consider the transformation processes resulting in a state change of operands between inputs and outputs of a system to be the function of a system. Instead, function is defined in relation to the capability of a system to create a desired overall effect, i.e. the capability to change operands from an input state to a desired output state (see Table 2-3). This desired overall effect determines the purpose (or goal) of the system under consideration. The desired output state of operands is the result of a chain of transformation processes that are realised by operators through 5

Recent publications (e.g. Andreasen et al. 2014) question whether function should indeed build a separate domain in the chromosome model, instead it is argued that function inherently reaches across all other domains, as it is related to processes, organs, and parts alike. However, this difference in the representation of the chromosome model does not affect the proposed function reasoning approach described in this section.

23

the functions they provide. Functions are hence defined as the internal tasks of the system under consideration which realise the transformation processes (see Table 2-3) and, thus, provide the capability to realise the desired overall effect. The different domains in the chromosome model can therefore be regarded as linked from top to bottom through a “by-means-of” relation (as also discussed by Hubka 1984 and indicated in Figure 2-7). Operators can be humans, technical systems, environmental influences, etc. They are addressed in the process domain in relation to the transformation processes they realise. The function domain focuses on the functions of the technical product that is to be developed and its functional interrelations with the surrounding operators that are also contributing to the required transformation processes. The technical product to be developed may be viewed as a structure of organs in the organ domain. Organs are abstract formulations of the function carriers in the technical product under development. They are defined as “function elements (or ‘means’) of a product, displaying a mode of action and a behaviour, which realise its function and carry its properties” (see Andreasen et al. 2014). Organs are realised by the product’s parts in the parts domain. The function reasoning approach, on which the Theory of Domains is based, focuses on determining the required transformation processes and functions, in order to realise the desired overall effect, as well as the function carriers (which may be specified as organs or parts) realising them. In an initial step, the transformation process structure in the process domain is determined. The desired overall effect is initially represented as a single box indicating the desired output states of operands. Subsequently, the required inputs and main transformation processes are determined in a way, so that the desired overall effect can be realised. The transformation processes are then decomposed and allocated to different operators that will realise them. That means, in this step, the designers effectively allocate the specific transformation processes that will have to be realised by the technical product that is to be developed as opposed to those that will be realised by other means. Transformation processes are modelled in relation to a flow of operands and indicate the operators involved in their execution. For the transformation processes that have to be realised by the product under development, the required functions are subsequently determined and modelled in a function structure. A function structure models functions in a similar manner as proposed by Pahl et al. (2007, see Figure 1-1) using input/output relations for flows of operands. Based on this function structure, the designers are to determine the function carriers. The reasoning between transformation processes, functions, and function carriers is foreseen to be performed in a highly iterative manner; this includes switching flexibly between the different domains and the related models (Eder 2008). The principles of the chromosome model and the Theory of Technical Systems originate from mechanical engineering; however, they have been adopted in mechatronic system development (see Buur 1990) and also in PSS design (see e.g. Tan et al. 2007 and Matzen 2009). Use case-based function reasoning Use case-based function reasoning has originally been proposed in the 1980s and 90s to support the development of software systems in so-called object-oriented design approaches (see e.g. Jacobson et al. 1992). A variety of slightly different conceptual design approaches based on use cases are proposed in literature, one of the most prominent by Cockburn (2000, 2003). The function reasoning approach proposed by Cockburn essentially involves deriving the central goals of the prospective users of a system. Based on the derived goals, the use cases realising these goals are to be determined as well as the required functions and their carriers in the system realising the respective use cases. 24

Chapter 2: Function in Design A use case is a set of distinct activities or process steps, which are intended to achieve a specific goal of a user. These processes typically include interaction processes between the users and different elements of the system under development, as well as processes provided by the system itself (see Jacobson et al. 1992). The goal of the user is “the goal that the primary actor has in trying to get work done” or in order to receive some kind of value from the system (Cockburn 2000, p. 57). Cockburn defines the functions of the system as the behavioural aspects (i.e. the processes) of the system (see Table 2-3) or as “the services [that the] system offers” in fulfilling the use cases, i.e. in achieving the user’s goals (Cockburn 2000, p. 45). The proposed function reasoning approach starts by determining the goals of prospective users through deriving the particular (change in the) situation that the user desires. Based on these goals, the specific use cases are determined that bring about this desired new or changed situation. The use cases are initially described textually; later on, they are typically modelled graphically, including the involved users and their behaviour in interacting with different sub-systems (i.e. the function carriers) in the system under development. In this stage, the designers are, hence, already expected to allocate an initial set of function carriers. Function carriers can be concrete physical parts (such as e.g. a touchpad or buttons) or software components (such as e.g. data objects, classes, etc.). The use cases further include the specific processes (i.e. the functions or “services”) that the system needs to provide in order to address and answer the different user requests. Subsequently, interaction processes and required system processes are typically modelled in a flow in time. The modelled use cases and process flows are iteratively detailed and refined. In parallel to this detailing step, further function carriers are being determined, so that the use cases (and eventually the user goals) can be fulfilled. The proposed approach is schematically depicted in Figure 2-8. User goals are achieved by enabling

Use Cases

through their interactions contribute to use case fulfilment

are enabled by implementing

Functions

Users interact in use case execution

are enabled by

Function carriers in the system

Figure 2-8: Schema of reasoning from user goals to required function carriers (after Cockburn 2000) To give an example, a user goal may be that he/she wants to withdraw money from a cash terminal. The associated use case that brings about the user’s desired situation may be called “withdraw cash”. In order to fulfil this use case, the user will interact with the system e.g. by providing his pin code and amount of money he/she would like to withdraw. The system will then have to perform a set of processes (i.e. functions) e.g. to verify the pin code, provide the cash to the user, etc. Based on the determined functions, the required function carriers (e.g. cash delivering system, data server, etc.) can be gradually derived. As described before, use case-based function reasoning originates from software development (see e.g. Kruchten 2004, IABG 2006, etc.), but is also proposed in systematic design approaches from systems engineering (see e.g. Weilkiens 2008). Approaches proposed by different authors typically differ in terms of the proposed sequence of design and modelling steps, as well as in terms of which 25

specific models that are proposed. Use case-based approaches typically rely on standardised diagrams e.g. from UML (Unified Modelling Language) or SysML (System Modelling Language)6. These and other function models are investigated in detail in Chapter 3. 5-key-terms reasoning approach The 5-key-terms reasoning approach can be regarded as an attempt to provide engineering design research with some kind of consensus model explaining the role of function in the reasoning from a problem towards a solution during conceptual design. The approach has been proposed by Vermaas (2009, see also Vermaas 2011, 2013a) and is based on comprehensive reviews of systematic design approaches from literature focusing on the proposed function modelling and function reasoning approaches. In particular the results of the work of Brown and Blessing (2005) are highlighted by Vermaas to have been rather influential. Based on his reviews, Vermaas proposes five “key terms”, which are used to describe the function reasoning process: goal of the device, actions with the device, functions of the device, behaviour of the device, and structure of the device (see Figure 2-9).

Goals of the device Actions with the device Functions of the device

Behaviour of the device Structure of the device Figure 2-9: 5-key-term approach (after Vermaas 2009) The approach is primarily intended to be descriptive and explanatory on how function reasoning may progress from goals and intended user activities towards the function carriers (i.e. the structure). The key terms are defined in the following way:     

Goals of the device are the “state of affairs the prospective users of the device are to achieve with the device”. Actions with the device describe “a deliberate manipulation of the device by the user”. Functions of the device describe the “physiochemical capacity of the device” enabling these actions (i.e. the actions with the device). Behaviour of the device “is the physiochemical evolution of the device including the evolution of its structure and the device’s physicochemical interactions with its environment”. Structure of the device “describes the physiochemical configuration of the device” (Vermaas 2013a, p. 196).

Goals and related actions with the device depend on the specific “use plan” of a user, which refers to “a goal-directed series of actions, including manipulations of a [device] and its components“ (see Houkes and Vermaas 2010, p. 19). 6

SysML (OMG 2012) has been derived from UML (ISO 2012). Both modelling languages are considered so-called “visual modelling languages” (Friedenthal et al. 2006). They are overlapping to a large extent. Central models proposed for the use of SysML are directly adopted from UML. SysML expands UML with specific system-oriented aspects in the proposed models and their definitions (Weilkiens 2008).

26

Chapter 2: Function in Design Vermaas describes the proposed key terms as different “conceptual layers” that reasoning passes through. Based on the proposed five key terms Vermaas describes function reasoning as an “ordered sequence of steps” towards a solution (Vermaas 2013a, p. 197). The reasoning process starts with the consideration of the goals of the prospective users and their associated actions with the device, corresponding to their specific use plan. In order for the system to be capable to enable this specific use plan, the designers have to determine the functions that the system needs to possess and the required behaviour of system in correspondence with the use plan to be realised. Finally, the function carriers (i.e. the structure of the system) need to be determined in a way that the system can exhibit the expected behaviour and provide the desired functions. In moving from the user goals to the structure of the device, the reasoning process is expected to include iterations between the different layers in Figure 2-9. 2.4.3

Comparing different function reasoning approaches

Vermaas argues that the proposed 5-key-terms approach can be regarded as most detailed in explaining the different stages that function reasoning passes through during conceptual design. Based on a comparison of his key-term approach with selected function reasoning approaches proposed in literature, Vermaas (2011, 2013a) further argues that function reasoning approaches proposed by different authors often combine or by-pass one or more of the conceptual layers proposed in his approach. This is referred to as conceptual by-passing and is argued to be depending on the specific archetypical notion of function that the reasoning approaches are based on. Based on a review of Vermaas’ comparisons, the 5-key-terms approach is regarded suitable for comparing the different fundamental function reasoning approaches described in the previous section. Vermaas (2011, 2013a) already presents an exemplary classification of the approaches proposed by Pahl et al. (2007) and Gero (1990) with respect to which of the key-terms they address. A comparison between the Theory of Domains and the 5-key-terms approach has recently been proposed by Howard and Andreasen (2013). The classification of use case-based approaches is performed using the descriptions presented in the previous section. In Gero’s FBS framework, the actions with the device are not addressed. Function is used synonymously with the goals of the device and directly relates the goals to the behaviour of the device that fulfils these goals. The designers are to determine the expected behaviour (Be) from the set of desired functions. The inherent archetypical notion of function is thus goal-related. Gero explicitly addresses the behaviour of the device (i.e. the structural behaviour Bs) and the structure of the device (S) which provides the structural behaviour. The classification of the FBS framework after Vermaas (2013a) is illustrated in Figure 2-10a. In his comparison Vermaas uses the example of the “Functional Basis” by Stone and Wood (2000), which incorporates the function reasoning approach after Pahl and Beitz. Vermaas’ classification of the approach is illustrated in Figure 2-10b. Pahl et al. (2007) consider the transformation of operands between the input and output of the system as the overall function of the system. The overall function is decomposed into sub-functions, which are represented as transformations in relation to a flow of operands. With respect to the identified archetypical notions of function (see Section 2.3.2), the interpretation of function as the transformation of operands conveys a behaviour-related notion of function (see also Figure 2-4). The key-term of behaviour of the device is by-passed and integrated into functions of the device. At the same time, actions with the device are not explicitly addressed.

27

Behaviour-related

Goals of the device

Goals of the device

Goals of the device

Goals of the device

Actions with the device Functions of the device

Behaviour of the device Structure of the device

Actions with the device Functions of the device

Behaviour of the device Structure of the device

Actions with the device

Functions of the device Behaviour of the device

d) Use case-based

Capacity-related

c) Theory of Domains

Behaviour-related

b) Pahl and Beitz

a) FBS framework

Goal-related

Structure of the device

Actions with the device

Functions of the device Behaviour of the device Structure of the device

Figure 2-10: Classification of a) FBS framework, b) Pahl and Beitz approach, c) Theory of Domains, and d) Use case-based reasoning7 The reasoning approach after Pahl and Beitz is particularly well suited to illustrate the conceptual bypassing that Vermaas discusses. As described earlier, function structures after Pahl and Beitz mainly focus on the functionality of the technical product to be developed and – to a certain extent – neglect the users and their activities with the product (see Section 2.3.3). This can also be seen, for instance, when looking at the example of a function structure of a power screwdriver provided in Figure 2-11. “Human force” (as specification of energy), “hand” (material), and “manual use” (signal) effectively refer to actions with the device. However, in the provided function structure, these user actions are encompassed as operands in the screwdriver’s functionality and, hence, the user itself is only implicitly addressed. Based on the decomposition of the illustrated overall function “loosen/tighten screws” the basic physiochemical effects and working principles (i.e. the function carriers) in the product are to be determined (see also Figure 2-6). This points out the clearly product-oriented focus in the Pahl and Beitz approach: functions of the device incorporate both the behaviour of the device and the actions with the device. The analysis of the example model in Figure 2-11, hence, further supports Vermaas’ classification of the Pahl and Beitz approach (see Figure 2-10b). electricity, human force, relative rotation, weight hand, bit, screw direction, on/off, manual use

energy flow

torque, heat, noise, human force, weight

loosen/tighten screws

hand, bit, screw looseness (or tightness)

material flow

signal flow

Figure 2-11: Function model of a power screwdriver (after Stone and Wood 2000) Howard and Andreasen (2013) provide a differentiated analysis of the specific correspondences between the key-terms proposed by Vermaas and their user-related and technical product-related counterparts in the Theory of Domains. As described before, the approach is based on a capacityrelated notion of function. The function reasoning approach essentially starts by determining the central goal of the system, which is the desired overall effect. This corresponds to the goals of the device. Subsequently, the different transformation processes are determined that bring about this desired overall effect. Transformation processes correspond to the actions with the device, in case they are associated to human operators and their interactions with the system to be developed. Transformation processes may also be interpreted as the behaviour of the device, which is realised by 7

The provided classification primarily focuses on illustrating which of the key-terms are addressed, rather than the specific situation-dependent sequences in which they are addressed in the proposed reasoning approaches.

28

Chapter 2: Function in Design the functions the technical product to be developed is intended to possess. Based on the determined functions, the function carriers are constituted (i.e. organs and parts), which build the structure of the device. Hence, all five of the key-terms after Vermaas are addressed in the Theory of Domains (see Figure 2-10c) and thereby also in the related Theory of Technical Systems by Hubka and Eder (1988) on which it is based. Use case-based reasoning approaches start by determining the specific goals of the prospective users and subsequently derive the use cases that realise these goals. Use cases include the specific interaction processes between the user and the system to be developed. Hence, the goals of the device and actions with the device are explicitly addressed. Use cases further include the specific processes required from the system to address the user requests. These processes are directly associated with the functions the system has to provide. Hence, use case-based approaches use a behaviour-related notion of function. The behaviour of the device is incorporated in its function (see Figure 2-10d). Function carriers (i.e. the structure of the device) are determined in parallel to the determination and detailing of the use cases. 2.4.4

Implications

The classification of the reviewed function reasoning approaches suggests that different notions of function and the specific way how the authors propose reasoning towards a solution affect the conceptual layers that are addressed or by-passed, respectively, in the 5-key-terms approach by Vermaas. Depending on the authors, different combinations of the key terms goals of the device, actions with the device or behaviour of the device are effectively incorporated within the functions of the device. The reviewed reasoning approaches further differ in terms of what is explicitly considered during reasoning and addressed in the associated function models, even if they are based on the same notion of function. For instance, function reasoning after Pahl and Beitz and use case-based reasoning are both based on a behaviour-related notion of function (see Figure 2-10); however, while use cases explicitly include the goals of users and their interactions with the system to be developed, Pahl and Beitz specifically focus on the product-related aspects of function. These differences directly affect what is addressed in the proposed function models that are intended to support the reasoning process concurrently (as discussed before in relation to Figure 2-11). Furthermore, the specific reasoning proposed in both approaches differs. While Pahl and Beitz endorse through decomposition of the functions before basic function carriers are allocated, use case-based reasoning proposes allocating function carriers early in the conceptual design process and endorses an iterative design approach. Large differences even occur within the same discipline, which can be seen from the comparison of the Pahl and Beitz approach with the Theory of Technical Systems by Hubka and Eder (1988). From what is considered and modelled, it seems, the reasoning approach proposed by Hubka and Eder is more closely related to use case-based reasoning than it is to the approach proposed by Pahl and Beitz. At the same time, Hubka and Eder mainly rely on representing processes and functions in relation to a flow of operands in function modelling, whereas use case-based reasoning mainly relies on modelling interaction processes and functions in relation to a flow in time. Thus, similar reasoning as such does not necessarily entail similar modelling. The gained insights from the comparison of the reviewed function reasoning approaches strongly support the previous discussions regarding the connection between the notion of function an approach is based on, the way function is reasoned about, as well as what is considered during 29

reasoning and addressed in the associated function models. However, even if one or more of these aspects is similar between two approaches, the others can still be largely different. The found differences in how function is understood, reasoned about, and modelled are considered one the main reason why shared function modelling is hampered, particularly in interdisciplinary design (as already discussed by Chakrabarti and Bligh 2001 and Chandrasekaran and Josephson 2000). Different notions of function and different ways of modelling functions may be competing when designers (from different disciplines) collaborate (as already suggested by Maier et al. 2006 and Müller et al. 2007). A variety of researchers have tried to consolidate between differences in function modelling and associated reasoning, in order to support joint function reasoning and the exchange of expertise during conceptual design. Two central schemes in this endeavour are described in the following section.

2.5 Towards shared function modelling In order to support the exchange of function considerations between different designers in the solution finding process and, eventually, realise shared function modelling, one particular endeavour in engineering design research has been to increase clarity of the function models. A central aim in this endeavour has been to build function modelling on one common definition of function, in spite of the existing diversity related to notions of function (see Section 2.3.1). The research related to advancing the desired clarity can essentially be differentiated in two categories:  

2.5.1

introducing formalisation in the representation of functions, including imposing one distinct definition of function for this formalisation to be based on; converging to a common representation of function and a common definition of function from comparing and consolidating function modelling approaches proposed in literature and the notions of functions that these are based on. Introducing formalisation in the representation of function

Several researchers try to introduce formalisation in the representation of function by proposing specific “function taxonomies” that the designers are intended to use during function modelling. One particularly prominent example of a function taxonomy is the “Functional Basis” developed by Stone and Wood (2000)8. Function taxonomies specify “a standard language of function” (Ahmed and Wallace 2003, p. 1), which typically include a “standard set of functions and flows” (Stone and Wood 2000, p. 360). Function taxonomies are typically proposed to be applied in models representing functions in relation to a flow of operands using verb/noun combinations, such as function structures after Pahl et al. discussed before (see Figure 1-1 or Figure 2-11). The functions are represented through the verbs indicating the specific transformation of an operand, such as e.g. “change”, “connect”, etc. The operands in the flows are represented by the nouns. In function taxonomies, function is typically defined using a behaviourrelated notion of function. A few authors also propose the use of function taxonomies in hierarchical tree representations of functions (see e.g. Ookubo et al. 2007). Formalisation in the function taxonomies is provided by defining a vocabulary of distinct classes of functions and operands. Figure 2-12 compares such classes of functions and of the operands in the 8

Further examples and comparisons of function taxonomies can be found e.g. in Szykman et al. (1999), Hirtz et al. (2001), Kitamura et al. (2007), Metzler and Shea (2011), and Sen et al. (2010, 2013).

30

Chapter 2: Function in Design flows proposed in alternative function taxonomies. The classes proposed by different authors have often been developed based on a comprehensive analysis of function models from literature and practice. The analyses led to the derivation of distinct types of verbs and nouns, which are considered archetypical by the different authors (Rodenacker 1970, Stone and Wood 2000). The proposed vocabulary is eventually expected to improve clarity of and reduce ambiguity in the communication between designers (Kurfman et al. 2003, Chakrabarti, Bligh 2001, Sen et al. 2013). Studies with practitioners in mechanical engineering by Kurfman et al. (2003) suggest that function taxonomies can indeed contribute to the desired clarity in the communication about functions. However, function taxonomies have also been repeatedly criticised, both in research and practice.

Pahl & Beitz

Branch Cut, Branch, Separate Count, Display

Channel

Functional Basis

Hundal

Channel

Branch

Separate

Channel

Transfer

Separate, Remove, Refine, Distribute Import, Export, Transfer, Transport, Transmit, Guide, Translate, Rotate, Allow DOF

Transmit, Transport

Flows

Functions

Connect

Connect

Compare, Divide, Subtract, Switch Connect, Mix, Pack Add, Multiply, Valve Mark AND, OR

Vary

Change magnitude

Change

Convert

Crush, Process, Form, Coalesce, Change Condense, Convert, Differentiate, Evaporate, Integrate, Liquefy, Solidify Sense

TIPS (Altschuller)

Connect

Couple, Mix

Control magnitude

Change, Control, Form, Initiate, Intensify, Lower, Modulate, Raise

Convert

Create, Destroy, Generate

Provision

Accumulate

Signal

Check, Indicate, Inspect, Measure

Support

Set-up, Stabilise

Actuate, Regulate, Change, Form, Condition Convert Store, Supply, Extract Sense, Indicate, Display, Measure

Store

Store/Supply

Energy

Energy

Energy

Movement, Aerosol flow, High pressure, Friction, Mechanical & heat energy, Energy, Electromagnetic field, Radiation, Electromagnetic radiation, Light, Chemical changes

Material

Material

Material

Mixture, Object, Structure

Signal

Signal

Signal

Temperature, Position, Interaction, Dimension, State & properties, Surface properties, Volume

Stop, Stabilise, Secure, Position

Release, Store, Supply Stop, Hold

Mechanical, Electrical, Thermal/Fluid, Miscellaneous

Human, Acoustic, Biological, Chemical, Electrical, Electromagnetic, Hydraulic, Magnetic, Mechanical, Pneumatic, Radioactive, Thermal

Human, Gas, Liquid, Solid Status, Control

Figure 2-12: Comparison by Stone and Wood (2000) of their Functional Basis with the function taxonomies proposed by Pahl et al. (2007), Hundal (1990), and Altschuller (1999) Criticism Ahmed and Wallace (2003) analysed the application of function taxonomies onto functions formulated by designers in industry. They conducted interviews with practicing designers in two companies and collected verbal descriptions of the functions of different assemblies and components. These descriptions (in natural language) were afterwards translated into two different function taxonomies: the one by Hirtz et al. (2001) and the one by Szykman et al. (1999). The translation frequently led to loss of information (e.g. such as relevant operating conditions and constraints) and, for some of the 31

functions, even could not be performed. Similar experiences are discussed by van Eck (2010). Van Eck tried to translate functions represented in the “Functional Basis” by Stone and Wood (2000) into the “Functional Concept Ontology” by Ookubo et al. (2007). Apart from information loss, the conversion frequently led to errors in the representation of dependencies between functions. A potential reason for these problems may be the limitation to input/output relations in representing functions and the restrictiveness of the proposed vocabulary (as suggested by Crilly 2010 and Aurisicchio et al. 2011). It forces designers to think in a very abstract manner while contextual information used for explaining vital particularities of individual function may be lost (see also Kitamura and Mizogushi 2007). Further criticism regarding the limitation to input/output relations was already discussed in Section 2.3: they are considered strongly limited to a product-oriented perspective and widely neglect the user. 2.5.2

Converging to a common representation of function

Different comparisons of function modelling approaches can be found in literature which aim to derive one commonly accepted definition of function on which the development of a shared function model could be based (see e.g. Chandrasekaran and Josephson 2000, Chakrabarti and Bligh 2001, Garbacz et al. 2011, and Srinivasan et al. 2012). The authors suggest that achieving shared function modelling through convergence to a shared definition of function could provide suitable means for the support of cross-disciplinary communication and integration of discipline-specific design efforts. Erden et al. (2008) provide a particularly comprehensive comparison of function modelling approaches from different disciplines. They intended to abstract a generally applicable notion of function, which could serve as a basis for the development of an integrated function modelling approach. Apart from mechanical engineering, electrical engineering, and software development, they explicitly also discuss the integration of services into system development. In the search of a common definition of function, the conducted comparisons by different researchers typically used different criteria in the analysis of the function modelling approaches. Erden et al., for instance, classify the different function models with regard to the used semantic definition (e.g. whether a verb/noun formulation is applied), representation formalism (i.e. whether different types of functions are proposed), etc. Others mainly focus on the addressed types of function in a model (e.g. Chandrasekaran and Josephson 2000). The differences in the used criteria hamper a direct comparison of the analyses by different authors. Still, despite the aim of the different scholars to derive a common approach for modelling functions, so far, it has not been achieved. Many of the authors stress that different modelling approaches are incompatible and that a shared notion of function cannot be derived. In their view, the incompatibility of different modelling approaches is due to the various differences coming from the disciplines. Particularly the specific contents represented in the function models and their structure are considered to be too diverse, in order for them to be consolidated. Therefore, a shared notion of function could also not be derived thus far. Criticism Based on reviews of the analyses by Erden et al. and other authors, Vermaas (2011, 2013a), Carrara et al. (2011), and similarly Garbacz et al. (2011) conclude that the aim of achieving convergence to one shared notion of function is a-priori futile. This conclusion also led to the derivation of the archetypical notions of function by Vermaas (discussed in Section 2.3.2). Because different notions of function are 32

Chapter 2: Function in Design considered to exist side-by-side, Vermaas and the other authors further conclude that convergence of different modelling approaches (from different disciplines) cannot be achieved, as these are based on alternative notions of function and are intended to support different function reasoning approaches. The authors stress that accepting different function modelling approaches to exist and to be used sideby-side is therefore considered a necessity, as these modelling approaches are specific to the needs of the designers from different disciplines (Vermaas 2011, see also Deng 2002). However, the barriers that the differences in function modelling raise for the communication about functions between designers (from different disciplines) remain unresolved and are not sufficiently addressed by Vermaas’ and related research. 2.5.3

Studies on function reasoning and function modelling in practice

The previous sections provided a brief insight into the rich discourse in research publications about different notions of function, as well as different function reasoning approaches and proposed function models in engineering design research. In the following, the discussed insights are complemented with insights from studies of function reasoning and function modelling in practice. Particularly noticeable research in this respect was conducted by Blessing (see Blessing 1997 and Blessing and Upton 1997) and Eckert and Alink (see Alink et al. 2010, Alink 2010, and Eckert 2013). Blessing describes the experiences of a group of researchers from a mainly mechanical engineering background with applying function modelling in a design project from industry. The research conducted by Eckert and Alink (Alink et al. 2010, Eckert 2013) include an interview study as well as experiments with participants from a mainly mechanical engineering background. Alink (2010) analyses the use of function models in design projects of students and in industry. Similar studies have also been published by Ullman et al. (1988), Visser (1991), Fricke and Pahl (1991), and Matthiesen et al. (2013). Further insights can be taken from Buur (1990) and Goel (2013) who discuss experiences with function modelling in different disciplines. Problems with solution-neutral function modelling Blessing (1997, see also Blessing and Upton 1997) describes experiences with function modelling after Pahl et al. (2007). Blessing found that modelling functions in the proposed strictly solution-neutral manner that is proposed by Pahl et al. (see Section 2.4.2) led to several difficulties in the application. The participants in the design project often felt restricted in their modelling and design activities. The hierarchical decomposition of functions and the input/output-based function modelling were considered rather abstract and difficult to perform without reference to a potential solution. Similarly, Albers et al. (2010) and Eckert et al. (2010) argue that – in many cases – required sub-functions depend on the specific configuration of selected solution elements. Hence, these sub-functions cannot be modelled or derived, respectively, from a strictly solution-neutral representation. Blessing and Upton (1997) and similarly Eckert et al. (2010) emphasise that designers – by nature – tend to make assumptions about the potential solution and model functions accordingly in an iterative process. In the study described by Blessing, it was beneficial for the designers to start modelling based on the existing system solution, in order to develop an understanding of its functions and their dependencies. Blessing further found that iterations between function modelling and modelling of a potential solution concept frequently sparked further ideas in the group for alternative solution

33

concepts. These insights correspond to the general insights on the iterative character of function reasoning discussed in Section 2.4.1 and are similarly discussed by Visser (1991). In addition, the participants in the study presented by Blessing frequently required information about the temporal order between modelled functions; however, this kind of information is not explicitly represented in function structures after Pahl et al. (2007). Also, function structures can only represent one specific decomposition of the overall function into sub- and auxiliary functions at a time; alternative compositions of sub-functions have to be modelled separately. Vermaas (2013b) further argues that a strictly hierarchical decomposition is often not possible from a logical point of view. Due to the multi-fold dependencies between functions on different hierarchical levels, for instance, different top-level functions may require the same auxiliary functions in parallel. Complex interrelations and links between selected sub- and auxiliary functions simply cannot be adequately represented in a strictly hierarchical structure once a certain level of complicatedness is exceeded. Function modelling needs to support flexible reasoning in practice Eckert and Alink focused on investigating the reasoning about functions. Their studies suggest that designers in practice do not necessarily use a clear definition of function. When asked about their personal understanding of function in the interviews prior to the conducted experiments, participants essentially addressed notions of function as   

purpose (i.e. the goal or the task) of technical products or specific components, flows of operands (i.e. material, energy, information), and transformation processes (i.e. input/output relations and state changes).

Furthermore, several participants referred to specific syntactical characteristics in the description of a function to be a notion of function; for instance, one participants claimed that “functions need a verb” in order to specify what the provided function is (see Alink et al. 2010, p. 412). In the experiments, the participants were asked to model the functions of a pump, which was presented to them. Eckert and Alink found that 

  

the specific formulation of functions in the generated models differed in terms of the used level of abstraction and in terms of used syntax (here syntax refers to the use of verb/noun combinations or the use of natural language to formulate functions, alternatively); while analysing and modelling the pump’s functions, participants formulated the functions on an inconsistent level of abstraction; the notion of function that the participants described in the preceding interviews frequently differed from the one they applied during modelling; several participants switched unconsciously between different notions of function while they were modelling the functions of the pump and because of this switch, the modelled functions differed in their formulations.

Alink et al. (2010) discuss a few examples of switches in the applied notion of function. One participant, for instance, expressed the main function of the pump in terms of an input/output relation as “convert power”. However, functions that were formulated later on in the experiment by this person rather referred to the intended behaviour of the pump, such as e.g. “haul fluid”. Alternatively, functions were also formulated as the ability to achieve an effect, such as e.g. “enable rotation”. Alink et al. further argue that participants also changed the specific way they reasoned about the functions of the pump: 34

Chapter 2: Function in Design depending on how function was interpreted at a specific point in time (i.e. which specific notion of function was applied), the reasoning about the system’s functions changed accordingly. That is to say, the participants switched between analysing the pump’s functions based on inputs and outputs of the pump and its components, based on the transformations of operands that they thought would be taking place or based on the purposes they considered specific components to serve. The way function was reasoned about surfaced in the way functions were modelled or verbally expressed concurrently. The different notions of function that Alink identified in the experiments correspond to the archetypical notions of function that Vermaas derived from literature (see Section 2.3.2). Eckert (2013) therefore concludes that the archetypical notions of function by Vermaas by and large are also valid in practice. Based on the findings in their combined studies, Eckert and Alink further argue that designers in fact need flexibility in modelling functions to support their function reasoning process concurrently. Based on own studies and a review of the publications by Eckert, Alink, and Vermaas, Goel stresses that "functional models of complex systems and functional reasoning about the systems are closely intertwined. Functional models, and meanings of functions, are constructed to support functional reasoning (and not the other way around). […] We see different meanings of function not as an obstacle to functional modelling, but as a critical source of the power of functional reasoning” (Goel 2013, p. 213). Function modelling should, hence, be able to cope with different notions of function and flexible changes in the way functions of a system are reasoned about (which is similarly discussed by Buur 1990, Goel 1995, Henderson 1999, and Lawson and Dorst 2009). Discussion The studies on function modelling and reasoning in practice suggest that practicing designers tend to switch flexibly between different notions of function, depending on their current strain of reasoning about the functions of a system and its components. Function reasoning approaches proposed in literature, in contrast, are based on one specific definition of function and propose function models that fit to the proposed function reasoning approaches (see Section 2.4). In particular the comparison presented in Section 2.4.3 suggests that depending on the proposed function reasoning approach, different contents are addressed in the associated function models. As designers tend to switch between different notions of function during function reasoning, the proposed function models may not always match their needs. Due to the flexibility required by practicing designers, the benefits of the application of function taxonomies during conceptual design – in spite of the potential benefits they offer in terms of clarity – seems to be limited, at least in terms of ease of application, instead – it seems – flexibility in modelling needs to be supported.

2.6 Summary and discussion The central design decisions are taken when conceptualising a system. In order to facilitate collaboration and the exchange of expertise between designers from different disciplines in this process, a shared understanding of the system under development is essential among involved designers. Function modelling is proposed with the intention of facilitating the central transition from the required functions to the potential solution implementing them and is further considered to offer a support for the establishment of the required shared system understanding. However, as was discussed in the previous sections, a shared notion of function is missing and diverse function 35

modelling and reasoning approaches are proposed. The presented research in this thesis aims at providing a function modelling approach, which eventually can provide support for interdisciplinary collaboration and the exchange of expertise. Function modelling is connected to the specific reasoning about functions applied and the notion of function it is based on (see Sections 2.4.4 and 2.5.3). As shown in Table 2-3, various definitions of function exist in design literature and different notions of function exist side-by-side, both in research (see Section 2.3) and in practice (see Section 2.5.3). Yet, even in case the same notion of function is used in proposed function reasoning approaches, reasoning about functions and associated function models may differ largely (see Section 2.4.4). Insights from research and practice (see particularly Sections 2.4.3 and 2.5.3) strongly suggest that what is considered during the reasoning about functions and what is addressed in associated function models are directly linked (as indicated in Figure 2-13). Function modelling needs to be able to support the flexible reasoning irrespective of the notion of function applied (see Section 2.5.3). That means, function modelling needs to enable combining different contents and/or relate between them, in order to facilitate the exchange of function considerations between designers (from different disciplines). However, it is particularly the differences in addressed contents and the way functions are represented that are considered central barriers for integration of function models proposed in different disciplines (see Section 2.5.2). notion of function

function reasoning

Focus of the research project

function modelling

Figure 2-13: Relation between the notion of function, function modelling, and function reasoning It is concluded in this thesis that a function modelling approach is required, which is capable of adequately coupling or relating between different contents addressed and ways of representing functions in different disciplines. Such an approach further needs to provide designers with the flexibility they require in the reasoning about functions. These two issues seem contradicting and further research is required to support the development of an adequate integrated function modelling approach. Such an approach would be expected to support the establishment of the required shared understanding of the system to be developed through relating between what is typically considered by designers from different disciplines. This in turn is ultimately expected to enhance shared function modelling and reasoning towards a solution concept in interdisciplinary design.

2.7 Refined research questions and objectives The overall goal of the research presented this thesis is the development of a function modelling approach, which is capable of facilitating integration between function modelling of designers from different disciplines and, at the same time, is capable of supporting flexible function reasoning during conceptual design in practice. To support the development of such an integrated function modelling approach, a detailed analysis of different function models with respect to addressed contents and their typical application is required, in order to derive insights on how they may be adequately coupled. As 36

Chapter 2: Function in Design part of this analysis, the actual application of function modelling as well as needs and preferences of designers in practice need to be explored. In order to guide the required analyses, the fundamental research questions presented in Chapter 1 are refined into the following questions, which will be addressed in the next chapters:      

What kind of models are proposed for function modelling in literature and used in practice? What is addressed in different function models (from different disciplines)? How is function modelling applied in (interdisciplinary) design practice? What are good and bad experiences with applying function modelling in (interdisciplinary) design practice? What kind of support is required or considered useful for integrated function modelling? What are different notions of function addressed by designers in practice?

The questions will be answered using comprehensive literature reviews (see Chapter 3) of function models proposed in different disciplines and in interdisciplinary design approaches. The literature reviews are complemented with empirical studies in interdisciplinary design practice (see Chapter 4). The results of both the literature reviews and the empirical studies are consolidated, in order to derive specific requirements and potential opportunities guiding the development of an adequate integrated function modelling approach.

37

3 FUNCTION MODELLING APPROACHES

This chapter presents a comprehensive literature review comprising a detailed analysis of different function models proposed in disciplinary and in interdisciplinary design approaches. In Section 3.1 function models are analysed with the intention to explore and differentiate distinctly addressed contents and ways of representing functions in the models9. The derived insights are used in Section 3.2 to analyse the proposed application of the function models, in order to determine which specific contents and modelling approaches are particularly prominent within and across the disciplines.

3.1 Analysing function models This review focuses on models representing aspects of system functionality that are intended to support the reasoning towards a solution during conceptual design. A variety of such function models can be found in literature. Many originate from systematic design approaches (see also Sections 2.4), while others are independently proposed. The discussion of the function models proposed in the reviewed fundamental function reasoning approaches (in Section 2.4.3) suggested that different function models are specific in relation to the addressed contents and the way the represented functions are structured (see also Section 2.6). In Figure 3-1 two examples of functions models from use case-based modelling (a use case schematic with associated activity diagram) are compared to a function tree to highlight some of the differences between addressed contents and structuring of represented information in different function models. Use case schematic for online management system of university courses and associated activity diagram for use case of “select courses to teach” System to be developed Professor

Select courses to teach

Course catalogue

Maintain professor info

Function tree for an electrically controlled joint to position an object

Position object

Professor selects to register for courses System displays a blank schedule

Ensure accuracy of movement

System retrieves list of available courses

Submit grades

…

a) Use case schematic

b) Activity diagram

Control speed of movement

… Correct position

Registrar

…

Measure position

c) Function tree

Figure 3-1: Examples of a) use case schematic and b) associated activity diagram (adapted from Kroll and Kruchten 2003), c) function tree (adapted from Gausemeier and Möhringer 2001)

9

Parts of the review and initial findings presented in this section have been published in Eisenbart et al. (2012a).

39

Both use case schematics and associated activity diagrams are considered function models in this thesis, as they represent aspects of the functionality of system components and associated users on an abstract level (see also Warell 1999 and the related discussions in Section 2.3.4). Use case schematics illustrate involved users, system components, and their interactions associated to different use cases. As discussed in Section 2.4.2, use cases contain a sequence of specific processes, which are modelled in detail in an associated activity diagram. These represent the interaction processes between users and the system under development (e.g. “professor selects to register for courses”, see Figure 3-1b), as well as the sequence of functions (represented as system processes, e.g. “system displays a blank schedule”) that have to be provided by the system, in order to fulfil the desired system functionality. For each use case, an associated activity diagram has to be produced. In contrast, function trees focus on the strictly hierarchical decomposition of the overall function of a system into sub- and auxiliary functions (see Figure 3-1c). In function trees, no reference is made to system components or users. 3.1.1

Approach

The analysed function models come from mechanical engineering, electrical engineering, software development, and service design, as well as from interdisciplinary approaches proposed in mechatronic system development, PSS design, and systems engineering. The presented review is guided by the questions:  

What is represented in function models proposed in different disciplines? How is the represented information structured?

In an initial step of the performed review, the selected models were analysed and categorised using an established generic, cross-disciplinary classification scheme after Buur and Andreasen (1989), which is based on the modelling activity and model characteristics, respectively (see Figure 3-2). The modelling activity addresses the aspects of    

the object (e.g. function structure, feature list, etc.), the modelled properties (e.g. specification of overall and sub-functions, transformation of flow of operands), the purpose for modelling (e.g. structure hierarchically, indicate sequence of transformations in time), and the user of the model (e.g. the designers, clients, etc.).

The model characteristics are  

the used code (e.g. human language, symbols, drafting standards) and the used medium (such as paper, pictures, etc.).

The individual aspects within the columns proposed by Buur and Andreasen in Figure 3-2 merely represent examples. They can be complemented with new entries and more than one aspect in each of the columns can be addressed by a single model (as already discussed by Brandt 2005).

40

Chapter 3: Function Modelling Approaches

THE DESIGN MODEL

Reproduction projected spatial

paper photograph movie, video computer display

3 Dimensional standard components raw materials (paper, cardboard, wood, plastic, foam, metal, clay,...)

Coarse

Abstract Simple

Talking Graphics

...

Others

...

Computer NC machine ...

Destruction

MEDIUM

...

Colleagues Project team Draftsman User Salesman Client Manager

...

function ease of operation reliability

...

...

total form dimensions

Usage

letters numbers mathematical terms electrical symbols mechanical symbols drafting standard flow chart symbols

...

Parts structure

design appeal ease of packing

Language Symbols

The designer himself

...

...

working principles

Marketing

...

Organ structure

...

...

necessary effects interface

CODE

...

impact on environm.

Fine

...

...

technolog. principle Manufacturing order of operations tolerances Function structure assembly time

Define Generate ideas Describe Verify Evaluate Specify Arrange information

USER

Level of abstraction Number of details

PROPERTY

Design Problem time consumption Criteria Process Structure costs

PURPOSE

Concrete Detailed

OBJECT

Manufacturing techique

THE MODELLING ACTIVITY

Figure 3-2: Generic model classification scheme (adapted from Buur and Andreasen 1989) In order to answer the posed questions, the classes of object, property, purpose, and coding are particularly beneficial, as they specifically focus on the models’ contents, forms, and structures. Table 3-1 exemplarily illustrates the categorisation of the function models shown in Figure 3-1. Table 3-1: Exemplary classification of function models after using the classification scheme by Buur and Andreasen (1989) Function model Use case schematics

Use case activity diagram

Function tree

Object

Property

Purpose

Code

Actor network: use cases and related interactions between users and technical (sub-)systems Process flow: interaction processes and functions performed by the system related to one use case Function tree structure: overall, sub- and auxiliary functions

Stakeholders (e.g. users) and technical sub-systems interacting in different use cases

Visualise and facilitate analysis of technical products and users involved Visualise and facilitate analysis of user and system processes (i.e. system functions) Decompose system functions and structure hierarchically

Symbols for humans and technical products, arrows for interaction processes, etc.

Processes of users and of the system in fulfilling a use case Hierarchy of system functions

Boxes for processes, arrows for flow in time Hierarchical decomposition, verb/noun representation

Based on the analysis, distinct function modelling perspectives addressed in the individual models as well as distinct modelling morphologies were identified: 



Function modelling perspectives refer to the particular contents addressed by individual function models. That is to say, they relate to what is explicitly modelled in a specific function model, in order to represent individual functions and overall system functionality. Modelling morphologies refer to the way represented information is structured in the different function models; this conveys information about how individual functions are linked or are dependent on one another.

Using the identified function modelling perspectives and modelling morphologies, a wide selection of function models proposed in disciplinary and cross-disciplinary design approaches were analysed and categorised with respect to the modelling perspectives they address and the kind of morphology they use. An overview of the analysed function models is presented in Table 3-2. For several of these, variants are proposed by different authors. In these cases, each variant was analysed and categorised 41

separately. Overall, a total of 76 function models (61 original models plus 15 variants) are considered in the review. The models originate from mechanical engineering (n=20 models), electrical engineering (n=8), software development (n=10), mechatronic system development (n=12), service and PSS design (n=16) as well as systems engineering (n=10). A few models, such as e.g. IDEF-010, are proposed by multiple authors in different disciplines. Table 3-2: Overview of reviewed function models Main references* Ehrlenspiel 2007

Function models Context and flow diagram

Main references* Salminen and Verho 1989

Ehrlenspiel 2007

Event list

Salminen and Verho 1989

Function-Means-Tree

Buur 1990

Mechatronic system development

Function models Functions list

Hubka and Eder 1988 Hundal 1990 Function structure

Pahl et al. 2007 Rodenacker 1970 Ullman 2010 Ulrich and Eppinger 2008

Function tree Function-Means-Tree Man/machine separation list

Process flow model

Ullman 2010 Pugh 1991 Andreasen and Hein 2000

Kajitani 1986 (in Buur 1990)

(Initial) behaviour diagram

Gausemeier et al. 2009

(Active) purpose functions

Buur 1990

State transition diagram

Salminen and Verho 1989 Buur 1990

Transformation functions

Buur 1990

Block diagram

Fisher and Schutta 2003

FAST11 model

Donaldson et al. 2006 Kaufman and Woodhead 2006

Process structure

Blessing and Upton 1997

Transf. process structure

Hubka and Eder 1988

User action sequence

Ulrich and Eppinger 2008

Use concepts

Roozenburg and Eekels 1995

CFRL12

Iwasaki et al. 1993

Finite state machine

Belzer et al. 1975

Function block diagrams

van Alven 1964

Function tree

Scheffer et al. 2006

Function table

Scheffer et al. 2006

Petri net

Baumgarten 1996

Chain of actions

Sequence diagram

ISO 2012

View model (VM)

(V)HDL specification

Dewey 2000, Bleck et al. 1996

VM + realisation structure

Feature list

Kruchten 2004

Functional Flow Block Diagr.

US DoD 2001, NASA 2007

Function flow diagram

Bosman 1978

IDEF-0 (SADT)

INCOSE 2010, US DoD 2001

IDEF-0 (SADT)13

Ross 1977,

N2-matrix

US DoD 2001, NASA 2007

Release backlog

Schwaber 2007

State diagram

NASA 2007

Sequence diagram

Kruchten 2004, IABG 2006

Time Analysis Sheet

NASA 2007, US DoD 2001

Storyboarding

Cooper 2007

Use case descriptions

Kruchten 2004, IABG 2006

Use case schematics

ISO 2012, IABG 2006, Kruchten 2004

Use case activity flow diagram

Kruchten 2004, IABG 2006

Systems engineering

Electrical engineering

Gausemeier et al. 2009

Hybrid function/solution model Möhringer & Gausemeier 2002

Customer chain (CC)

Process-function chart

Software development

Function structure

Salminen and Verho 1989

Customer activity cycle (CAC) Tan 2010

Tjalve 1978

Service development and PSS design

Mechanical engineering

Stone and Wood 2000

Function tree

Functional block diagram Interactor network

Maussang-Detaille 2008

IDEF-0 (SADT) Service blueprint

Shostack 1982,

Service process model

Watanabe et al. 2011

Scenario model Flow model Scope model

Sakao and Shimomura 2007

Use case flow diagram Sequence diagram State diagram Use case schematic

Weilkiens 2008

Use case activity flow diagram

*Some models are similarly proposed by different authors; however, if the models differ to a relevant extent between references, a new row is added for each. For instance, the function tree by Gausemeier et al. (2009) looks fairly different from the one by Salminen and Verho (1989).

The following sections describe the identified function modelling perspectives and modelling morphologies and show the specific categorisation of exemplary function models. Sections 3.1.4 and 10

ICAM DEFinition for Function Modelling (IDEF), “ICAM” stands for “Integrated Computer Aided Manufacturing” Function Analysis System Technique (FAST) 12 Causal Functional Representation Language (CFRL) 13 Structured Analysis and Design Technique (SADT) 11

42

Chapter 3: Function Modelling Approaches 3.1.5 provide an initial discussion of the identified perspectives and morphologies in relation to the insights derived from the review of current research, which was presented in Chapter 2. 3.1.2

Function modelling perspectives

Seven distinct function modelling perspectives were identified: states, transformation processes, interaction processes, effects, use cases, as well as technical system and stakeholder allocation. Several function models address multiple function modelling perspectives. In a few models, additional distinct contents were found, which are described at the end of this section. The perspectives are described in the following. The descriptions are complemented with examples of the function modelling perspectives based on a welding robot using welding tongs to connect metal sheets. 

States: Representation of the states a system can be in, or of the states of operands before (input) and after (output) a transformation process. Operands are typically specifications of energy, material, and information. Welding robot: The welding robot changes the state of metal sheets (operand) from “loose” to “welded”, while the state of the welding tongs (system) changes from “open” to “closed”. Example models: Finite state machine (see e.g. Belzer et al. 1975), process structure after Blessing and Upton (1997, see Figure 3-3).

A

B

Compartment closed Tip not deployed Tip not attached

Compartment not closed Compartment not closed Tip not deployed Tip deployed Tip not attached Tip not attached Note: deploying and attaching done separately

Compartment closed Tip not deployed Tip not attached

Compartment not closed Tip deployed Tip not attached

Compartment not closed Tip deployed Tip attached

Compartment not closed Tip deployed Tip attached

Note: opening and deploying done together; attaching done separately

Figure 3-3: Two alternative process structures for an in-flight refuelling probe proposed by Blessing and Upton (1997) 

Transformation processes: Representation of the processes executed by the function carriers (technical products, stakeholders, etc.) that – from the designers’ perspective – are part of the system under development and which may or may not result in a change in state of the system or of operands. Therein, - technical processes are transformation processes executed by technical systems (technical products, sub-systems, etc.); - human processes are executed by stakeholders involved in function fulfilment (this explicitly includes human activities e.g. during service execution). Transformation processes require various physiochemical effects to be provided by technical systems or stakeholders. Effects are described later on in this section. Welding robot: The welding robot needs to “move into position” and “close the welding tongs”, in order to connect the metal sheets. Example models: Technical process structure after Hubka and Eder (see Figure 3-4), use case activity diagram (see e.g. Figure 3-1b), CAC model (see Figure 3-5). 43

Figure 3-4: Transformation process structure (reprinted from Eder and Hosnedl 2008)

Early awareness Kidneywise.com

Various relevant services

General-practitioner awareness, training

Pre

Help lines, information sites, Kidneywise.com

“deciding what to do“

Early and speedy diagnosis

Experiences symptoms Haemodialysis at home

Has a kidney transplant

Early diagnosis

Receives diagnosis

Has next treatment Maintenance and replacement of equipment Remote prescription adjustment Mobile nurses

Customer Activity Cycle

Post “keeping it going “

Chooses treatment

During “doing it“ Start treatment

Adjust treatment

Telemedical monitoring

Organises supplies/ home dialysis

Is monitored Delivery of other drugs

Mobile units

Goes to doctor

Treatment-option educators in clinic

Training Help lines, peer support Installation of equipment Personalised home care and delivery

Has dialysis

“Edutainment” and education

Emergency, 24-hour help lines and phones

Figure 3-5: Example of customer activity cycle (CAC) for a medical service proposed by Vandermerwe (2000)14 

Interaction processes: Representation of interaction processes of stakeholders or of other technical systems, which – from the designers’ perspective – are not part of a system, with stakeholders or technical systems, which are part of the system under consideration. Welding robot: If the robot is sold to a customer, without services associated to it, “exchange electrodes”, “type in position information”, etc. are regarded as interaction processes with the system; in a service, interaction processes are e.g. “deliver/hand-over materials to customer”. Example models: Use case schematic and/or use case activity diagram (see Figure 3-1a and b).

14

The CAC represents the activities of a customer before, during, and after service execution. In addition, the associated service activities are represented. The basic CAC has recently been expanded with additional layers, to address e.g. stakeholder needs and required resources for service execution (see e.g. Mougaard et al. 2012).

44

Chapter 3: Function Modelling Approaches 

Effects: Representation of the required physiochemical effects, which have to be provided to enable, respectively support, the transformation processes that change the state(s) of operands and/or of the system into (a) new state(s). Welding robot: Within the welding robot physiochemical effects are used to transform electrical energy (as operand) into torque and movement to close the welding tongs (by using basic physiochemical principles); similarly, the welding tongs will have to convert the torque closing the tongs into force to place a spot weld. Example model: Function structure after e.g. Pahl et al. (2007, see Figure 1-1 or Figure 3-6) or Stone and Wood (2000, see Figure 2-11). Legend: energy material signals

Transfer FA from rot. to stat. system

ω, FA ω, FR

Transfer FA and FR in rot. system

Transmit FR from rot. to stat. system

Transmit FA and FR to foundation

Feed oil

Build up oil pressure

Remove losses

FA , Δlr  0

Connect bearing to foundation

FR , Δlr  0

.

Voil_in Poil_set

Store oil

Seal rot. and stat. system

. Voil_out

Transfer oil Set and measure oil pressure

Poil_measured

Figure 3-6: Function structure of a hydraulic bearing system (adapted from Pahl et al. 2007) 

Use cases: Representation of different scenarios of applying the technical system for a specific purpose (e.g. fulfilling a goal, changing the state of the system or user, etc.); this is typically associated to the interaction of stakeholders or another technical system with the technical system under development (interaction processes), which triggers, respectively requires, subsequent processes to be carried out by the system (see also Section 2.4.2). Welding robot: A use case of the welding robot is “display the position of the end effector”, which includes a user who “requests the robot to display the position of the end effector” as an interaction process, as well as several sub-processes within the robot, such as “measuring position”, “processing data”, etc. Example models: Use case schematic (see e.g. Figure 3-1a).



Technical system allocation: Representation of the role of technical products, their subsystems or any other kinds of (tangible or intangible) technical means acting as function carriers in performing or enabling one or more functions; these technical means may be either part of the system under consideration or interact with it. Welding robot: The role of the welding tongs (technical sub-systems) is to implement the welding function, the functions involved in changing the electrodes of the welding tongs may be allocated to another robot. Example models: Use case schematic (see e.g. Figure 3-1a), transformation process structure after Hubka and Eder (see Figure 3-4), service process model (see Figure 3-7). 45



Stakeholder allocation: Representation of the roles of different stakeholders (humans or other animate beings), which may be users benefitting from a system or function carriers contributing to the system, e.g. through executing required processes or providing resources, etc. Welding robot: In the PSS context, a service associated to the welding robot may involve stakeholders, such as a mechanic, to change the electrodes; other stakeholders may be personnel from a company who deliver new electrodes. Example model: Transformation process structure after Hubka and Eder (see Figure 3-4), service process model after Watanabe et al. (2011, see Figure 3-7). Provider: Organisation

Receiver: Consumer Action cost CONTROL

Resources

Received value

OUTPUT

INPUT

Service activity (function) MECHANISM

Environmental burden

Natural resources

Third party: Environment

Figure 3-7: Schema of a service process model (after Watanabe et al. 2011)

Additional contents found in a few models The identified seven function modelling perspectives represent specific information related to system functionality addressed in the reviewed function models. In a few models additional contents were found that are aimed at supporting the solution finding process and/or the reasoning about specific aspects of system functionality. These are:   

constraints and target values for function execution, impacts from/on the environment, and (alternative) solution principles.

Constraints and target values specify the prospective functions and their execution by the system. An example is “provide 5 to 10 Nm of torque” instead of simply stating “provide torque”. For instance, Pahl et al. (2007) stress that the solution finding process may be enhanced by including information about constraints for function fulfilment and/or associated target values already during function modelling. By making this information explicit in function modelling, the designers should be able to exclude unsuitable solution concepts more easily later on. For example, transporting an object which weighs two tons cannot be performed manually by a single person. Constraints and target values are explicitly included in function models, e.g., by Salminen and Verho (1992) and Gausemeier et al. (2009). Impacts from the environment on a system may impair function execution or function fulfilment, due to eventual disturbances. In turn, impacts from a system on the environment may be critical and subject to safety requirements or environmental legislation. Pahl et al. (2007) and Hubka and Eder 46

Chapter 3: Function Modelling Approaches (1988) explicitly stress that impacts from/on the environment need to be considered during conceptual design to facilitate finding viable solution concepts. The transformations process structure of Hubka and Eder (1988, see Figure 3-4) and the service process model of Watanabe et al. (2011, see Figure 3-7) explicitly include the environment as an actor influencing or being influenced by individual processes. Some function models combine modelling functions with (alternative) solution principles to support and make explicit the selection of potential solution principles out of a variety of alternatives. An example is the Function-Means-Tree (see Figure 3-8) or a morphological chart (see Pahl et al. 2007). An alternative example is proposed by Gausemeier and Möhringer (2001), who combine blocks indicating functions with the hierarchical representation of principle solutions (see Figure 3-9). Gausemeier and Möhringer aim to allow “hybrid” modelling of systems focusing on offered or required functionality and/or the system’s hierarchical structure. The inclusion of alternative solution principles may also support function-sharing considerations. Function-sharing refers to the combination of different functions into one solution element, in order to reduce the number of function carriers in a system (as proposed e.g. by Andreasen and Hein 2000). Blessing and Upton’s process structure (see Figure 3-3), for instance, emphasises considerations about combining different state transitions by evaluating alternative flows of state changes and alternative solutions for their implementation.

Figure 3-8: Example of a Function-Means-Tree of a projector (see Buur 1990) Legend: Function Function carrier function carrier = girder

Position object Position sensor Hold object Digital electronics

…

function = control accuracy of movement function = monitor position of object

Figure 3-9: Combined or “hybrid” modelling of functions and solution principles in one model (simplified from Gausemeier and Möhringer 2001) 47

3.1.3

Modelling morphologies

Essentially three main ways of structuring and linking functions and associated information can be discerned in the reviewed function models:   

hierarchical structure, flow in time, and flow of operands (input/output relation).

…

Hierarchical structures representing functions can be found, for instance, in simple function lists (see Figure 3-10) or function trees (see e.g. Figure 3-1c and Figure 3-8). Typically, the decomposition follows a strict “is part of” relation (see Vermaas 2013b). As discussed in Section 2.4.2, the overall function of a system can be decomposed into sub- and auxiliary functions until function carriers can be found and allocated by the designers.

System function 3 Sub-function 3.1 Sub-function 3.2

Sub-function 3.3

…

System function 4

Figure 3-10: Schema of a hierarchical function list Flow in time is a particularly prominent means for structuring information in function models from software or service development, but is also proposed in other disciplines. The represented functions are structured in relation to their chronological sequence or parallelism in time (see e.g. a service blueprint after Shostack 1982 presented in Figure 3-11b). Flow of operands has already been discussed related to function structures after Pahl et al. (2007, see Figure 3-6) and Hubka and Eder (1988). Another example of a function structure from Stone and Wood (2000) is provided in Figure 3-11a. Flows of operands represent the successive transformations of one or more operands from input to output of a system. Within the models, functions are usually represented as blocks, which are causally linked through the flow of operands between them; i.e. the output of one function serves as input of another function. The flow in time is only implied; it is not driving the structuring of the function models as it is the case in models, which are purely based on a flow in time. The difference between the two types of flows is illustrated in Figure 3-11. In Figure 3-11a, the user of the model may derive how one particular operand is transformed within the system, but cannot necessarily derive the (particular) point in time when a transformation is taking place compared to transformations in flows shown parallel in the same model. For instance, in Figure 3-11a it is not clear whether the transformation processes of “secure solid” and “rotate solid” are carried out in parallel or in sequence. The flow of operands only reveals a causal sequence based on which transformations of operands need to be finalised before another transformation can take place. This has been one of the main aspects of criticism of this kind of representation, as discussed in Section 2.5.3. In contrast, in Figure 3-11b the relative point in time (and in the presented example also the duration) of the different

48

Chapter 3: Function Modelling Approaches operations of buffing shoes are shown explicitly. Such models, however, usually do not represent the concerned operands. bit hand h.f.

relative rotation

couple solid

h.f. hand bit

secure solid

h.f. hand bit

screw

manual use human force

a)

h.f. hand bit

separate solid

h.f. import hum.force

h.f.

stop rot. energy reaction

rotate solid

force

h.f.

h.f.

force

force

h.f.

dissipate allow rot. reaction force reaction DOF

rel.rot.

screw 1

transmit Standard force

h.f.

weight

execution times

h.f.

2

Brush shoes

3

Apply polish

30 sec.

h.f. Buff weight

30 sec.

F1 F1 Clean

b)

Line of visibility

h.f. Materials (polish, cloth)

shoes 45 sec. Not directly seen or experienced by customer, but necessary to perform the service

Collect payment 15 sec.

45 sec.

Fail Wrong point colour wax

actuate electricity

4

Select and purchase supplies

Facilitating products Facilitating services and products

Figure 3-11: a) Function structure of a power screwdriver proposed by Stone and Wood (2000); b) Service blueprint of a shoe buffing service proposed by Shostack (1982) Categorisation of exemplary function models As discussed before, all reviewed function models were categorised according to which perspectives they address and the used morphologies. The categorisation is based on example models and explanations provided by the authors. Table 3-3 exemplarily shows the categorisation of the function models that have been presented in this chapter thus far. The detailed categorisation of all reviewed models can be found in Appendix A. Table 3-3: Exemplary categorisation of function models presented in preceding sections

(x)

function modelling perspective may be included implicitly addressed in function model changed states included after each operation

Function structure Function tree Hybrid funct./solution model Process structure Service blueprint Service process model Transformation process str. Use case schematic Use case activity diagram

Möhringer and Gausemeier Blessing&Upton Shostack Watanabe et al. Hubka and Eder Kruchten

x x

x x (x) (x) x x

x

(x)

x x

x

x* x

Figure 3-1a and b

x

x x

o

o

E,M,S

x x

x* x x x

Hierarchical structure

x x x (x) (x)

Morphologies

Stakeholder allocation

Figure 3-5 Figure 3-8 Figure 3-6 Figure 3-11a Figure 3-1c Figure 3-9 Figure 3-3 Figure 3-11b Figure 3-7 Figure 3-4

Technical system allocation

Vandermerve Buur Pahl et al. Stone & Wood

Use case

CAC Function-Means-Tree

Interaction processes

Figure

Transformation processes

Authors

Effects

Function models

States

o x*

Function modelling perspectives

Flow of operands (input/output relation)

does not apply; not included driving aspect function modelling perspective is explicitly addressed

Flow in time

empty black cell grey cell

x x x x x

o x

x x x x (x)

x x x x x

x x x x x x

E,M,S

E,M,S: Energy (E), Material (M), Signals (S)

49

3.1.4

Comparison of identified function modelling perspectives and 5-key-terms

As discussed in Section 2.4.2, Vermaas (2009, 2013a) proposes the concept of 5-key-terms to describe the different conceptual layers that function reasoning approaches typically pass through in the solution finding process during conceptual design. These five key terms are directly related to the archetypical notions of function (as already discussed in Section 2.3.2). The proposed reasoning approaches and the notion of function that these are based on, in turn, were found to influence which specific contents are addressed in the associated function models (see Section 2.4.4). Various parallels can be drawn between these key terms and the function modelling perspectives presented in the previous section (see Table 3-4). A difference is introduced by the fact that Vermaas focuses on tangible and/or intangible artefacts (i.e. “devices”), whereas the identified function modelling perspectives can be associated to technical products and services, which may be combined in a PSS. This difference in scope surfaces when considering the function modelling perspectives of human processes and interaction process. In the following, the key terms are compared with the different function modelling perspectives: 







The goals of the device by Vermaas (V) are associated with the desired states as the output of a function in a system or refer to the state change from input to output. This directly corresponds to the function modelling perspective (FMP) of states. The actions with the device (V) correspond to interaction processes (FMP); actions with the device (V) further correspond to the specific human process (FMP, i.e. transformation processes that are carried out by stakeholders) that refer to a manipulation of system elements (i.e. technical sub-systems) through a person that is considered part of the system under consideration (e.g. if the considered system is a PSS including service personnel interacting with technical products). The key-terms functions of the device and behaviour of the device (V) can both be regarded as associated to the required transformation processes (FMP) carried out by technical (sub-) systems (i.e. technical processes) and the physiochemical effects perspective (FMP). The structure of the device (V) corresponds to the stakeholders and technical systems (FMP) that are allocated to act as function carriers. Chains of process (which may be human and/or technical processes) (FMP), can be regarded an abstract representation of the structure of services (as discussed in Section 2.1). The combination of technical sub-systems (such as e.g. components, modules, parts, etc.) build the structure of involved technical products.

Houkes and Vermaas (2010) further discuss the concept of use plans (see Section 2.4.2). Use plans describe the intention or purpose that a user has in applying a system, and thus define the goals of the device (V) and the actions with the device (V) of a prospective user. The functions of the device and behaviour of the device are determined in a way that they can enable different use plans. In comparison, different use cases (FMP) similarly describe different scenarios for applying a system to meet a goal, which can involve different interaction processes and transformation processes (FMP). Therefore, use plans (V) and use cases (FMP) can be regarded as corresponding to one another. The comparison is summarised in Table 3-4. It supports the conclusions from earlier discussions in Section 2.4.3: the key terms by Vermaas are reflected in the contents addressed in function models proposed within and across disciplines that aim to support the reasoning about functions and function carriers during conceptual design. Depending on what is considered part of the system (i.e. including or

50

Chapter 3: Function Modelling Approaches excluding stakeholders, such as users, and surrounding technical systems) the key-terms can be mapped to different sets of function modelling perspectives (as indicated in Table 3-4).

3.1.5

Key-terms

Function modelling perspectives

Goals of the device

Desired output states or state change from input to output

Actions with the device Functions of the device Behaviour of the device Structure of the service

Interaction processes, (human processes) Transformation processes (human processes and/or technical processes), effects

Use case

Use plan

Table 3-4: Function modelling perspectives associated to the five key-terms

Stakeholder and technical system allocation

Discussion

A large variety of function models are proposed in disciplinary and cross-disciplinary design literature. The performed review led to the identification of several distinct function modelling perspectives as well as distinct modelling morphologies. The reviewed function models address different combinations of these modelling perspectives and use different modelling morphologies. None of the reviewed function models was found to represent all identified function modelling perspectives. Because of the found differences, different function models may be incompatible and designers using different models may, hence, not be able to share their ideas and design considerations. This may considerably hamper the exchange of information and shared function modelling during conceptual design. As discussed in Section 2.6, it is assumed in this thesis that through combining or relating between different contents addressed in function modelling from different disciplines, shared modelling and reasoning about functions can be supported irrespective of the specific notion of function used. The correspondence between the identified function modelling perspectives and the different key terms proposed by Vermaas supports this assumption. The identified function modelling perspectives enable a comparative analysis of the specific reasoning approaches followed in different systematic design approaches, by focusing on which specific function model(s) and associated modelling steps are sequentially proposed, in order to guide designers during conceptual design. An additional, comprehensive review of the proposed modelling steps and associated function models may provide valuable insights into which specific modelling perspectives are particularly prominent within the disciplines and how they may be (or need to be) adequately coupled or linked in an integrated function modelling approach. The following section presents the results of a comprehensive analysis of function modelling approaches from different disciplines15.

15

Parts of the reviews presented in this section have been published in earlier versions in Eisenbart et al. (2012b, 2013b, and 2013c).

51

3.2 Analysing function modelling approaches The sequence of proposed modelling steps and associated function models in systematic design approaches are intended to guide designers in their reasoning towards a potential solution concept (as already discussed in Section 2.4). Such a sequence of modelling steps and associated function models means moving between the function modelling perspectives addressed in these models. Commonalities across disciplines between what is prominently addressed in function modelling approaches from the different disciplines and the way function modelling is proposed to progress towards a solution may provide a suitable starting point for the development of an integrated function modelling approach, as discussed before. The term “function modelling approach” used henceforth encompasses the specific sequences of modelling steps and the associated function models (with the modelling perspectives these address) proposed in an approach. 3.2.1

Approach

The presented research is guided by the questions:  

Which function models and associated modelling perspectives are addressed in disciplinary and cross-disciplinary modelling approaches and which modelling perspectives are most prominent? What kind of sequence (if any) is suggested for function modelling in the different disciplines and is there a shared one between?

A multitude of function modelling approaches can be found in literature. In total, 47 function modelling approaches have been analysed, each proposing between 1 and 5 different function models in the transition towards a potential solution during conceptual design. The approaches originate from mechanical engineering (n=13), electrical engineering (n=5), software development (n=6), service development (n=6), mechatronic system development (n=7), PSS design (n=5), and systems engineering (n=5). The analysis also includes the function modelling approaches proposed by Hubka and Eder (1988) and Pahl et al. (2007), as well as a selection of approaches using use case based modelling, already initially discussed in Section 2.4.2. For each discipline, a selection of approaches is exemplarily discussed in detail in the following. Subsequently, the findings are summarised and compared in Section 3.2.9, in order to provide answers to the posed questions. 3.2.2

Mechanical engineering

Function modelling proposed by Pahl et al. (2007) and related approaches have been adopted in a variety of systematic design approaches from mechanical engineering and interdisciplinary system development (as already discussed in Section 2.4.2). The modelling approach of Pahl et al. (2007) is essentially characterised by derivation of the overall system function from the requirements specification. Subsequently, the respective sub- and auxiliary functions are established through decomposition. Decomposition is exhibited until basic working principles can be allocated based on the required physiochemical effects. The central modelling steps are listed in Table 3-5. In terms of addressed function modelling perspectives, individual (sub-)functions are modelled related to (a set of) basic effects, which are necessary to transform an initial state of operands into a desired state. Frequently, individual effects are encompassed as transformation processes.

52

Chapter 3: Function Modelling Approaches Ulrich and Eppinger (2008) also adopt the Pahl and Beitz approach, but add the modelling of so-called “user action sequences”. These represent the flow of human processes in time, which fulfil required functionality in combination with the system under development. Table 3-5: Central function modelling steps after Pahl et al. (2007) Step

Description

Related models

1

Establishing the main overall function using a black box indicating the central inputs and outputs of operands

2

Determining and formulating the overall function within the black box

3

Decomposing the overall function to establish sub- and auxiliary functions, as well as their structure

Function structure

4

Selection and combination of suitable working principles for each sub-function

Morphological chart

Function structure (initial black box model)

Considerably different approaches are proposed e.g. by Tjalve (1978) and Hubka and Eder (1988, Eder 2008, Eder and Hosnedl 2008). Tjalve’s function modelling approach has further been partly taken up by Andreasen and Hein (2000). Tjalve addresses a similar set of function modelling perspectives as Hubka and Eder; however, the proposed sequence of modelling perspectives differs slightly. Both Tjalve and Hubka and Eder clearly separate between external and internal transformation processes related to desired overall state changes of operands. As discussed in Section 2.4.2, Hubka and Eder define an external transformation system (see Figure 3-4), which contains any “operator” involved in realising the transformation processes that are required to create the overall state change of operands. Operators include technical sub-systems, human operators (i.e. stakeholders), and related information or management systems, but also the active and reactive environment (see Section 3.1.2 and Figure 3-4). The mutual interactions and contributions of all operators constitute the required transformation processes in the transformation system. These transformation processes are external to the different operators and are realised through the functions that the operators possess. Functions are defined by Hubka and Eder as the internal tasks of the system under development; they are represented as technical processes and effects internal to the system under development (as already discussed in Section 2.4.2). Function carriers within the system may have interaction processes with each other and with other operators (these latter transformation processes are referred to as “cross-boundary functions” by Hubka and Eder). Function carriers are the organs and their parts (see Figure 2-7). In Table 3-6, the individual steps and related models proposed by Hubka and Eder are illustrated. In an initial step, the different “duty cycles”16 are consolidated. Each duty cycle is related to a different transformation system, including related operators, internal and external transformation processes, and effects. The concept of duty cycles is thus to a large extent compliant with use cases (as defined in Section 3.1.2). Subsequently, transformation processes (both internal and external) and effects are modelled related to a flow of operands. Transformation processes and effects that only indirectly contribute to a state change (i.e. without directly affecting a specific operand) are regarded as supporting or auxiliary functions by Hubka and Eder.

16

“Duty cycles” refer to different operations applied to or with a technical system, for instance, during cleaning, maintenance, transportation, usage, etc.; for each of which different transformation processes and operators may be relevant. Hubka and Eder emphasise that in order to determine the transformation system the different, relevant duty cycles have to be established first.

53

Table 3-6: Central function modelling steps after Hubka and Eder (adapted from Eder 2008) Step

Description

1

Establishing the different duty cycles the technical system may encounter in the different life-cycle phases

2

Establishing the desirable or required output (operand in final state) of the transformation system

3

Establishing suitable transformation processes, determined from the established desirable output

4

Establishing of an appropriate input (initial state of operand), if needed or considered helpful

5 6 7 8

Related models

Allocating which operator, alone or in cooperation with others, will perform which transformation processes; and which technical system(s) need to be designed Choice of technology (i.e. a general technical principle) to enable the transformation process(es), e.g. hydraulic cylinder, mechanical fixture etc. Establishing what the technical system under development needs to be able to do (its internal functions and functions performed “cross-boundary”, in cooperation with other operators) Establishing the function carriers (organs and their parts structure), which can perform these functions

No separate model

Transformation process structure (see Figure 3-4)

Function structure Organ structure, parts structure

The approach proposed by Tjalve (1978) comprises modelling the main transformation process that need to take place in order to fulfil the desired goal of the system under consideration. Subsequently, it is decided which operators will be carrying out the individual transformation processes (operators may be either humans or technical products). For the transformation processes that are to be carried out by the technical product, the required physiochemical effects are determined; these are considered as the product functions by Tjalve. Finally the transformation processes carried out by humans (which are referred to as “manual operations”) and the physiochemical effects that have to be provided by the product are modelled into one model in relation to their flow in time (in the socalled “Process/function chart”). 3.2.3

Electrical engineering

While all reviewed systematic design approaches from electrical engineering propose a stepwise overall design process, none was found to propose a specific sequence of models or modelling steps in relation to function modelling. Different function models are proposed which can be used in parallel or alternatively (see Walker and Thomas 1985, Bleck et al. 1996, Dewey 2000, and Scheffer et al. 2006). The designers are free to choose the specific function models and the order in which they are applied, with respect to what best fits their needs in a specific situation. Therefore, no electrical engineeringspecific sequence of addressed function modelling perspectives could be derived. Dewey (2000) describes function modelling as part of the initial design stage of system development, the so-called “design entry”. Design entry is typically based on a requirements and constraints specification and results in an (initial) electrical or physical layout of the system. The development process is described to move from abstract to concrete. The most abstract level is a specification of the system to be developed, whereas the most concrete level is a physical layout. In this progression, function modelling is considered one distinct level of abstraction for looking at the system. It is preceded by the architectural level and succeeded by the logical level (this is similarly proposed by Walker and Thomas 1985). The architectural level represents an initial set of basic interlinked components, e.g. in a netlist (Dorf 2000). The logical level describes the system by abstracting its components into interlinked logical block elements, which can subsequently be transferred into an electrical layout. Function modelling in particular addresses states and their transitions to facilitate the synthesis from the architectural level to a logical layout (i.e. the logical building elements are an abstract specification of the function carriers). For function modelling, a variety of models are 54

Chapter 3: Function Modelling Approaches proposed as alternatives (see Table 3-7). Based on these models, the design is optimised before moving to the logical level. The central steps in this transition are listed in Table 3-7. Table 3-7: Central steps related to function modelling after Dewey (2000) Step

Description

Alternative models

1

Determining and establishing system states and their transitions

2

Eliminating redundant or equivalent states

3

Modelling states and transitions in binary logic to minimize combinational logic

Finite state machine, Function table, Function block diagram, Petri nets, VHDL description.

Function modelling proposed in electrical engineering most prominently addresses system states and their transformations, in order to derive the necessary (logical) building elements. This is usually modelled in e.g. function block diagrams (van Alven 1964), finite state machines (see Figure 3-12), petri nets (see e.g. Baumgarten 1996) or specified in VHDL17. In one case, sequence diagrams (see Section 3.2.4) from use case modelling are proposed (see Scheffer et al. 2006). transition

State 1

transition

recursion transition State 4

State 2

transition State 3

Figure 3-12: Schema of a simple finite state machine (after Belzer et al. 1975) 3.2.4

Software development

In software development, increasingly often so-called agile and object-oriented systematic design approaches are proposed, which are based on use case-oriented reasoning and frequently rely on UML-based modelling18 (see also Section 2.4.2). Prominent examples are, for instance, the Rational Unified Process (RUP) after Kruchten (2004) or Scrum (see e.g. Schwaber 2007). Further examples are Extreme Programming (XP, see Beck 1999) or Crystal (see Cockburn 2003). Overviews of systematic software development approaches are provided e.g. by Bunse and von Knethen (2008) and Liu and Li (2012). Kruchten’s RUP provides one of the most detailed function modelling approaches with a clear sequence of modelling steps. All involved actors and their interaction processes with the technical 17

Very High Speed Integrated Circuit Hardware Description Language (VHDL) As discussed before, UML is considered a so-called “visual modelling language” (Friedenthal et al. 2006) representing information about comprised objects and their relations via different partial models using alternative modelling morphologies. While UML may be expanded with specific contents if required by designers, a few core models have been generally established in software development (three particularly prominent models are provided in Figure 3-13). 18

55

product under consideration are gradually identified and modelled, in order to support deriving the specific technical processes that the software system needs to enable and control in the technical product. These process chains are subsequently implemented into the software system. In an initial step in the RUP, a feature list is generated. Features refer to the specific services and functions that the system is expected to offer to a user. Based on this feature list, central use cases are differentiated. Subsequently, the external actors and their interaction processes with the system under consideration are determined for each use case. Actors include humans (i.e. users and other stakeholders) and external technical systems that interact with the system under consideration or its sub-systems (e.g. through a touchpad, control buttons or similar). Each use case is initially described in a so-called use case description. Use case descriptions provide (frequently list-based) textual descriptions of the central human processes, technical processes or interaction processes that occur in each use case. The technical processes have to be enabled by the software system, in order to fulfil the user requests and features in different use cases. The overall goal of each use case is to implement a desired overall state change for the primary user (i.e. achieve a new or changed situation to fulfil the user’s goals). Subsequently, the described technical processes are modelled in relation to their flow in time for each use case, using an activity flow diagram. Finally, process flows are detailed and represented in associated sequence diagrams, which relate each process to involved stakeholders and technical sub-systems. In Table 3-8 the essential steps and associated models proposed in the RUP are illustrated. Figure 3-13 presents examples of the central models proposed. Table 3-8: Central function modelling steps in the RUP (after Kroll and Kruchten 2003 and Kruchten 2004) Step

Description

Related models

1

Listing the general features, the system is expected to provide to the users

2

Determining/identifying central use cases from the feature lists

3

Identifying actors (stakeholders and technical systems interacting with the system under consideration)

4

Identifying the most important use cases

5

Identifying and modelling individual steps of the most important use cases

6

Modelling alternative flows in case of error scenarios

7

Adding pre-and post-conditions of use cases (initial and final system states)

8

Representing the interactions between actors in the realisation of a use case in a sequence diagram

Feature list

Use case descriptions, use case schematics

Use case activity flow diagram

Sequence diagrams

A similar approach to the RUP is proposed in the V-Model XT (see IABG 2006), in which several of the UML-based models included in the RUP are also employed. For function modelling use case schematics and activity flow diagrams are proposed. Other approaches propose simple function lists (e.g. Scrum and XP) or storyboarding (see Cooper 2007). Storyboarding is proposed for depicting and visualising the interaction processes of users with the system and the technical processes within the system that are required for realising the different user requests.

56

Chapter 3: Function Modelling Approaches System to be developed

view report card register for courses

Student

maintain professor info

Course catalogue

select courses to teach Professor

Use case activity flow diagram for use case “register for courses”

maintain student info

Student selects to register for courses Registrar

close registration

submit grades

Billing system

Use case schematic

Student

1: create schedule Student wishes to create a new schedule List of available courses is displayed

Registration Controller

2: get course offerings

System retrieves list of available courses

Student selects courses

Sequence diagram for use case “register for courses” Register for courses form

System displays a blank schedule

Course catalogue

System verifies eligibility of course selection eligible?

Show error message no

yes

3: get course offerings

Add student to course

4: display course offerings

Save schedule

5: display blank schedule

Blank schedule is displayed for student to select from

Figure 3-13: Examples of use case schematic, activity flow diagram, and sequence diagram for a course management software system (adapted from Kroll and Kruchten 2003) 3.2.5

Service development

Function modelling in service development primarily focuses on the interaction processes between customers and service providers, as well as the specific processes of service providers during service execution. The latter mainly addresses transformation processes, which may be executed by humans (i.e. human processes) often in conjunction with the use of technical products comprising respective interaction processes. This usually encompasses the allocation of technical systems and stakeholders that contribute to the realisation of the required functionality (see e.g. Scheuing and Johnson 1989). Fisher and Schutta (2003), Fähnrich and Meiren (2007), and Bullinger et al. (2003) rely on simply listing the central functions (i.e. the central processes) of the service to be developed. Fisher and Schutta (2003), in addition, propose block diagrams complementary to these lists, which represent the flow in time of service processes (these may be technical processes or human processes). A specific sequence for modelling, however, is not specified by the authors. A particularly detailed function modelling approach is proposed by Spath and Demuss (2005). The authors base their overall service development approach on the VDI guideline 2221 (VDI 1993). Function structures based on Pahl et al. (2007, see Figure 1-1) are proposed including step-wise decomposition of the required functions of a service system. Subsequently, this function structure is complemented by either service blueprinting (see Figure 3-11b), IDEF-0 (Figure 3-14) or FAST modelling. This second step is intended to support function decomposition and, at the same time, 57

gradually establish the flow of required service processes (mainly covering human processes), which are expected to be performed by the service providers and/or customers allocated in the models (i.e. stakeholder allocation). In Table 3-9, the approach by Spath and Demuss is illustrated. Table 3-9: Central function modelling steps proposed by Spath and Demuss (2005) Step

Description

Related models

1

Decomposing the central service functions (service processes and operand flows)

2

Establishing service operators and their activities

Function structure (similar to Pahl et al. 2007) (alternatively) Service blueprinting, IDEF-0 modelling or FAST modelling

Service blueprinting is widely proposed in service development. In contrast to Spath and Demuss, however, it is typically not exclusively used during conceptual design, but is gradually transferred into a model illustrating the concrete service solution, by successively adding information about the respective human and/or technical resources required in each individual service process (see e.g. Shostack and Kingman-Brundage 1991, Edvardsson and Olsson 1996, Alam 2002, Alam and Perry 2002, Bullinger et al. 2003, and Fähnrich and Meiren 2007).

Legend:

Detect or suspect malfunction, or item is scheduled for benchcheck

In-service asset

Remove and replace

Control

Replaced asset

Input

1

Function/ Technical process

Output

Repairable asset

Spare asset

Mechanism Schedule into shop

Status records 2

Supply parts Replacement or original (repaired)

Asset (before repair)

Inspect or repair 3

Asset awaiting parts

Asset (after repair)

Monitor and route

Completed asset 4 Spare

Figure 3-14: Example of IDEF-0 model of a maintenance service (after US DoD 2001) 3.2.6

Mechatronic system development

In mechatronic system development, the VDI guidelines 2221 (1993)19 and 2206 (VDI 2004) propose function modelling approaches which have been adopted from Pahl et al. (2007). Alternative approaches are proposed, for instance, by Salminen and Verho (1989), Buur (1990), Gausemeier et al. (2009), and Eigner et al. (2010).

19

VDI guideline 2221 is not exclusively proposed to support mechatronic system development. It originates from a mostly mechanical engineering background; however, it also addresses the development of systems combining mechanical engineering, electrical engineering, and precision technique.

58

Chapter 3: Function Modelling Approaches Buur’s approach consists of four partial function models (see Figure 3-15) and builds on Hubka and Eders’s function modelling approach (see Section 3.2.2). In Buur’s approach “transformation functions” address effects and transformation processes related to operands (see “transformation functions” in Figure 3-15), whereas “purpose functions”, in contrast, are represented as a flow in time of transformation processes (in the “purpose functional structure” in Figure 3-15). The different states in the “states and transitions” partial model are closely related to different duty cycles proposed by Hubka and Eder (as described in Section 3.2.2). Similar to duty cycles or use cases (as used by Kruchten 2004), depending on the specific state (0, 1, 2 or 3) that a system is in, a different set of “purpose functions” are active. This is illustrated on the bottom right in Figure 3-15. Therefore, Buur’s states correspond to the use case perspective. In the provided example of the telephone, the same purpose functions may be involved in alternative use cases.

Purpose functional structure

States & Transitions 2 Idle

Calling

0 3

Speaking 1 Sending number

inf. about ph.number

2

sound (ringing)

E-signal is generated Acoustical signal is generated

sound (speech)

E-signal is generated

sound (speech)

Acoustical signal is generated

3

generate electrical signal

generate calling sound

detect calling signal

accept sound(speech)

generate electrical signal

generate sound (speech)

Transformation functions 1

accept number inf.

transmit signals receive signals

change state

Active purpose functions

Signal is transmitted Calling signal is detected

00

22

11

3

Signal is transmitted Signal is received

Figure 3-15: Different function models proposed by Buur (1990) for the example of a telephone The proposed modelling approach emphasises iterations between the four partial models during function modelling. The four partial models are developed in co-evolution, which is to say, the different modelling perspectives use cases, effects, and transformation processes are addressed and modelled together. Finally, the required effects and transformation processes are allocated to different function carriers (mainly technical sub-systems forming the specific solution) using a Function-Means-Tree (see Figure 3-8). Table 3-10 illustrates the central proposed modelling steps. Salminen and Verho (1989) propose a sequential function modelling approach. Modelling initially focuses on the required transformation processes, before focusing on the allocation of technical systems and stakeholders foreseen for their implementation. Finally the different system states and their transitions are addressed. 59

Table 3-10: Central function modelling steps proposed by Buur (1990)

Iterative modelling

Step

Final step

Description

Related models

Elaborating system states and transitions between them

States and transitions

Establishing transformation functions (related to operands) required in different system states

Transformation functions

Establishing general purpose functions needed in technical systems to enable the transformation functions.

Purpose functional structure

Indicating which purpose functions are active in different system states.

Active purpose functions

Allocating principle solutions and function carriers from the involved disciplines.

Function-Means-Tree

Gausemeier et al. (2009) propose a relatively new approach for the specification of mechatronic systems. Function modelling in this approach involves hierarchical tree structures and abstract behavioural modelling. In a first step, the central functions (i.e. transformation processes) are derived on system level from the requirements list and modelled into a function tree, in order to decompose the main functions into sub- and auxiliary functions. Decomposition can be performed up to the level of basic effects, in order to allow allocation of solution principles (similar to Pahl et al. 2007). Subsequently, the central transformation processes are modelled in a “behaviour-activities” model related to a flow of operands (focusing on energy and information). Based on this initial behavioural model, further models that focus on the solution (shape, structure, etc. of the system) can be derived during embodiment design. 3.2.7

PSS design

Within several PSS design approaches, service blueprinting, IDEF-0 or FAST modelling are proposed to support the reasoning towards a solution in the conceptual design stage. Similar to approaches from service development (see Section 3.2.5), these models are gradually transferred into a representation of the solution concept (see e.g. Brezet et al. 2001, Maussang-Detaille 2008, and Watanabe et al. 2011). In this transition, the models are iteratively refined and required resources for service fulfilment, such as humans (i.e. stakeholders) and products (i.e. technical systems) are allocated. Maussang-Detaille proposes parallel generation of multiple function models for different parts of a PSS. For instance, activities of users and service providers (i.e. human and interaction processes) are separately modelled in an IDEF-0 model, whereas the main functions of the involved technical products (i.e. technical processes) supporting the provided service are modelled in a FAST model. In addition, functional block diagrams (FBD) are proposed for modelling the internal product-related functions (i.e. technical processes). The designer is expected to move back and forth between the models, in order to detail them gradually. Finally, the different models are integrated into one IDEF-0 model and one FBD model, which together address the functionality of the entire PSS. Similar to Maussang-Detaille, Aurich et al. (2006, 2007) propose separate function models and modelling steps for the product-related and the service-related parts, focusing on the required effects and technical processes as well as human processes, respectively. Both parts are iteratively modelled in parallel. This kind of iterative, reoccurring refinement of different function models resembles a spiral design approach (see e.g. Boehm 1988 in software development). The spiral character is in fact explicitly emphasised by Brezet et al. (2001), and – to a lesser degree – by Watanabe et al. (2011).

60

Chapter 3: Function Modelling Approaches Only Sakao and Shimomura (2007) were found to propose a somewhat sequential function modelling approach; however, iterations in modelling are also foreseen by these authors. The essential modelling steps proposed by Sakao and Shimomura (2007) and the related models are presented in Table 3-11. The “flow model” addresses the network of different stakeholders and their respective interactions within a service. The flow model further serves as a link between all proposed partial models (see Figure 3-16). Partial models represent associated interaction processes, transformation processes, and state changes in more detail. The proposed modelling approach moves from modelling the associated human processes (flow model and “chain of actions”) to modelling the required state changes of the customer (“scenario model”) and related transformation processes (“view model”). Scenario models represent how the states of customers (referred to as “Receiver state parameter”, RSP) are transferred when they receive the offered service. Finally, the involved technical systems (e.g. “realisation structure”) are allocated, which are foreseen for implementing and supporting the respective processes. The application described by the authors suggests that each partial model is iteratively refined. This frequently seems to require updating the associated models with respect to changes made within any of the partial models. Although Sakao and Shimomura do not explicitly refer to the proposed models as function models, they are applied for the same purpose as IDEF-0 or service blueprinting within other PSS design approaches. Table 3-11: Central function modelling steps proposed by Sakao and Shimomura (2007) Step

Description

Related models

1

Making a preliminary flow model

Flow model

2

Setting the goal of a scenario

Scenario model

3

Describing a chain of actions for service receivers

Chain of actions

4

Identifying the goal parameter

Scenario model

5

Generating a realisation structure

View model with realisation structure

Coffee Machine Maker Customer

Coffee Runner

Provider

Furniture Maker Receiver

Flow model View model

Intermediate Agent Scope model

RSP (Receiver State Parameters)

Figure 3-16: Overview of proposed models (adapted from Sakao and Shimomura 2007)

61

3.2.8

Systems engineering

Systems engineering is often considered to be a particular mind-set approach or high-level engineering design approach (ECSS‐E‐ST‐10C 2009). It focuses on the systematic development of any kind of system and its sub-systems. This includes combining multiple technologies and associated design disciplines in an often iterative process (see Moser 2014). Particularly prominent systematic design approaches from systems engineering can be found, for instance, in Hall (1962), Sage and Rouse (1980), US DoD (2001), Hitchins (2007), NASA (2007), ECSS‐E‐ST‐10C (2009), and INCOSE (2010). The specific function modelling approaches proposed by these different authors proceed in a similar manner. In an initial step, the central functions are derived from the requirements specification and put into a logical order. Establishing the logical order between the derived functions may be based on the specific data or energy flows (i.e. operands) or on their sequence in time. A variety of function models are proposed, which may be alternatively used. Most notably, this includes Functional Flow Block Diagrams (FFBD, see Figure 3-17), IDEF-0 models or N2-matrices. No specific sequence is proposed for applying these models. Irrespective of the specific authors, functions are typically modelled as transformation processes. NASA (2007), in addition, proposes state diagrams, focusing on the specific system states and their transitions. Function modelling typically results in a system specification or structural models, such as e.g. system block diagrams (US DoD 2001). INCOSE (2010) further suggests the use of SysML as an option for modelling and specifying these structural aspects of the system under development. Functional description

Function number Summing gate 9.2.1

…

and

See detail diagram

9.2.2

Go flow

Parallel function

or

…

or

…

_ G

9.2.3 or

G

and

or

Alternative function 9.2.4

Sys. Leader note

No go flow

Malf. See detail diagram

Figure 3-17: Schema of a Functional Flow Block Diagram (adapted from US DoD 2001) SysML provides a large variety of models, which allow for detailed modelling and analysis of a system’s structure, its behaviour, as well as its context. Context refers to, e.g., possible external stakeholders and peripheral technical systems interacting with the system under development. Because of the variety of offered models, SysML is often applied in interdisciplinary design projects, which are based on systems engineering approaches, in particular aerospace system or medical device development (see Bone and Cloutier 2010 and Pires et al. 2012).

62

Chapter 3: Function Modelling Approaches A particularly interesting modelling and design approach using SysML is proposed by Weilkiens (2008). Weilkiens proposes a detailed sequence of modelling steps for conceptual design20. In an initial step, the central use cases are derived and represented in a use case schematic, which further address the external stakeholders, peripheral technical systems as well as their interaction processes with the system under development in relation to the derived use cases. Use cases can further be modelled in a separate flow diagram, which illustrate the sequence in which the individual use cases may be executed in the application of the system under development. For each use case, the specific sequence of required transformation processes and the interaction processes of the stakeholders and peripheral technical systems with the system under development is modelled in a separate activity flow diagram (similar to function modelling in the RUP, described in Section 3.2.4). In parallel, the sequence of transformation and interaction processes can be modelled in detail in associated sequence diagrams, which relate each transformation process to the involved stakeholders and technical sub-systems (see also Figure 3-13). Finally, modelling the process flows for each use case may be further substantiated with state diagrams (similar to finite state machines) representing the specific states of the involved actors and their transitions. The different models are to be iteratively refined in parallel. The central modelling steps proposed by Weilkiens are illustrated in Table 3-12. Function modelling may be complemented with block diagrams showing the initial system structure. Table 3-12: Central function modelling steps proposed by Weilkiens (2008) Step

Description

1

Modelling the context of the system to be developed; identifying external stakeholders and peripheral technical systems contributing to the system or otherwise interacting with it

2

Identifying and prioritising use cases and respectively involved users

3

Modelling activity flows related to the different use cases

4

Modelling specific interaction processes between sub-systems and users per use case

Sequence diagram, internal system block diagram

5

Deriving and modelling system and user states and their transitions for the use cases

State diagram

3.2.9

Related models System block diagram, Use case schematic Use case schematic, use case activity flow model

Comparing function modelling approaches

Table 3-13 summarises the specific function models, their succession and the specific function modelling perspectives they address for the main examples of the reviewed function modelling approaches discussed in the presented review. The succession of the function models in the respective rows corresponds to their proposed sequence (if any) in the individual reviewed function modelling approaches. The column “proposed models” additionally includes the specific models that the individual function modelling approaches are based on and the models that are proposed succeeding the proposed function models, respectively. These models have been included, in order to indicate the specific proposed input and output of the conceptual design stage in the reviewed function modelling approaches. For instance, function modelling proposed by Pahl et al. (2007) is based on a requirements list and results in a working structure. Alternative working principles may be represented in a morphological matrix, as discussed in Section 2.4.2. 20

Weilkiens discusses a variety of extensions to the models proposed in SysML for specific applications in system development, mainly focusing on the structural aspects of a system under development. The modelling approach presented here focuses on core SysML models/diagrams and associated modelling steps.

63

Table 3-13: Summary of exemplary function modelling approaches

Mechanical engineering

Pahl et al. (2008)

Function structure Morphological matrix

based on

Requirements list Transformation process structure Function structure

succeeding

Organ and/or parts structure, morphological matrix

based on

Requirements list Process flow models

Tjalve (1978)

Electrical engineering Service development Software development

x (x)

x

x x

x o

x

x

x

x x

o (x) x

succeeding

Function-Means-Tree

based on

Specification, netlists, schematics

x x in parallel/ alternatively

Petri nets VHDL description succeeding

Logic tables, circuit diagram

based on

Problem statement

x x x

(x) x

x

Use case schematics

(x) (x)

Use case description Sequence diagram

x x x

Use case activity flow diagram succeeding

Initial system structure/architecture

based on

Requirements list, initial system structure

FAST IDEF-0

alternatively

x x x*

x

Service blueprint succeeding

Module structure

based on

Requirements list, application scenario

(x)

Function tree structure

Gausemeier et al. (2009)

(initial) Behaviour diagram succeeding

Shape model, active structure, etc.

based on

Requirements list

in parallel

(Active) purpose fcts. model

iteratively

x x

Transformation fcts. model solution

Function-Means-Tree

based on

Requirements list

Events list

x x

Context and flow diagram State transition diagram succeeding

x x (x) x x

o x x

x (x) x (x)

x x x x

o x x x

x x x

x x

(x) x

x x

x x x

x (x) x

x

comment: Presented succession is not strictly proposed

Function tree Salminen and Verho (1989)

x x

(x) o

x

State transition model Buur (1990)

x x x

x

comment: IDEF-0 and FAST used alternatively, resulting in blueprint

Function structure Spath and Demuss (2005)

x

o

x

Feature list Kroll and Kruchten (2003), Kruchten (2004)

x x

(x) x

Function table Function block diagram

o

comment: Different function models can be used alternatively

State diagrams Dewey (2000)

Stakeholder allocation

(x)

Man-machine separation list Process/function chart

Mechatronic system development

x

Requirements list, overall problem formulation

succeeding

Hubka and Eder (1988)

x

Technical system allocation

Proposed models based on

Use case

Authors

Interaction processes

function modelling perspective may be included implicitly addressed in function model changed states included after each operation

Transformation processes

(x) o x*

Effects

does not apply; not included driving aspect function modelling perspective is explicitly addressed

States

Function modelling perspectives empty black cell grey cell

Principle solution table (see Koller and Kastrup 1998)

64

x x x x

x x x

x x (x)

x x

Chapter 3: Function Modelling Approaches Table 3-13 (continued)

FAST (general) IDEF-0 (use activity)

alternatively

x*

FAST (function and solution allocation)

PSS design

Functional block diagram (FBD) (internal modelling of system with principal elements)

based on

Stakeholder allocation

Function list (decomposition)

succeeding

x

x

(x)

Customer needs Inter-actor network

MaussangDetaille (2008)

Technical system allocation

Use case

Interaction processes

Transformation processes

Proposed models based on

Effects

Authors

States

Function modelling perspectives

x*

IDEF-0 - activities within the system FBD (detailed system modelling)

x x x x

(x) x (x)

x (x) x

x

x

x

x

x x

x x

x x

(x) x x x

x x

x

o x

x

Initial scenario model Flow model

Sakao and Shimomura (2007)

x x

Scope model Scenario model (transition graphs) Chain of actions

x

succeeding View model (function tree and realisation structure) based on

Requirements diagram, requirements list

x

Systems engineering

Use case schematic (external) Activity flow diagram (flow of use cases)

Weilkiens (2008)

x o

Use case activity flow diagram

x

x

x

(x) x

x x

(x)

(x)

x in parallel

(x) x

Sequence diagram State diagram

x x

x x (x)

succeeding System block diagram (internal/external) based on US Department of Defence (2001)

Requirements specification (alternatives available) Function Flow Block Diagram (FFBD) IDEF-0 N2-matrix

as alternatives

x*

Time Analysis Sheet

x x x x

(x) x (x)

succeeding System specification

Diversity of proposed function modelling approaches Table 3-14 shows the results of the analysis of all 47 reviewed function modelling approaches. The findings suggest that function modelling approaches proposed in literature differ greatly, both within the disciplines and particularly across. That includes, which function modelling perspectives are considered and how designers are supposed to move between individual function models, i.e. move between addressed function modelling perspectives. The classification of modelling approaches in terms of sequential, spiral, etc. is based on the overall tendency conveyed by the comparison of the different function modelling approaches within the respective disciplines. The reviewed systematic design approaches from mechanical engineering, software, and service development typically propose a sequential modelling approach. In PSS design, mechatronic system development, and systems engineering, mostly, iterative modelling approaches were found or a selection of models is proposed, which may be alternatively used. In PSS design, in addition, spiral approaches can be found. In a few approaches from mechatronic system development (e.g. Gausemeier et al. 2009 and VDI guideline 2206) conceptual design is split into system-level design and 65

discipline-specific design. In contrast, in PSS design, technical product development and development of service processes are proposed to be performed (separately) in parallel (see e.g. Aurich et al. 2007); a differentiation into system-level and disciplinary design was not found. The comparison, hence, strongly suggests that there is no shared sequence for moving between individual function modelling perspectives across disciplines. In addition, different modelling approaches frequently use alternative entry points. For instance, some approaches start by considering the specific stakeholders and their expected interactions (i.e. interaction processes) with the system under development (see e.g. Maussang-Detaille 2008 or Weilkiens 2008). In contrast, others start by determining the specific transformation processes expected from the system under consideration and proceed to modelling the specific effects required for their implementation, as e.g. proposed by Hubka and Eder (1988). Even within the disciplines a great diversity can be found in this regard, as can be seen in Table 3-13. Prominent function modelling perspectives The scope of the function models that are proposed in the reviewed function modelling approaches differs greatly with regard to the function modelling perspectives they address. None of the reviewed function modelling approaches addresses all identified function modelling perspectives. In the disciplines, different sets of function modelling perspectives and morphologies are particularly prominent, as illustrated in Table 3-14. Table 3-14: Comparison of function modelling approaches from the different disciplines Function modelling perspective

Effects

Transformation processes

Interaction processes

Use case

Technical system allocation

Stakeholder allocation

Hierarchical structure

Flow in time

Flow of operands

Morphologies

States

number entries: amount of function modelling approaches that were found to explicitly address the respective aspect

Mechanical engineering

13

sequentially

10

10

12

9

1

3

3

3

8

9

Electrical engineering

5

as alternative, (in parallel)

5

2

5

0

2

1

1

3

5

2

Software development

6

sequentially

4

0

5

5

3

4

4

3

5

0

Service development

6

sequentially

1

1

6

5

0

6

6

1

6

1

Mechatronic system development

7

iteratively, (sequentially)

6

6

7

1

2

3

6

5

3

6

PSS design

5

iteratively,(spiral)

4

1

5

4

0

4

4

2

5

1

Systems engineering

5

as alternative, iteratively

4

0

5

4

1

3

3

1

4

2

grey cell: prominently addressed aspect(s) in the discipline black cell: most prominently addressed aspect(s) in the discipline

Discipline

Σ reviewed approaches

Typical modelling approach

The different shading of the cells in Table 3-14 indicates the specific function modelling perspectives and morphologies that are particularly prominently addressed in the disciplines. While function models from mechanical engineering and mechatronic system development frequently address transformation processes and effects related to a flow of operands, software development, PSS design, and systems engineering particularly focus on modelling the flow of processes in time, including the interaction processes of users or peripheral technical systems with the system under consideration. PSS design approaches share a variety of function models with service design approaches (such as 66

Chapter 3: Function Modelling Approaches service blueprinting or IDEF-0). In various approaches, these have been complemented with function structures after Pahl et al. (2007), as described in Section 3.2.7. Table 3-14 suggests that the transformation processes perspective is always one of the most prominent – or even the single most prominent – modelling perspective within all reviewed disciplines as well as in interdisciplinary design approaches. Thus, it is most prominent across all the reviewed disciplines. While mechatronic system development, mechanical engineering, and electrical engineering focus on technical processes, service development focuses on human processes. As can be expected, in PSS design and software development both human and technical processes are particularly prominent. Nevertheless, also in mechanical engineering and mechatronic system development some authors stress the inclusion of humans as operators into the system; thus, they include human processes in function modelling (see e.g. Tjalve 1978 or Hubka and Eder 1988 and related approaches). Prominent modelling morphologies While one function modelling perspective was found to be the single most prominent perspective across all reviewed disciplines, this does not similarly apply to one single modelling morphology. Flows in time are most prominent in the majority of disciplines (see Table 3-14); however, the other two morphologies are also particularly prominently addressed in one or more disciplines. In addition, in various function modelling approaches, multiple function models are proposed in parallel, which use alternative morphologies. For instance, in the approach proposed by Spath and Demuss (2005), function structures after Pahl et al. (2007) are complemented with models addressing service processes related to a time flow, as discussed in Section 3.2.5. This suggests that the information conveyed in all three morphologies (hierarchical structure, flow of operands, and flow in time), about how individual functions are interlinked, is important in interdisciplinary system development.

3.3 Discussion In the presented analysis different function modelling approaches proposed across disciplines were reviewed with regard to the proposed sequence of modelling steps, as well as the function modelling perspectives and modelling morphologies addressed in the associated function models. None of the reviewed function models and function modelling approaches was found to address all identified function modelling perspectives. This is not to be seen as criticism; rather, the different disciplines seem to focus on different – but overlapping – sets of modelling perspectives, as the comparison shown in Table 3-14 suggests. This implicates that function modelling in the different disciplines effectively differs in terms of focus and scope, i.e. regarding which specific information is considered in the respective function modelling approaches and, therefore, addressed in the associated function models. Thus, during interdisciplinary conceptual design, these (sets of) modelling perspectives and morphologies need to be integrated, in order to address the specific focus of the disciplines that are involved in a design process. This is expected to facilitate the exchange of function considerations between the designers during conceptual design. 3.3.1

Potential barriers for shared function modelling

The found diversity in function modelling approaches from the different disciplines supports the general picture of diversity associated to function as a concept, including the way system functions are 67

reasoned about and modelled (as already discussed in Section 2.6). The presented literature study further suggests that depending on the respective author, the same model may in fact serve different purposes during the development process. For instance, in service development and PSS design, depending on the respective authors, service blueprints and IDEF-0 models are proposed for either function modelling during conceptual design and/or also for the representation of the particular service solution (see Sections 3.2.5 and 3.2.7). Each proposed modelling approach is eligible to the specific application discussed by the respective authors and aims to support designers in their reasoning process towards a solution. However, in case different designers follow alternative modelling approaches (i.e. follow a different chain of reasoning about functions) in the same project, this may lead to problems in the exchange of models and represented information. As can be expected, this seems to apply exceedingly to interdisciplinary conceptual design, but may even be the case within the disciplines (as discussed in Section 3.2.9). Designers, who have been introduced to discipline-specific function modelling approaches, may also not be aware of the differences in the targeted application and which specific modelling perspectives are relevant to designers from other disciplines. Providing designers with an adequate, integrated function modelling approach is expected to support the exchange of information during conceptual design and, hence, improve the design process and the design. 3.3.2

Needs and opportunities for integrated function modelling

In order to support the integration of function modelling in interdisciplinary system development, it seems an integrated modelling approach is needed that copes with the existing diversity. This suggests that an integrated function modelling approach needs to enable switching between modelling perspectives easily and allow entering at different points. These findings correspond to the initial insights discussed in Section 2.6. Linking different function modelling perspectives in a way which allows switching between them easily, further is expected to allow adaptation of what (i.e. which function modelling perspective) is modelled in a specific situation, as focus can be put on selected aspects. The conducted literature study further suggests that the transformation process perspective is prominently addressed across all reviewed disciplines. Modelling the required transformation processes (both human and technical) may, hence, serve as a common basis in an integrated function modelling approach. Linking the remaining modelling perspectives through the shared transformation process perspective may enable interlinking and translating between the different modelling perspectives taken by designers at a specific point in the development process, i.e. at a specific point in their reasoning about functions. 3.3.3

Possibilities for combining different function modelling perspectives

The analysis of the proposed function modelling perspectives shows that some function models, like IDEF-0 models or Hubka and Eder’s transformation process structure, combine several of the identified function modelling perspectives in single models. Another possibility for the integration of perspectives can be seen in the modelling approaches proposed by Buur (1990), Salminen and Verho (1989), and in use case modelling (see Kruchten 2004 or Weilkiens 2008). In these approaches, multiple complementary function models are proposed, which – together – complementarily cover a wide

68

Chapter 3: Function Modelling Approaches selection of the function modelling perspectives, while each model remains focused on specific information only. Combining several modelling perspectives (preferably all) in one single model in an integrated function modelling approach may result in complex representations that are hard to read. This, in turn, may hamper retrieving relevant information quickly. Inadvertently, this could prevent the desired flexible application and, in addition, it may become technically difficult to combine the different morphologies in such an approach. Using multiple complementary models, on the other hand, such as in SysML/UML, allows the designers to focus on a limited number of function modelling perspectives within each model. This can reduce complexity of each partial model. However, communicating the designers’ function considerations during conceptual design – within as well as across disciplines – may be hindered when continuing using separate models, in particular, because capture of information that is distributed between different partial models can be a complex cognitive task. Causal links between represented information may be difficult to grasp (see Henderson 1999). Hence, the establishment of a shared understanding across disciplines may still not be sufficiently achieved. In addition, consistency of information represented in multiple, complementary models can be difficult to maintain and poses particular challenges to change management (as discussed e.g. by Eger 2005 and Stechert 2010). Both problems, inconsistencies between complementary models (due to subsequent modifications which were not adequately advanced to all models) and a missing shared understanding of the system to be developed, also occurred in the initial example of failed cross-disciplinary integration taken from the major developer of mechatronic products (described in Section 1.1). Integrated function modelling may have to conciliate or compromise between using a single model or a set of partial models. In order to decide on an adequate solution in this regard, the specific needs of designers in interdisciplinary design practice also need to be taken into account. UML and SysML, for instance, have been particularly critically discussed regarding their application in mechanical engineering practice (see Bone and Cloutier 2010 and Borches and Bonnema 2010). Practicing mechanical engineers apparently felt restricted by using associated modelling tools and required substantial training to be able to apply the different models proposed in UML and SysML (see also Torry-Smith 2013). 3.3.4

Limitations

The comparison is based on the analysis and interpretation of the function models proposed in systematic design approaches described in literature. In some cases, however, few or no examples and limited descriptions of the proposed models and modelling steps were available. The presented literature review is based on the assumption that the approaches proposed in design literature to some extent represent common practice in the disciplines. In addition, it is assumed that they are taught to designers or incorporated in design guidelines and thus – at least subconsciously – influence design practice. The next step in this research is therefore to complement and verify the obtained insights from the presented literature review with empirical research into the application of function models in interdisciplinary design practice.

3.4 Implications The insights obtained in the presented literature analyses suggest that individual modelling approaches are specific in relation to the addressed function modelling perspectives, morphologies, 69

and how to move between them. An integrated modelling approach, hence, needs to link the different function modelling perspectives prominently addressed in the different disciplines, while at the same time provide designers with flexibility in how modelling (and reasoning) is performed. However, the transformation process perspective is most prominently addressed in function modelling proposed across all reviewed disciplines. Transformation processes may, hence, serve as a common basis for the development of such an integrated function modelling approach. Providing designers with an adequate integrated function modelling approach may further improve the designers’ understanding of function modelling and reasoning outside their own disciplines. An expansion of the available vocabulary to describe the contents of function modelling, the designer’s considerations about the functions of a system, and the particular approaches associated to it, hence, may positively influence the comprehension of cross-disciplinary function modelling. It is aspired that such a modelling approach – because of the advantages and opportunities it offers – will enhance the use of function modelling in all disciplines involved in interdisciplinary system development. In order to support the development of an integrated function modelling approach, empirical research is conducted to explore and verify which function models – and hence, which function modelling perspectives and morphologies – are de-facto relevant to practicing designers from different disciplines. The following chapter presents the results of an interview study in ten different companies, which are active in interdisciplinary system development in diverse market areas.

70

4 FUNCTION MODELLING IN PRACTICE – AN EMPIRICAL STUDY

4.1 Intentions and questions In this chapter the results of an empirical study in industry are presented. The study investigates which function models are applied in interdisciplinary design practice and explores experiences with using these models. Furthermore, the participants’ preferences and needs in relation to function modelling, including reasons for not using certain function models, are investigated. The aim is to obtain insights which support the development of an integrated function modelling approach. The study is guided by the following research questions: 1. Which models are used in practice for modelling functions and system functionality? How are these models typically applied during conceptual design? 2. What kind of experiences (good and bad) have been made with the different function models regarding a. modelling in (interdisciplinary) design? b. exchanging information with colleagues (from other disciplines)? 3. Which function modelling perspectives are addressed in the different practically applied function models? What kinds of function modelling approaches are used? 4. Which other function models are known but currently not used? What are specific reasons for not applying them? 5. What kinds of experience have been made when a new function model/modelling approach was introduced in the companies? 6. What kind of (abstract) representation/visualisation of functions is preferred? 7. What kind of support related to (interdisciplinary) function modelling is needed or considered useful by practicing designers? 8. What are different notions of function addressed by designers in practice?

4.2 Study design 4.2.1

Research method selection

Empirical research of designing and related activities is regarded exceptionally demanding due to mutually dependent influences coming from – among other things – involved tools, people, approaches, and terminology (Hale 1987, Blessing et al. 1998). Social sciences provide a wide selection of methods for researching human behaviour and its results (Diekmann 2001). Bender et al. (2002, adapting from Atteslander 1995) differentiate empirical research into studies of human behaviour and 71

studies of products resulting from human activities (see Figure 4-1). Therein, studies of human behaviour are further discriminated with respect to whether performed in natural situations, e.g. at the workplace of the designers, or in an environment controlled by the researcher, such as a laboratory. Analysis can be connected to time and place of the studied behaviour (during observation) or disconnected from it (in surveys). Different variations of these methods are – and have been – widely applied in design research (Jänsch 2007, Blessing and Chakrabarti 2009). Social reality

Products of human activity

Human behaviour

Behaviour

Behaviour

in natural situations (“Field”)

Talking about…

Open behaviour

Content analysis

in synthetic situations (“Laboratory”)

(connected to time and place of behaviour)

(not necessarily connected to time and place of behaviour)

Observation

Survey

Experiment

Figure 4-1: Subject areas and methods for empirical research in social sciences (after Bender et al. 2002) The aim of this study is to explore approaches related to function modelling in practice, including the investigation of experiences as well as specific needs and preferences of designers involved in interdisciplinary system development. This suggests the use of surveys. Surveys are a retrospective data collection method that aim to explore a person’s perspective on a specific issue by asking questions. They typically involve questionnaires and/or interviews targeting people, who are or have been involved in the specific phenomena the researcher is interested in. Interview studies can be essentially divided in three different types (Patton 2002, Blessing and Chakrabarti 2009), these are   

guided or unstructured interviews, which typically use a pre-defined list of questions not necessarily asked precisely as written; standardised open-ended or semi-structured interviews, in which carefully worded questions are asked in the same sequence to each participant; closed quantitative or structured interviews using multiple-choice questions.

While structured interviews and questionnaires facilitate comparative analysis of provided answers, semi- or unstructured interviews are particularly suitable for exploratory research. The diversity related to function modelling that is suggested in the reviewed literature and the initial insights from practice (discussed in Chapters 2 and 3) allows the presumption that terminology and concepts used by individual designers in practice may differ considerably. Therefore, enabling a certain degree of situation-actuated adaptation and potential reformulation of individual questions is expected to be required. For this reason, semi-structured or guided interviews are considered more suited for this study. Compared to structured interviews and questionnaires, they allow for deviation 72

Chapter 4: Function Modelling in Practice – An Empirical Study from a pre-defined set of questions, if required or considered useful. Questions may be asked in alternative sequences and can be adapted in their wording in relation to the specific situation at hand. The possibility to do so is expected to be beneficial in the interview study, as it enables discussion of individual issues in more detail and thus allows for comprehensive exploration of the participants’ opinions on and experiences with function models and their application. 4.2.2

Study overview

The interview study with practitioners, its preparation and post-processing essentially comprised four phases:  preparation of interview questions and study design,  recruitment of participants,  data collection (i.e. interview execution), and  data analysis. Preparation of the interview study included generation of a catalogue of questions to guide the interviews (see Appendix C.I). The catalogue was developed based on the formulated research questions guiding the study (see Section 4.1) and was discussed with different researchers from the field of engineering design research prior to the interview execution. Furthermore, an initial round of interviews preceding the main study was used to evaluate the formulation of specific questions and to adapt them slightly wherever necessary. 4.2.3

Recruited participants

Ten companies were recruited for the study from a variety of market areas, in order to ensure gaining broad insights from interdisciplinary design practice (as suggested by e.g. Cicourel and Haug 1974 and Yin 2009). All companies are active in interdisciplinary system development. Four companies are considered PSS developers as they combine the developed technical products with associated services. Market areas of recruited companies include telecommunication (n=1 company), consumer products (n=1), aerospace (n=2), as well as automotive (n=3) and manufacturing machinery design (n=3). Company sizes vary between a small start-up company with 12 employees to a well-established vehicle design and manufacturing company with more than 275 thousand employees and an annual turn-over of more than 114 billion € in 2012. The companies can be discerned into large (number of designers employed in the company is higher than 250) or medium-sized companies (50 to 250 designers) with globally distributed design teams, as well as small-sized companies employing less than 50 designers located on one site. Half of the companies participating in this study are small-sized. Table 4-1 illustrates the specific disciplines that are typically involved in the design process within the recruited companies. Irrespective of whether the developed product is a mechatronic system or PSS, cross-disciplinary design work is usually performed by individual participants assuming the role of a “system-level designer”. This refers to e.g. systems engineers or project leaders etc. Separate roles of mechatronic or PSS designer were not found in the companies. System-level designers are typically involved in two or more disciplines and coordinate technical design decisions as well as the exchange of information between designers in different disciplines. Participants ought to have been collaborating with each other on a regular basis in current or past design projects. Selection of participants within the companies was facilitated by the heads of the 73

organisational unit participating in the study. In each company, a single organisational unit was selected. A total of 35 participants were recruited for the study. Participants comprise specialist designers (n=18) involved in discipline-specific development in mechanical engineering, electrical engineering, software development or service design. In addition, participants were recruited that are involved in system-level design and/or assume strategic management positions (n=17). Participants had an average of 14.1 years of professional experience, with a minimum of 4 years and a maximum of 33 years. The majority of participants (n=25) possessed profound professional experience of 10 or more years. All participants had been involved in numerous interdisciplinary design projects prior to the interviews and were thus considered suitable for the study. Five participants were specifically selected, as they were or had been involved in developing and introducing function modelling across disciplines in their respective companies. A comprehensive overview of the profiles of individual interview participants is provided in Appendix B.II. Table 4-1: Overview of companies involved in the study

Σ participants in study

Mechanical engineering

Electrical engineering

Software development

2

x

x

x

B

Special machinery

< 50

one site

One off

2

x

x

x

Aerospace

< 50

one site

One off/batch production

5

x

x

x

x

Mass production

4

x

x

x x

C D

50 - 250 global

Automotive

> 250

global

Mass production

3

x

x

x

Automotive

> 250

global

Mass production

5

x

x

x

G

Telecommunication

< 50

one site

Web-based service

2

H

Aerospace

< 50

one site

F

I J

4.2.4

PSS

E

Automotive

One-off/batch production

5

x

x

Consumer products

50 - 250 global

Mass production

1

x

x

Manufacturing machines

50 - 250 global

Batch production

6

x

System-level design

Type of production One off

Service design

Distribution of different design teams one site

Mechatronic systems

< 50

Companies A

Main market Special machinery

Σ designers in company

Disciplines addressed in study

x

x

x

x

x

x

x

x

x

x

x

Data collection

Participation was voluntary for all participants. Before the start of the interview, participants were introduced to the objectives and nature of the study and were informed about their right to discontinue participation at any time without consequences. Interview execution Native languages of participants comprise Dutch, French, German, Italian, and Luxembourgish. Interviews were conducted in English or German. Data collection was composed of two parts in each company: 



brief preparatory discussion with a selected participant (project manager or key designer) focusing on the developed system and its sub-systems, design context, and typically applied design steps; main interview study with all participants focusing on the current application of function models, as well as personal preferences and required support for (interdisciplinary) function modelling. 74

Chapter 4: Function Modelling in Practice – An Empirical Study The brief preparatory discussions focused on understanding the design context, the specific system under development, and its sub-systems. In addition, the typical (sequence of) design steps taken during conceptual design were explored. For these brief initial questions one key designer, project leader or strategic manager from each company was selected, who could provide a comprehensive overview of the conceptual design stage from a management perspective. Participants were asked to describe market and customers, typical design and modelling activities, as well as the organisation of the design team. The second part comprises the main interview study and included all participants. The interviews started by asking the participant to briefly describe their usual involvement in the conceptual design stage, including their specific role as well as applied design and modelling activities. Participants were encouraged to refer to both on-going as well as past design projects that they had been involved in. The interviews were guided by the developed question catalogue (see Appendix C.I). It comprises of open-ended questions, which are intended to guide the interviews and ensure that every topic relevant to the study is addressed. Part II, III, and IV in the catalogue are specifically intended to spark and guide more open discussions about the respective topics with the interviewees. These parts in the catalogue are complemented with several supporting questions (marked in blue), which could be used, in order to encourage discussions further, when needed or considered useful. It was a clear intention in this part of the interviews to get the participants to talk more freely and share their genuine experience with function modelling. Setup Interviews were recorded; in addition, the interviewer took notes, in order to put down central statements that seemed particularly relevant. Note taking was further used to write down queries on specific details arising in the progress of a discussion, so they could be asked later on without necessarily breaking up an on-going discussion. In one company (5 interviews) audio-recording was not permitted and data was collected through note taking only. Paper sheets were provided for note taking by the interviewer and could be used by the participants e.g. for sketching. Participants were asked to bring their laptops to the interview, in order to be able to show examples of used models. Interviews were typically conducted individually, face-to-face in a separate room at the site of the company. One interview was conducted via telephone. The majority of the interviews lasted between 60 and 90 minutes. One interview with a senior designer was considerably faster. The person did not apply function modelling himself; therefore, only selected questions in the catalogue applied. For clarifications and verification of some answers selected participants were contacted again after the interviews to support the interview analysis. 4.2.5

Data analysis

Analysis of the collected data started with the transcription of the collected audio recordings. Similarly, the notes taken in those interviews, which could not be recorded, were digitalised. Answers from each participant were labelled in the transcripts according to which of the research questions (Section 4.1) they address. The given answers were analysed individually and across different interviews, in order to identify concepts, themes, and opinions addressed by the participants. These insights were used to derive categories for coding the different provided answers. Categories were formed based on the researcher’s interpretation of the analysed answers. 75

A potential risk inherent in any interview is an unconscious influence on participants by the specific way a question is asked, which may unintentionally convey the interviewer’s expectations in relation to the provided answer. This is typically referred to as “experimenter bias” (see Blessing and Chakrabarti 2009). Such an influence may have occurred, as parts of the interview were discussionbased, which means that some questions were reformulated to not break the flow of an on-going discussion. To minimise any bias, before the analysis of the interviews, therefore, the transcripts were carefully reviewed and any question and answer pairs that seemed in any way mooted were removed. However, this was rarely required.

4.3 Findings The following section presents a few examples of specific function models that could be found in the different companies. Subsequently, the findings for the each research question 1–8 guiding the study (see Section 4.1) are successively addressed in Sections 4.3.2–4.3.9. 4.3.1

Examples of function models found in practice

An example of an in-house developed function model is the “Function Parameter Model” (see Figure 4-2). According to the interviewee who described it, it is adapted from classical function models from mechanical engineering literature such as Rodenacker (1970), Ehrlenspiel (2007) or Pahl et al. (2007). The model is typically applied and shared among a few system-level designers in the company. The model is mainly used for the analysis of single functions with regard to the transformation of inputs to outputs, including potential effects from eventual disturbances that result in undesired outputs. Undesired outputs may be safety-critical or cause malfunctioning. A described example for the application of the model concerns the detailed analysis of heat distribution functionalities of a developed sub-system. The functionality could be influenced by several control parameters, in order to react to external disturbances. Through this detailed analysis, the search and selection of suitable and particularly robust solutions is facilitated in the design team. Disturbances

Inputs

Function

Desired outputs Undesired outputs

Control parameters

Figure 4-2: Schema of "Function Parameter Model" An example of a model addressing specific aspects of functionality in service development is the “Service Process Model” (see Figure 4-3). Therein, service activities are sequentially modelled. Each represented activity is complemented with information about involved technical means supporting service execution (such as telephone, software data storage, etc., see Figure 4-3) as well as involved stakeholders (such as the customer, the servicing staff, etc.). They are differentiated in relation to whether they are providing input or are receiving output from a specific service activity. The model is typically generated during design of a service, in order to explore and specify required steps, activities, and related resources for service execution. Later on – during service execution – the model was described to serve as a reference model for the service staff. 76

Chapter 4: Function Modelling in Practice – An Empirical Study

Figure 4-3: Example of "Service Process model" from Company J (excerpt) Another example of an in-house developed function model is the so called “Function Cycle Breakdown” (see Figure 4-4). It is typically used as a reference model for different designers and, in particular, by software developers for design and parameterisation of the required control software system. It represents the sequence of specific functions in relation to the quantitative flow in time using a similar structure as a Gantt chart (see Gantt 1910). It illustrates the concrete starting point and duration for the execution of individual functions in the application of the developed machinery. ID

Functions

Start

Duration

End

1 2 3 4 5 6 7 … n

Function 1 Function 2 Function 3 Function 4 Function 5 Function 6 Function 7

0 1 1 2 5 5 1

2 5 5 5 6 4 10

1 5 5 6 10 8 10

Function n

2

9

10

0 sec.

5 sec.

10 sec.

Figure 4-4: Schema of “Function Cycle Breakdown” “Grafcet” (see e.g. VDE 2004) is a variant of classical function block diagrams from electrical engineering, which are typically applied in automation technology to support the development of control systems, such as Programmable Logic Controllers (PLCs). Figure 4-5 represents an example of a Grafcet model generated in Company A. It illustrates the sequence of functions (also referred to as “activities” or “technical processes”) which have to be carried out by a (sub-)system. The represented function flow is complemented with associated system states. Represented system states illustrate the pre-conditions for the execution of a function and at the same time represent the post-condition for the preceding function. The required transitions of system states from input to output define the individual steps in the function flow. Grafcet is applied in two of the companies involved in the study (Companies A and B) with the intention of supporting selection and design of electrical components 77

and required ports (for incoming and outgoing signals). Furthermore, the model is used to support coding of the required software control system. It is thus collaboratively used in electrical engineering and software development. M 148.0

1

Grundstellung [6370] leer

M 148.1

2

Übergabe absenken [6370] OT

Legend: M 148.2

3

Warte auf FRG LR [6370] FRG_Einlauf

M 148.3

4

Rolleingang EIN [6370]

Required system state

Einlauf M 148.4

5

Function/ technical process

ID

Einlauf sperren [6370] /Einlauf+KG

M 148.5

6

KG [6370] Halt

7

Übergabe Anheben [6370]

…

M 148.6

Figure 4-5: Example of Grafcet model from Company A (excerpt) A particularly prominent example of a function model used in practice is a Function Flow Chart. Therein, functions are modelled related to their qualitative flow in time (sequential or in parallel). They correspond to a large extent, for instance, to use case activity flow diagrams (see Figure 3-13). A schema of a Function Flow Chart found in Company H is presented in Figure 4-6. Similar models were found in five out of the ten visited companies. In Company H the model is collaboratively used within electrical engineering and software development. Function 1 Function 2

Function 4

TIME

Function 3 Function 5 Function 7

Function 7’

Function 8

Figure 4-6: Schema of a Function Flow Chart A particularly interesting example of a function model that was developed in one of the visited companies is the “Allocation Matrix” (see Figure 4-7). The model uses a matrix-representation for making explicit which sub-systems, alone or in combination with others, are foreseen for implementing the different functions that the system is expected to fulfil. In the application, the main system functions are derived from the requirements list and are subsequently decomposed into required subfunctions. Sub-functions are then allocated to the concrete sub-systems that are contributing to their 78

Chapter 4: Function Modelling in Practice – An Empirical Study fulfilment. The model is intended to serve as a reference model on system level in the company. At the time of the study, the model had not yet been applied in on-going projects. It is expected to support managing sub-system development by making explicit which sub-systems are collaboratively – and thus interdependently – contributing to function fulfilment. A similar model is already used in one more company and currently being elaborated in a third. Function 2

Function 3

Function 4

Sub-system 4.1

…

X

Sub-system 4

Sub-system 4.2

Sub-system 5

Neighbouring systems … …

System under consideration

…

Function 1

Sub-system 4.3

X X

Sub-system 4.4 Sub-system 4.5

X

Sub-system 5.1

X

X X X

Sub-system 5.2

(Sub-)system X

X

(Sub-)system Y

X X

Figure 4-7: Schema of “Allocation Matrix” Generally, the idea (and/or desire) of making the concrete allocation between functions and the solution elements from different disciplines that are foreseen for their implementation explicit in used function models was found in four out of the ten visited companies. 4.3.2

General application of function models during the conceptual design stage

The first research question can be answered by consolidating the answers provided to questions in Parts I and II in the interview catalogue. Participants were asked to describe their typical role during conceptual design, as well as their typical design and modelling activities. They were further asked for examples of used function models and to explain their typical utilisation in the design process. Participants referred to a total of 23 different function models that are typically applied during conceptual design (see Appendix E.I). 16 of the function models directly originate from design literature. In one case, a function model (use case descriptions) had been slightly adapted from the original by the designers using them. Eight applied function models can be considered new models, which were developed in-house in different companies, some of which were presented in the preceding section. Four of the referenced function models are applied in two or more companies. Specific models and experiences with their application are discussed in detail in Section 4.3.3. On a meta-level, the application of the function models in the companies was found to vary in relation to  

the level of participation, as well as the specific purpose it is used for by individual designers.

These are described in the following. Subsequently, the typical application of function models in the course of the conceptual design stage that was described by the participants is presented. 79

Level of participation Different levels of participation are derived from the typical involvement of designers (from different disciplines) in the generation and application of function models. For instance, models may be used by single designers or by multiple designers from one, two or more disciplines. Essentially, four distinct levels of participation can be distinguished:  





Level 1 – personal function modelling refers to function modelling by a single designer; the generated function model is not shared with another designer. Level 2 – function modelling within one discipline typically involves modelling functions related to discipline-specific sub-systems. It may be performed either collaboratively or individually by designers within a discipline and is subsequently shared within this discipline, but not with other disciplines. Level 3 – function modelling between selected disciplines typically involves modelling functions in relation to sub-systems that involve two or more disciplines in their development. It is typically performed collaboratively by designers from the involved disciplines. Level 4 – system-level function modelling involves modelling individual functions and/or overall functionality of a system under consideration across all involved disciplines. It is typically performed collaboratively by system-level designers and/or key designers from involved disciplines; the resulting model is shared between all disciplines.

Four of the referenced function models were found to be applied on different levels of participation in different companies (n=5, see also Section 4.3.3). Different purposes for applying function models Individual participants described different purposes for the application of specific function models during conceptual design. Usually, function models are used for multiple purposes by different designers. Essentially, four distinct purposes can be discerned: 







Support the solution finding process: Participants described to be using function models to support their specific reasoning process towards a potential solution during conceptual design. This may include exploring, determining, and analysing the required functions, as well as their mutual dependencies; it may also involve function analysis of any already known solution elements, in order to select and design new elements appropriately. Support specification of sub-system requirements: Participants described to be using function models, in order to determine which functions and requirements will be realised by which of the specific solution elements that are foreseen for their implementation. Solution elements typically compose of distinct sub-systems (such as e.g. modules, components etc.). Based on this analysis, separate sub-system requirements specifications may be generated, in order to support the subsequent development of the different sub-systems in the different disciplines. Documentation of solution finding process: Conceptual design is cascading from requirements to a potential solution concept and involved solution elements. Some participants saw function modelling – pertaining to a management point of view – as a means for tracing the different performed design steps in the solution finding process. Consultation only: Some participants explained that they would only use specific function models, in order to retrieve information which was required in another modelling step or design step, but would not use the concerned function model for other purposes. 80

Chapter 4: Function Modelling in Practice – An Empirical Study Two participants expressed further interests in function modelling. One person involved in systemlevel design explained to also be using a function model, in order to monitor the progress in a design project. This is performed by the participant by tagging the already implemented functions in comparison to not-yet-implemented functions in the respective model. The other participant explained that function modelling to him also serves as a means for detailed exploration and comprehension of what is de-facto required of the system under development. The information determined during function modelling is then used for further detailing of the requirements specification. This is, effectively, evidence of early co-evolution in the design process. Modelling in the course of the conceptual design stage The specific design and modelling steps used in the conceptual design stage are specific for each visited company. The starting point usually builds a requirements specification for the system to be developed. The design and modelling steps performed based on this requirements specification can be differentiated in the phases of system-level design and disciplinary design (see also Figure 4-8): 

Deriving main system functions and subfunctions

Model addressing solution

Progression

(Not shown: personally used models addressing the solution)

Level 4: Function model shared across all disciplines

Sub-system requirements specification

Sub-system requirements specification

System-level design Disciplinary design

Allocation to concerned sub-systems

Level 3: Function model shared between selected disciplines

Discipline 1

Model(s) addressing solution

Discipline 2

Discipline 3

Level 2: FM shared within discipline

Level 2: FM shared within discipline

Model(s) addressing solution

Model(s) addressing solution

System-level designer(s) and/or key designer(s) from different disciplines)

Requirements specification Function model

Supervision by system-level designer

System requirements specification

Legend

New/updated system structure



Initial system structure

system-level design encompasses determining an initial system structure and allocation of requirements and expected functions to the specific sub-systems foreseen for their implementation; disciplinary design encompasses determining the solution concepts for each sub-system to be developed within the respectively responsible discipline(s).

Level 1: Personally used function model

Figure 4-8: Function modelling on different levels of participation during conceptual design Participants portrayed conceptual design to be progressing from general to concrete. That means, from a modelling point of view, designers gradually move from general, i.e. addressing the entire 81

system, to more concrete, i.e. focusing on specific (interdisciplinary) sub-systems. This seems to be typically performed in a highly iterative manner. Both phases are – to different extents – supported by function modelling:   

in three companies function modelling is applied already during system-level design; in six companies it was only applied during disciplinary design; finally, one company (Company G) did not apply any function models.

The use of functions model in both phases, portrayed by the interviewees, is described in the following. System-level design In six companies, in an initial step the requirements from the requirements specification are sorted into “functional” and “non-functional” requirements. One expressed reason for this sorting step is to build an initial comprehension of the functionality expected from the system and to support subsequent function modelling. The concrete differentiation between what is considered a functional and a non-functional requirement varies between companies. Essentially, the terms may be distinguished in the following way:



Functional requirements describe and specify an expected and measurable behaviour of the system to be developed;



Non-functional requirements specify specific constraints, expected physical stresses to be supported or target values (e.g. regarding performance, durability, etc.) related to the expected system functionality.

In the next step, requirements are allocated to the prospective sub-systems that they concern. The initial decomposition into sub-systems used in this step is usually taken from an already existing system structure21. In the three companies that use function modelling already during system-level development, this allocation step is explicitly facilitated using the generated system-level function models. System-level function modelling is performed on level 4 of participation (n=2 companies) or level 3 (n=1). Based on these system-level function models, separate partial requirements specifications for (selected) subsystems may be generated22. The models support making explicit which functions and requirements will be implemented by which sub-system. This was briefly discussed in Section 4.3.1 relation to the Allocation Matrix (see Figure 4-7). Disciplinary design The disciplinary conceptual design phase focuses on determining solution concepts for the subsystems to be developed. In eight companies, a limited number of disciplines use a shared function model (level 3) to support the joint selection of discipline-specific solutions (see Table 4-2). In most cases, this involves system-level designers, electrical engineering, software development, and also service development (if applicable). Mechanical engineering is rarely involved in level 3 function

21

All but one company perform evolutionary or variant design projects. In these cases the initially used system structure may originate from former development projects. In original design projects (occasionally applied in three companies), usually a sort of basic system structure taken from similar systems is used as a starting point. 22 In the company that uses level 3 function modelling during system level design, the generation of sub-system requirements specifications is limited to electrical engineering and software development.

82

Chapter 4: Function Modelling in Practice – An Empirical Study modelling. Apart from level 3 function modelling, discipline-specific conceptual design involves function models either shared within one discipline (level 2) and/or personally used by individual designers (level 1). In seven companies, single disciplines do not use any kind of function model on a regular basis. In five of these seven companies, this refers to mechanical engineering. In one of these companies it refers to mechanical engineering and electrical engineering. The last of these seven companies does not use any function models at the moment (as discussed before). In those disciplines that do not use function models regularly in these companies, conceptual design moves directly from the requirements specification to an initial solution concept that is subsequently developed in detail. Designers from different disciplines may be working in parallel (n=7 companies) or sequentially (n=2). In one company, two disciplines were found to work parallel, whereas the other disciplines work sequentially. Table 4-2 collocates the discussed findings. In the table, companies are ordered in relation to the level of participation on which function modelling is usually applied. Appendix D.I exemplarily describes the conceptual design stage typically performed in three of the companies in more detail. Table 4-2: Use of function models and types of design described in the companies

Level 4

Level 3

Level 2

Company G

Level 1

Addressed levels of participation

?

D

?

x

A B J I C E

x ? ? x x

x x x x

x x x x x x

H F

? x

x x

x x

x x

Discipline-specific design in parallel

Novelty of design On-demand adaptation of software system

in parallel

Evolutionary design

sequential sequential partly parallelised in parallel in parallel in parallel

Evolutionary design, (original design) Evolutionary design, (original design) Variant design Evolutionary design Evolutionary design, (original design) Evolutionary design

in parallel in parallel

Evolutionary design Evolutionary design

Conceptual design is typically supported by existing or gradually generated models addressing the emerging solution (such as sketches, CAD data, circuit diagrams etc.), which are further detailed in subsequent design stages. Similarly, the initial system structure is gradually adapted with respect to the newly defined solution concepts and results in a new or adjusted system structure (see Figure 4-8). Discussion The conceptual design stage described by the participants seems largely dependent on the specific company and on the disciplines involved. Mechanical engineers, for instance, were found to be using function models considerably less often than other disciplines. The differences also surface in terms of the level of participation of different disciplines in the generation and application of function models. At the same time, the level of participation on which function models are used seems corresponding to the specific purpose for which function models are used. This can be seen with respect to systemlevel function models (used on level 4). These mainly serve the purpose of supporting the allocation process of requirements and functions to the solution elements foreseen for their implementation. In the following section, the specific usage of the found function models in different companies and disciplines as well as specific experiences made with their application are investigated in more detail. 83

4.3.3

Experiences with modelling and exchanging information using function models

The second research question is addressed by consolidating the answers provided to the questions in Parts II and III in the catalogue. For the function models that the participants personally apply, they were asked to describe and assess the experiences they made, regarding  

modelling in (interdisciplinary) design, as well as exchanging information with colleagues from either - the same discipline or - other disciplines (if applicable).

32 participants provided comprehensive descriptions and assessments of the applied function models, which could be analysed and categorised by the researcher. Selected categories for coding comprise “+” “0” “–“

rather positive, neutral, and rather negative.

The limitation to these three categories was chosen to prevent a bias from over-proportional weighing of a (strongly positive or negative) singular opinion of an individual participant. Table 4-3 and Table 4-4 collocate the categorisation of all 23 function models included in the study. The tables separate function models with respect to the level of participation, i.e. the specific level to which the models are typically shared between disciplines. In addition, the tables aggregate information about the companies and disciplines typically using the function models.

Finite state machine Function flow model "Function parameter model" Function runtime model

D D F C

electrical engineering electrical engineering system level design electrical engineering

Morphological chart

F

system level design

"Service flow model" "Service process model" "State/time diagram" Use case description + flow model Use case shematics + sequence diagram

I J J

service design service design mechanical software development system level design

D C

SDL model, Matlab/ Simulink models (Finite state machines) Function parameter model

supplementary requirements specification

software development

1

x

x

+

N.A.

1

x

x

+

N.A.

1 1 1 1

x x x x

x x x x

+ + + +

0 0 + +

1

x

x

+

+

1 1 1 1 1

x x x x

x x x x

1

x

Consultation only

Associated models

exchange information within discipline

"State/position diagram"

Company/disciplines using the model electrical engineering C electrical engineering B software development

Experiences with…

Purpose

Support solution finding process Support specifying subsystem requirements Documentation of solution finding process

Function model IDEF-0

applies driving aspect may apply does not apply does not occur/ no answer provided

modelling

level 2

level 1

Legend: x grey cell (x) empty N.A.

Σ participants addressing model Involvement of disciplines in generation

Table 4-3: Function models used on level 1 and level 2 of participation

x

x (x)

x

x

+ 0 + + + + + + N.A. N.A. +

+

The majority of function models applied in the companies (n=17) is mainly used by the interviewed designers for the purpose of facilitating the solution finding process. This applies to designers from all disciplines, however, substantially less often to designers involved in mechanical engineering. Only a single mechanical engineer stated to use function modelling for this particular purpose (see Table 4-3). 84

Chapter 4: Function Modelling in Practice – An Empirical Study Elsewise, mechanical engineers use function models mainly as a reference model, which are consulted e.g. to retrieve information about the specific flow of functions (n=3) or regarding the specific dependencies between functions and allocated sub-systems (n=4). Such a pattern was not found in any other discipline. Nevertheless, those mechanical engineers that are using function models described them to be beneficial, particularly when it comes to the exchange of information with colleagues within and across disciplines.

Level 4

Level 3

"System Function Requirements Document" "System Function Specification"

H

F

(Flow charts)

Pre- and postcondition table

1

x

x

2 1 1 1 1 1

x x

x x

2

+

x x x x

x

x

x

x x x

1 (Finite state machines)

1

(x) x

x

2

x x

x x

Mechanical layout

1

x

Pre-concept, (mechanical layout)

1

x

1

System function requirements

mechanical enginering electrical engineering (use case software developement schematics) service design system level design mechanical enginering electrical engineering software developement system level design

x x

+

+ + + + N.A. N.A. + + + + + + +

+

N.A. N.A. +

x x x

exchange information within discipline exchange information across disciplines

Associated models

Experiences with…

modelling

Company/disciplines using the Function model model electrical engineering H software developement Finite state electrical engineering machine C software developement system level design mechanical enginering "Function cycle J software developement breakdown" system level design Function flow electrical engineering E diagram software development mechanical enginering Function flow electrical engineering H chart software developement service design "Function electrical engineering E database" software developement electrical engineering A software developement Grafcet electrical engineering B software developement Morphological I system level design chart C system level design Use case system level design H schematics service design

Purpose

Consultation only

applies driving aspect may apply does not apply does not occur/ no answer provided

Support solution finding process Support specifying subsystem requirements Documentation of solution finding process

Legend: x grey cell (x) empty N.A.

Σ participants addressing model Involvement of disciplines in generation

Table 4-4: Function models used on level 3 and level 4 of participation

+

N.A. N.A.

+ + + + + + + + + + +

+

+

+

x

+

+

+

x

x

+

+

+

1 1 1 1

x x x (x)

x x

+ + + +

+ + N.A. N.A.

+ + + +

1

(x) (x) (x) x x x x x x

+

N.A.

-

+

+

-

+ + -

+ N.A. +

+ + +

+

+

+

+

+

+

1 1 2 1 1 3

x x (x)

(x)

(x) (x) (x) (x) x

x x x x x

x x x

x x x

x x x

Expressed strengths and weaknesses The majority of participants assessed the application of the used function models rather positively. Only in a few cases, participants described to experience specific problems related to different models. A comprehensive collocation of expressed strengths and weaknesses for specific function models is provided in Appendix E.II. The central identified aspects are discussed in the following.

85

Central expressed strengths of used function models Different participants essentially expressed three particular strengths of different function models: 





Traceability: For the four models specifically used for the purpose of supporting the specification of sub-system requirements (i.e. the Function Database, use case schematics, System Function Requirements Document, and System Function Specification, see Table 4-4), seven out of the total of twelve participants applying these models particularly highlighted the benefit of traceability. Here, traceability refers to making explicit which functions will be implemented by which solution elements. Traceability was described to result from clearly visualising the allocation of functions to specific sub-systems foreseen for their implementation graphically (as already discussed in relation to the Allocation Matrix, see Figure 4-7). Comprehension of the system context: Use case modelling is applied in three of the visited companies. All participants using use case modelling described it to substantially support obtaining a thorough comprehension of the system context. This refers to clarifying the system border, peripheral technical (sub-)systems, and stakeholders (such as users) as well as their interconnection and specific interactions with the system under development. Support of (cross-disciplinary) collaboration: Being aware of the links and dependencies between the system under consideration and its surrounding, as well as dependencies among its sub-systems, was described to support collaboration both within (expressed in 4 companies) and across disciplines (expressed in 2 companies). This refers to being aware of potential effects of introduced design changes across functionally dependent sub-systems, as well as of all departments and persons involved in the development of different sub-systems.

Regarding the latest, one participant with a mechanical engineering background from Company F, for instance, explained that the specific potential of the used system-level function model (i.e. the System Function Specification) to support cross-disciplinary collaboration originates from the facts that Q1: “…the interfaces between involved personnel have improved considerably […]. The [model] forces you to deal with the [entire] system […]. Now you know much better who else is involved with the system and who you need to talk to. […] The comprehension of the system has improved. […] If we get a new employee, e.g. fresh from the university, and want him to quickly understand the system we develop, we give him the [System Function Specification]. It is the best way to quickly learn how the systems functions; but reading those [documents] is hard work!“ Similar remarks were made by three more participants from the company. The System Function Specification addresses a large number of functions, descriptions of the specific contributions of all involved sub-systems to function fulfilment, and of the requirements associated to individual functions and selected sub-systems. The descriptions of the contributions of individual sub-systems to function fulfilment are derived from their explicit visual allocation in the model. The allocation is performed using a matrix, which is quite similar to the Allocation Matrix presented in Figure 4-7. Central expressed weaknesses of used function models 

Complexity: Reading the System Function Specification was described to be “hard work” (see Q1), as the specific final model typically results in a complex and rather long, mainly text-based document. Problems with model complexity were also described regarding the use of IDEF-0 by one other participant from a different company. 86

Chapter 4: Function Modelling in Practice – An Empirical Study 

Miscomprehension: Six participants from three companies (two large, one small) further expressed difficulties in the exchange of information while using function models. This refers to miscomprehension or even incomprehension of specific functions, due to the way these are formulated. These difficulties were described to occur regularly in the companies and result in increased time and effort required for clarification of specific formulations and eventual design iterations (due to misunderstandings which can cause design errors).

In order to address the issue of miscomprehension of specific formulations, specific guidelines and in one case special training were introduced for the designers in the two large companies. Participants from both companies explained that these measures helped to reduce the problems with miscomprehensions to a certain extent. This is discussed in more detail in Section 4.3.6. Occurrence of miscomprehensions in general was remarked by participants from five more companies (small and medium-sized). In spite of regular occurrences of such miscomprehensions, it was not necessarily considered a problem in these five companies. The respective participants claimed – particularly in small-sized companies – that they can usually quickly clarify any miscomprehensions through personal discussions with their colleagues. Discussion Function modelling is typically proposed in literature, in order to support designers in the reasoning process towards a potential solution (as discussed in Section 2.2.3). The findings suggest that this is also the main reason for applying specific function models in the participating companies. The models utilised for this purpose were assessed predominantly positively (see Table 4-3 and Table 4-4). A potential explanation for such a positive assessment could be that only those function models have prevailed in the companies, which can be conveniently applied and provide a benefit to the designers using them. Two participants made remarks, which foster this assumption. However usage of function models for this purpose is typically limited to design of sub-systems and not applied on system level. On system level, function models are mainly used with the purpose of supporting the specification of sub-system requirements (see also Figure 4-8). For these function models the issue of traceability between functions and solution elements was highlighted as a particular strength. Another benefit is the support for obtaining a thorough comprehension of the system under consideration, particularly regarding its context as well as involved sub-systems and their mutual dependencies in function fulfilment. These two aspects – traceability and an increased system comprehension – were expressed to provide a substantial benefit when it comes to supporting (cross-disciplinary) communication. Apart from the measures taken in the two larger companies, the findings suggests that supporting traceability and system comprehension may also help addressing the issue of miscomprehensions of modelled functions. This seems to be a particularly dire issue in large, globally distributed companies, because individual designers may not be aware of all persons involved with the development of a system and the functional dependencies between developed sub-systems (as indicated in Q1). An increased system comprehension was described to help with these difficulties. 4.3.4

Addressed function modelling perspectives and used modelling approaches

This section presents the analysis and categorisation of the function models applied in the visited companies with respect to the addressed function modelling perspectives and used modelling morphologies, in order to answer the third research question. The basis for the analysis are examples 87

or schemas of the function models used in the companies. Examples were provided by the participants as print-outs. Schemas were sketched on paper either by the participants or noted down by the researcher based on an example shown on a computer screen during the interviews. For two out of the total of 23 applied function models no print-outs or schemas were disclosed by the participants; which prevents detailed analysis. The remaining 21 function models were analysed using the same approach as described in Chapter 3. That means, analysis of the used function models was performed in the same manner and using the same categories that are described in Section 3.1. In addition, four companies were found to explicitly propose distinct function modelling approaches, i.e. a specific sequence of modelling steps, in two cases including multiple function models. The function modelling approaches from two of the companies are exemplarily described later on in this section. Addressed function modelling perspectives and modelling morphologies Table 4-5 collocates the results of the analysis for those function models that were either developed in-house in the companies or that are adapted from an original proposed in literature (see also Appendix E.I). Addressed function modelling perspectives and used modelling morphologies of those functions models that originate from design literature can be directly taken from the table presented in Appendix A. Table 4-6 aggregates the addressed function modelling perspectives and used morphologies for the disciplines that are actively involved in the creation of the specific function models on a regular basis (as indicated in Table 4-3 and Table 4-4). A particularly striking finding suggested in the analysis is the predominance of time flow-oriented representations of functions. From the total of 21 evaluated function models 15 are based on a flow in time. In comparison, four function models were found to structure their representation of functions hierarchically and only in two models flows of operands are used. Table 4-5: Function modelling perspectives addressed in in-house-developed function models

Function flow diagram

E J

"Function parameter model"

F

Grafcet

A, B

"Service process model"

J

"State/time-model"

J

"State/position diagram"

B

Use case flow model

o

o

o

o

x

x

o

x

o

x

Flow of operands (input/output relation)

Flow in time

x

F

"Function cycle breakdown"

Use case descriptions

Hierarchical structure

x**

Stakeholder allocation

Function Flow Structure Function Allocation Chart "Function database" "System Function Specification"

Used in

Technical system allocation

Function models

Use case

o x* x**

Interaction processes

function modelling perspective may be included implicitly addressed in function model changed states included after each operation states proposed as pre- or post-condition of operations

Morphologies

Transformation processes

(x)

Function modelling perspectives

Effects

does not apply; not included driving aspect function modelling perspective is explicitly addressed

States

empty black cell grey cell

D

x x o x x**

(x)

x x x**

88

x x x x x x

x o

x

x x

x x

x o x

Signals E, M, S

x

x

x

x x

x

o o

x x x x x x

Chapter 4: Function Modelling in Practice – An Empirical Study Table 4-6: Overview of function modelling perspectives and modelling morphology addressed in the function models used in different disciplines number entries: amount of function models that were found to explicitly address the respective aspect

Interaction processes

Use case

Technical system allocation

Stakeholder allocation

Hierarchical structure

Flow in time

4

1

0

3

2

2

3

0

0

7

1

0

3

1

2

5

0

0

12

4

2

4

4

2

6

1

0

0

3

2

1

3

3

1

2

0

4

1

8

1

1

3

2

3

3

1

 function models

States

black cell: most prominently addressed aspect(s) in the discipline

5

3

Electrical engineering

9

6

Software development

13

8

Service development

4

System-level design

9

Mechanical engineering

Flow of operands (input/output relation)

Transformation processes

0

grey cell: prominently addressed aspect(s) in the discipline

Discipline

Morphologies

Effects

Function modelling perspectives

Additional contents addressed in selected function models in the companies Apart from the identified function modelling perspectives, additional contents were found in some of the function models applied in practice. These are   

constraints and target values for function execution (in n=3 function models), bilateral impacts and dependencies between solution elements (n=2), and impacts from the environment (n=1).

The inclusion of constraints and target values was found in function models from three companies: in the Function Database (developed in-house in Company E) and in use case modelling in two companies. The inclusion of information about constraints and target values for function fulfilment was also found in two examples of function models from literature (see Section 3.1.2). In the three companies, this information is included in the function models as textual descriptions specifying the modelled functions further, either as part of the formulation of the function (e.g. “provide 5 to 10 Nm of torque”) or as supplementary list of attributes for individual functions. Bilateral impacts and dependencies are specifications of mutual exchanges between interacting solution elements. Through their interactions, solution elements contribute to the fulfilment of expected functions. The interactions are realised through the bilateral impacts. This kind of information is typically addressed in documentations of interfaces between sub-systems (e.g. “send 12 Volts signal from A to B”). Bilateral impacts are hence more concrete as compared to the interaction process perspective. Bilateral impacts are included in two function models from two companies. The first model represents the allocation between functions and solution elements similar to the example in Figure 4-7: bilateral impacts are included into the cells that specify the involvement of solution elements in different functions. In the other function model, bilateral impacts are textually described as part of a function list. Finally, impacts from the environment and their potential effect on function fulfilment are addressed in the Function Parameter Model (see Figure 4-2). This kind of information is also addressed in a few function models found is literature (see Section 3.1.2). The Function Parameter Model allows for

89

detailed analysis and representation of impacts resulting from external disturbances, potentially even going into analysis of basic physiochemical effects. Function modelling approaches proposed in the companies Various participants described a sometimes rather lose sequence of modelling steps that they typically apply flexibly in a design project. The descriptions suggest that the specific modelling activities applied strongly depend on the personal preferences of individual designers. Furthermore, they can be influenced by the novelty of the design (i.e. the potential extent to which models from former design projects may be reused) and the progression of how the information to be modelled is gradually generated in the course of the design project. This pattern is not limited to function modelling, but similarly applies to other models generated in the course of conceptual design in the companies. In four companies, however, participants described rather strictly applied approaches related to function modelling. That includes specific sequences of modelling steps for multiple (partial) models. These modelling approaches were specifically proposed in-house in the companies for the designers to employ. Two of these modelling approaches are exemplarily discussed in the following. The first approach concerns the use of Grafcet (described in Section 4.3.1, see also Figure 4-5); the other approach concerns use case modelling in Company D. The latter covers use case descriptions and use case activity flow diagrams. For both modelling approaches, the respective sequence of modelling steps and associated function models are provided in Appendix D.III. The addressed function modelling perspectives differ; more importantly, however, the respective entry points for modelling and the reasoning about system functions (i.e. the sequence of modelling perspectives addressed) differ largely. The reasoning seems to move in opposite directions (this similarly applies to the two found modelling approaches that are not described in detail here): 



Participants in Company D used established literature (explicitly referring to Cockburn 2000) to inspire the described sequence of modelling steps. It starts with determining central use cases and involved actors (i.e. stakeholder and technical system allocation) as well as their interaction processes. Subsequently, the flow of interaction processes and technical processes that need to be fulfilled by the system under development is established for each use case. In contrast, modelling with Grafcet starts by determining the main system functions and subfunctions (technical processes), as well as their sequence in time. These are then allocated to the specific electrical components (i.e. allocation of technical (sub-)systems) foreseen for their implementation. Finally, the function flow is complemented with the required states in the system (associated to the allocated sensors, actuators, etc.) and their changes.

Discussion Process flows are most prominent The findings strongly suggest that time flow-oriented representations of functions are predominant in practice. In fact, they were found to be the most applied morphology within and across all disciplines in the visited companies. The findings further suggest that the transformation processes perspective is always one of the most prominent – or even the single most prominent – function modelling perspective in the models applied by designers from different disciplines. Therein, similar to function models proposed in literature, mechanical engineering and electrical engineering focus on technical processes, whereas service development focuses on human processes. In software development both 90

Chapter 4: Function Modelling in Practice – An Empirical Study types can be found. Depending on the specific disciplines involved in a development project, the system-level function models address either technical processes (provided by technical sub-systems within or external to the system under consideration) or human processes (provided by stakeholders, such as users or service providers) or both. No model or modelling approach addresses all function modelling perspectives Different combinations of the identified function modelling perspectives are addressed in the models applied in the companies. Looking across all reviewed function models, each function modelling perspectives and each morphology is addressed by at least one function model. This suggests that all modelling perspectives and all morphologies are beneficial to the different practicing designers. Nevertheless, none of the individual function models or their combination in the found function modelling approaches were found to address all of the identified modelling perspectives. This corresponds to the insights obtained from the review of function models proposed in literature (see Section 3.2.9). Eventually, these findings support the earlier discussions in Section 3.3 regarding that integrated function modelling needs to be able to link and combine all modelling perspectives and information about their interrelations (which are conveyed in the modelling morphologies). Effects are considerably less prominent in practice A particular difference to the analysis of the function models proposed in literature presented in Chapter 3, however, is the found wide negligence of the effects perspective. Only one function model applied in the companies addressed effects. A reason for this may be the limited application of classical function models from mechanical engineering or adaptations of them. As these mainly mainly address the effect perspective, while other disciplines tend to neglect it entirely, the number of overall occurrence of effects in the models used in practice is relatively low by nature (see Section 3.2.9). Diversity of function modelling approaches Interviewed designers were found to perform function modelling in a rather flexible manner in their daily work. Modelling steps applied depend on personal preferences, how much can be reused from existing models, as well as the specific progression of the design process. In the two discussed modelling approaches, modelling starts from different entry points and addressed function modelling perspectives are progressing in opposite directions. Both these findings support the general picture of diversity related to function modelling and proposed function modelling approaches, which was already discussed in Chapters 2 and 3. This further supports the initial insights that integrated function modelling needs to be able to represent and integrate the different function modelling perspectives, while at the same time allowing flexible application (see also Section 3.3). 4.3.5

Reasons for not using known function models

Apart from the function models that they use, participants were further asked for any other function models that they know, but do not utilise. If applicable, participants were encouraged to explain the specific reasons for not using a respective model, in order to provide answers to the fourth research question (see Part IV in the question catalogue). A total of 24 participants provided answers to this question. Provided answers referred to either  

specific function models (8 models, referred to by 11 participants) or to general types of function models (16 participants). 91

Regarding the latter, participants would refer to function models in a generalised way, for instance, by saying “such models like the one from VDI 2221”. Six participants could not recall a particular reference and more generally talked about function models “from mechanical engineering literature” or “systems engineering literature”, for instance. Expressed reasons The reasons that the participants provided for not applying a specific function model or types of function models, respectively, can be distinguished in two groups: 



Group 1: Function model not considered useful - model considered to be too abstract, - model not considered to provide benefit, - solution concept is already known, - lack of time. Group 2: Function model considered less suitable compared to others - specific function model considered more complex than required, - another – already used – function model is considered better suited.

Table 4-7 collocates the referenced function models included in the analysis with the specific reasons expressed by participants. In addition, Figure 4-9 consolidates the findings with regard to whether the driving reasons provided by participants from the individual disciplines belong to Group 1 or 2. Group 1 The specific reasons comprised in Group 1, in a way, suggest a general, intrinsic reluctance of participants to perform function modelling and multiple of the reasons from Group 1 were often expressed in combination by individual participants. Two designers with a mechanical engineering background, for instance, explained Q2: “Modelling approaches like Pahl and Beitz are too abstract for the ‘normal’ designer. During the operational business you don’t have the time and also usually not the necessity to do it.” Q3: “These models are not used, because the problem is usually essentially known [in the design team] and also the decomposition into sub-systems with their respective central functions. […] That is why one quickly moves to more concrete aspects and – to some extent – skips this abstract level. […] You usually also do not have the time to explore functions and solutions again. […] It is in principle a nice idea but you normally lack time and then you [usually] already have some solution ideas and one does not see an additional benefit in moving back [...]. Also, it can be difficult to abstract from an already known concept.” A potential difficulty with detaching oneself from an already thought-up solution concept was mentioned by four more participants. It seems, this difficulty is closely related to remarks from participants who specifically highlighted that individual function models are “too abstract”. One specific aspect that was criticised in this regard (n=6 participants) is that the function models (in this case classical models from mechanical engineering) often do not directly refer to a targeted solution. Instead, an abstract, solution-neutral description of functions is requested (as discussed in Section 92

Chapter 4: Function Modelling in Practice – An Empirical Study 2.4.2). This is not considered beneficial by the relevant participants, because they regarded it not to be leading towards a solution, but – in fact – to be leading away from it. Table 4-7: Known but not used function models

Individual models

Grafcet Morphological chart

service design system level design mechanical engineering mechanical engineering system level design mechanical engineering electrical engineering software development electrical engineering software development mechanical engineering software development software development

1 1 1 1 2 1

software development service design electrical engineering software development mechanical engineering mechanical engineering system level design system level design system level design mechanical engineering system level design

1 1

x

1

x

H

system level design

2

D

electrical engineering electrical engineering software development

A Petri nets B TRIZ Sequence diagram (UC) User Stories

H D D

Function flow models

J H A

Types of models

B Classical function models from mechanical engineering

J I E F

Systems engineering function models Use case analysis and modelling

Group 1: Function model not considered useful

E

Lack of time

Solution concept already known

x

x

x x x x x

x x

1

x

1

x

1 1 1

x

1 1 1 1 1 1 2

x x

x x x

x x

x x x x x

x x

x x x

x x x x

x x

x x x

x

x

1

x

x

2

x

x

mechanical engineering (n = 5) 5

Group 2: Function model considered less suitable compared to others 0%

x

Already used function model considered better

H E A B C H

Function model considered more complex than

Finite state machines "Function database"

Model not considered to provide benefit

Company/ disciplines

Model considered to be too abstract

Expressed reasons Group 1 Group 2

applies driving aspect may apply does not apply

Σ participants addressing a model

Legend: x grey cell (x) empty

1

7

6

1

electrical and/or software development (n = 7) service design (n = 1)

2

System level design (n = 9) 20%

40%

60%

80%

100%

Figure 4-9: Driving reasons (from Group 1 or 2) provided by participants from different discipline 93

Group 2 In contrast to Group 1, reasons and arguments comprised in Group 2 suggest some sort of more or less explicit, conscious decision-making process of the participants for or against a specific function model. For instance, two designers typically involved in electrical engineering and software development explained in relation to petri nets that (Q4) “[for] the cyclic machining processes in a [Programmable Logic Controller], sequential models and representations […] are simply much closer to the concrete implementation. Something like [petri nets] does not lend itself so much in this regard.” Both participants typically use Grafcet (see Figure 4-5). Similar explanations were provided by another participant regarding finite state machines (see Table 4-7). Participants who explained, not to be using a specific function model because of the expected modelling efforts and complexity were usually primarily interested in a general overview of the expected functionality with a limited level of detail. They mainly preferred brief (hierarchical) lists (n=2 participants) or simple flow models (n=4) over other function models they knew. Discussion Mechanical engineering function models often considered too abstract One aspect suggested in the findings is exceptionally striking: twelve out of the 13 participants, whose driving reasons against utilisation of specific function models belong to Group 1, are either currently working in (n=5) or were originally educated in mechanical engineering (n=7). Eleven of these participants explicitly referred to classical mechanical engineering function models as known but not used. The last participant in this group is a senior software designer. The software development process portrayed by this person mainly covers incremental adaptation of the existing software code with limited conceptual changes. The person explained thus not to require the function flow models that he knew about. All 13 participants from the first group explained that to them function modelling seems to be a “detour”, which diverts from an already existing idea of a potential solution. Similar experiences are discussed by Blessing and Upton (1997, see Section 2.5.3). Potential benefits from exploring the solution space in more detail by detaching oneself from a pre-defined solution were not recognised or it was considered to be impractical due to the shortage of time in typical design projects. In fact, abstract (and particularly solution-neutral) function modelling is rejected by the majority of participants with a background in mechanical engineering and function models proposed in classical mechanical engineering literature are rarely applied (see Section 4.3.3). This supports the earlier discussed impressions that these sorts of models are of limited relevance for the participants’ practical design work. Expected benefit of specific function models differ The expressed reasons belonging to Group 2 suggest a more or less explicit decision process against a rejected function model. Nevertheless, models rejected by some participants are still considered beneficial by other designers. For instance, finite state machines, morphological charts or use case modelling, which are rejected by some of the participants (see Table 4-7), are nevertheless applied and considered beneficial by participants in other companies or – in one case – even in the same company 94

Chapter 4: Function Modelling in Practice – An Empirical Study (see Table 4-4). Depending on the individual designers and/or the context of function modelling in the design process, specific models (with different contents and morphology) thus may or may not be advantageous or preferred by individual designers. Integrated, cross-disciplinary function modelling should be respective of such diverging preferences, in order to address the demands of individual designers and different design contexts. 4.3.6

Experiences made while introducing a new function model or modelling approach

Research Question 5 is addressed by consolidating the answers provided by the participants in relation to those questions in Part IV in the catalogue that focus on the introduction of new function models in a company. Six of the visited companies had newly introduced a specific function model (n=4) or entire modelling approaches (i.e. a set of associated function models, n=2) preceding this study. A total of twelve participants provided information about the particular experiences made during this introduction. Participants were encouraged to describe the specific initial situation that motivated the introduction of a new function model, as well as eventual changes achieved through the introduction. From the participants’ descriptions, essentially three different cases can be distinguished in relation to the specific motivation for introducing a new function model or modelling approach:   

Case 1: Supporting joint exploration of potential solutions Case 2: Supporting exploration/specification of system context and required functionality Case 3: Building a shared reference model

In all three cases, introduction of new function models had been lanced by system-level design, electrical engineering and/or software development departments, respectively. Table 4-8 to Table 4-10 collocate the specific motivations, experiences made, and eventual changes resulting from introducing the new function models and modelling approaches in the respective companies. Case 1 In Case 1, introduction of morphological charts was employed. The intention in the two related companies had been to introduce a model, based on which different designers would be able to discuss alternative solution concepts for a few selected functions in the system to be developed more easily. Table 4-8: Case 1 – Supporting joint exploration of potential solutions Companies:

C (2 participants), I (1 participant)

Introduced model

In both companies the concept of morphological charts was applied (on level 3) to a few central functions of selected sub-systems.

Motivation

In both companies, no function model shared across disciplines (neither on level 3 nor 4) had been used before. The aim of the introduction had been to  establish a more systematic approach in conceptual design, in order to  facilitate joint exploration of alternative specific solution concepts for selected sub-systems by bringing together designers from different disciplines for discussions.

Experiences made during model introduction

In both cases, applying the concept of morphological charts in principle seemed to work well, however: Company C: The design team seemed to experience some difficulties in applying the method, particularly regarding the decomposition of functions. Company I: Designers (particularly mechanical engineers) seemed to consider the more systematic conceptual design approach to be impractical and in some cases unnecessary; changing their mind-set towards abstraction of functions from an existing idea for a solution was experienced particularly challenging.

Impacts of model introduction

Company C: Introduction of the modelling approach was considered beneficial in principal, however for future application, more training was considered necessary, in order to exploit the full potential. Company I: Despite the initial reservations of individual designers against the modelling approach, conceptual design was indeed considered to have become – to some extent – more systematic.

95

The involved participants did not describe to have experienced difficulties with applying the basic matrix representation, but rather with the required abstraction from existing solution ideas and concepts to more abstract, function-oriented considerations. A strategic designer, for instance, explained: “designers want to design” and thus typically prefer to quickly move towards a potential solution, rather than going into detailed function modelling. This particularly seemed to apply to mechanical engineers. An impact on cross-disciplinary collaboration was not be found in this case. Case 2 All three participants in Case 2 specifically highlighted one particular benefit resulting from the introduction of use case modelling: the significant increase in the comprehension of the system context. Table 4-9: Case 2 – Supporting exploration of system context and required functionality Companies

D (2 participants); H (1 participant)

Modelling approach

In Company D textual use case descriptions in combination with use case flow models were introduced in software development (level 2). In Company H use case schematics were introduced by the systems engineer and are occasionally shared across disciplines (level 3)

Motivation

In Company D, before the introduction of use case modelling, software designers mainly relied on the requirements specification and different flow charts. These were expressed to be missing relevant context information (e.g. users, peripheral technical systems, etc.) and thus to be hampering the establishment of an overall view on the system. Use case modelling was introduced, in order to  explore and make explicit context-related information;  aggregate relevant information in one model, to be used by all software developers;  establish a more systematic approach in conceptual design. Company H changed from being mainly a developer and manufacturer of mechatronic systems as commissioned by a customer, towards providing services with the developed systems (see also Appendix D.II) For the development of the first such system, a new model was sought, to  explore the new system context (particularly regarding users and service support systems) resulting from the inclusion of services, i.e. identify different users, peripheral technical systems, and analyse their interactions with the system to be developed;  derive and specify expected functions of the system to be developed, including any new, service-related functionality.

Experiences made during model introduction

Impacts of model introduction

Company D: The design team seemed to experience some difficulties in applying the modelling approach in the beginning, which seemed to originate from getting acquainted with the used software tool; however, application was described to have improved quickly due to growing experience. Company H: Learning and getting started with employing use case schematics was described to work very quickly; no considerable difficulties seemed to occur while getting operable with the model. Company D  The modelling approach was expressed to have improved comprehension of the system context, significantly;  to have introduced a more systematic and more traceable development process in the transition from the requirements towards the solution,  to support the development of test cases for the developed software, as these can be quickly deduced from the developed flow models;  to facilitate communication between globally distributed design teams as the shared understanding of the system was expressed to have been increased substantially and at the same time, generated models serve as a means guiding the discussions. Company H  Introduction of the model was expressed to have helped considerably with understanding and analysing the new, service-related aspects of system functionality;  it is considered a valuable basis for specification of requirements and functions of involved sub-systems to be developed.

The achieved increase in system comprehension includes the comprehension of the associated users, surrounding technical systems, and the specific interactions among them as well as with the system under development. In case of Company H, this was considered particularly beneficial as the model helped the interviewed systems engineer to derive an understanding of the new required functionality and system context introduced by changing towards a more service-oriented business model. While 96

Chapter 4: Function Modelling in Practice – An Empirical Study the main functions of the developed mechatronic system did not change tremendously, it was particularly the users and how they would interact with the system, which required additional technical means and functions to be integrated into the technical product. Apart from the increased understanding of the system context, another benefit highlighted in Company D was the significantly improved communication between colleagues in globally distributed teams. What used to take a vast amount of phone calls and emails, was described to work much more effectively now. The responsible strategic manager emphasised that this – in his opinion – is a direct result from the increased comprehension of the system and its context. In addition, the conceptual design process was considered more systematic, also due to the specific sequence of modelling steps provided along with the respective partial models (see also Appendix D.III). Case 3 Supporting introduction In both companies in Case 3, the development of the respective modelling approaches had to go through several iterations. Initially investigated function models from mechanical engineering literature (in Company F) were considered too formalised and restrictive to support flexible, practical design work. Both companies thus decided to develop their own function models. However, earlier versions were still considered too abstract, which led to iterations in the development process. In addition, specific training was developed, in order to guide and support individual designers in applying the function models. Still, considerable time was required for the designers to become acquainted with the new models. Establishing traceability A specific goal had been the establishment of traceability between functions and solution elements (i.e. the different involved sub-systems). Therein, the concept of traceability includes: 



top-down traceability, which essentially addresses a consistent and reproducible documentation of the allocation from the requirements over required functions to the specific solution elements (function carriers, e.g. different sub-systems to be developed) that – either alone or in combination with others – are actively or passively contributing to function and requirements fulfilment; bottom-up traceability, which essentially addresses the consistent specification of the interactions between solution elements, in order to establish the possibility to trace back, in which way eventual changes made to one solution element will affect other interfacing solution elements, but also, eventual effects on fulfilment of functions and requirements that the respective solution element(s) is/are contributing to.

As described in Section 4.3.3, traceability is considered a key element in facilitating system comprehension, which supports communication between designers. In addition, consistency between the specifications – and eventually the designs – of interfacing sub-systems was described to have improved significantly. Also, the possibilities to reuse existing data from former development projects was described to have improved. A strategic manager from one company claimed that – because of these improvements – consumed development time for some highly interdisciplinary sub-systems could be reduced by up to 30% and, at the same time, design errors were reduced as well.

97

Table 4-10: Case 3 – Building a shared reference model Companies

E (2 participants), F (4 participants)

Modelling approach

In both companies in-house developed function models were introduced: “Function database” in Company E (on level 3) and “System Function Specification” in Company F (on level 4). Both modelling approaches link functions to involved sub-systems, such as modules, components, etc.

Motivation

In both companies system development used to rely mainly on separate requirements specifications for the sub-systems to be developed by the different (often mono-disciplinary) design teams or by sub-contractors. Changes made within one of these documents, which would affect interfacing sub-systems, were often not or only inconsistently updated in other specifications. Also, designers were not always aware of dependencies between sub-systems. As a consequence, in some cases assemblies would malfunction, as interfaces between sub-systems were inconsistent. In a few cases, this was not discovered, as testing focused on the specific sub-systems, which functioned exactly as they were specified. In both companies, cross-disciplinary function modelling was introduced to address these issues. Essentially, the specific goals had been  to introduce a shared reference model addressing system functions across disciplines (in Company F across all disciplines, in Company E across electrical design and software development), from which the requirements specifications for involved sub-systems can be consistently derived;  to standardise and support traceability from requirements and expected functions to associated solution elements (“top-down”) and vice-versa (“bottom-up”).

Experiences made during model introduction

In both companies experiences made during the introduction were quite similar:  development and introduction of the modelling approach in-house had to go through a few iterations; earlier versions were regarded too abstract and formalised by practitioners; as a consequence, models were adapted and complemented with guidelines and training to support designers in applying them;  acceptance in electrical design and software development seemed generally high;  however, across disciplines, several designers seemed reluctant to use the models, in order to document “things they already knew” or “that they had already written down somewhere else”; however, acceptance of the modelling approaches was described to increase drastically the more complex a system under development is and the less previous knowledge about it exists. In Company F, in addition, experiences made with mechanical engineers could be collected: numerous mechanical engineers had been reluctant to use function modelling in general, as it seemed difficult for them to detach themselves from an already known solution concept and take a more abstract view on the system (see also Section 4.3.5).

Impacts of model introduction

In both companies, utilisation of the respective function modelling approaches was described to have become “business as usual”. Introduction of the respective modelling approaches was expressed to have been highly valuable and to have significantly improved upon  communication and collaboration through increasing the shared understanding of the system to be developed, that includes awareness of dependencies between sub-systems and simply by knowing “who to talk to”;  the design process by systematising development steps and decreasing development time;  the design through reducing inconsistencies between sub-systems, facilitate system testing, and by being more easily able to trace back the reasons for malfunctioning.

Difficulties with formulations of functions In both companies, the communication with the respectively developed function models seemed regularly hampered by difficulties with miscomprehension of formulations of functions (see also Section 4.3.3). The difficulties were regarded to originate from the fact that individual designers have their own personal preferences and vocabulary in describing functions and technical facts. In order to address this issue, rather formalised approaches for function formulation, somewhat similar to function taxonomies (see Section 2.5.1) had been introduced in one company. These were described to be widely rejected by the designers for being far too abstract and thus impractical. In fact, designers exclaimed that formulations were now even less comprehendible than what they used before. In both companies, the issue was independently addressed in a similar manner. For one, a definition of function was introduced for all designers from the related company to use: “(intended or already perceivable) behaviour of a system”. In addition, designers are asked to formulate functions, as if the particular behaviour was perceived from a specific viewpoint: the viewpoint of a person that looks upon or experiences the behaviour that the system exhibits. To give an example, the function of an automatic door, would be formulated as “door opens when a person is approaching”. In addition, the 98

Chapter 4: Function Modelling in Practice – An Empirical Study designers were provided with guidelines and training. Participants from both companies claimed that these measures finally had helped reducing difficulties with miscomprehensions. Discussion Shared function modelling supports interdisciplinary conceptual design The findings suggest that function modelling could provide the respective companies with considerable support for the conceptual design stage. That includes the systematisation and consolidation of design and modelling activities. The findings further suggest a particularly strong potential of function modelling to support collaboration among involved designers, i.e. the exchange of expertise within and across disciplines. The achieved improvements in (cross-disciplinary) collaboration and communication seem to a large degree originating from an increased comprehension of the system, its context (see Case 2), and in particular, the establishment of traceability between functions and solution elements (see Case 3). The clear allocation between functions and solution elements as well as representation of the specific dependencies among them was described to support the comprehension of the overall system across involved disciplines. A thorough understanding of the system, its context, and internal dependencies, in turn, was described to have resulted in an improved (cross-disciplinary) communication in the respective companies (see Section 4.3.3). These findings strongly support the initial assumption that function modelling can establish a shared understanding among collaborating designers, which facilitates (cross-disciplinary) collaboration (see Section 1.2). Function taxonomies are rejected The experiences made during introduction of the function modelling approaches in Case 3 support findings by Ahmed and Wallace (2003) and van Eck (2010), which were discussed in Section 2.5.1. Highly formalised approaches for formulating functions, such as function taxonomies, do not seem to provide a support for practicing designers. In fact, the described experiences suggest that such approaches may introduce even more problems, which is why they had been rejected by the designers in the companies. The imposed measures in Companies E and F to some extent can be regarded to compromise between widely unrestricted and highly formalised formulations. 4.3.7

Preferred representation

Part V in the interview catalogue aimed at exploring the personal preferences of involved participants regarding the representation of functions (Research Question 6). Participants were asked the question: “What kind of representation or visualisation of functions do you personally prefer?” A total of 26 participants provided answers to the question. Seven participants did not refer to a specific type of representation, but resorted to naming specific models that they personally prefer to use. Five answers could not be evaluated and were excluded from the analysis. Seven participants referred to two (n=5) or more (n=2) ways of representing functions. Three participants explained not to have a specific preference, while two more participants explicitly asked not to be limited to one specific type of representation. Instead, they expressed the desire to be able to flexibly choose between different types of representations or to combine them when considered useful. The two participants explained: Q5: ”This has to be done in a flexible way […] without too [many] tools involved. Why? Because, if you use [specific modelling tools] […] you have to speak in one language, 99

the language of the tool. […] But if you use paper, for instance, you can use whatever you want and even mix.” Q6: ”Do I have to choose one? It is mostly strongly dependent on what you want to do. Often it makes sense to combine different things.” From the answers provided by the remaining 21 participants, five types of representations of function can be distinguished (see Figure 4-10): time flow-related representations, (hierarchical) lists, brief textual descriptions, matrices, and block diagrams. Time flow-related representations include e.g. sequence diagrams, flow charts, Gantt charts, etc. Brief textual descriptions cover concise statements and explanations using lists. Block diagrams refers to block representations using input/output relations (similar to Figure 1-1 or Figure 4-2, for instance). No connection was found between individual preferences and the specific discipline a person is involved in. 0

1

2

3

4

5

6

7

8

9

10

Time flow-related representations (Hierarchical) lists Brief textual description Matrices Block diagrams No specific preference

Figure 4-10: Preferred representation of functions (n=21) Discussion The findings support the predominance of time flow-oriented representations of functions, which was already suggested in the analysis of the function models that are currently used in the companies (see Section 4.3.4). Such representations may thus reasonably be used as a starting point or basis, respectively, in the development of an integrated function modelling approach. However, linking other kinds of representations may provide an additional benefit for individual designers. Being able to select and combine whatever is considered best suited in a specific situation was considered a valuable asset. Start modelling on paper was further expressed as a benefit, particularly during the early design stages. 4.3.8

Considered support

In order to answer Research Question 7, participants were asked for the specific support they needed or would consider useful in (interdisciplinary) function modelling (Part V in the question catalogue). All 35 participants provided answers to this question. Three answers could not be evaluated and were excluded. Seven participants expressed no need for a specific support. The remaining answers suggest several desired supporting measures, both regarding the improvement of current function modelling practices in the companies, as well as to facilitate interdisciplinary function modelling (further) in the future. The desired support can essentially be distinguished in three groups: 1. Foster comprehensiveness of function modelling: a) introduction of an overall function model including all disciplines, b) establish top-down traceability and 100

Chapter 4: Function Modelling in Practice – An Empirical Study c) bottom-up traceability between functions and solution elements, d) linking function models with models from later design stages; 2. Improve consistency of modelled content: a) support consistency of contents across different models, b) improve completeness of the generated function models; 3. Managing modelling efforts a) support determining the adequate level of detail in function modelling, b) support delimitating the modelling scope. The distribution of which specific support was considered useful by designers in different companies is provided in Figure 4-11. Therein, participants are differentiated between whether they come from a company already using cross-disciplinary function modelling or not. The former group is further differentiated into participants from companies already using a function model shared between all disciplines (level 4 of participation) or shared between selected disciplines (level 3) only. The latter group comprises the participants that come from companies that do not use cross-disciplinary function models (level 2 or level 1) or, in one company (Company G), no function models of any sort. 1.a): Two companies already have introduced a function model shared across all involved disciplines (level 4). Participants from four more companies (currently using level 2 and 3 function modelling) specifically expressed the desire to introduce such a generally shared function model as well. The expressed reasons include   

supporting systematisation of the design process, facilitating a more thorough exploration of the solution space, and furthering integration of different disciplines in the early design stages.

The participants from Company G expressed a general desire to introduce some kind of modelling approach to systematise their design and service processes (see also Appendix D.II). In three companies currently using level 3 function modelling, no desire for further integration of function modelling was expressed. Participants seemed content with the current practices. 1.b) and c): The demand for supporting comprehensiveness in function modelling was articulated several times. It particularly includes the issue of traceability between functions and solution elements. As described before, three companies had already taken up related measures. In one of these (Company E), the inclusion of mechanical engineering (currently not using function modelling) was desired for the future, in order to realise full traceability: Q7: ”What we are currently trying to achieve is [to establish an overall function model] including mechanical engineering along with the [electrical engineering and software development] parts, so that I end up with a continuous documentation of the top-level [system functions] – including mechanics and [electronics and software] – down to the product architecture to every sub-function in every component, so that I […] can, on the one hand, properly control the implementation of functions top-down – thus I can avoid implementation of redundant functionalities, [as] I can distribute functions efficiently onto distinct components – but, on the other hand, so that I also have the possibility

101

[bottom-up] to trace back which [system functions] will be affected, [if] I have some kind of change in any [of the] components.” Participants (n=4) from two companies (Company E and Company H) independently referred to matrix representations as one promising option for making relations between functions and solution elements explicit. At the time of the study, initial attempts for such a matrix-based allocation model had already been investigated in Company E (as discussed in Section 4.3.1) and were already used in another company. One specific difficulty Company E was struggling with in this regard, is clearly defining the relations between sub-functions. So far, the company mainly uses hierarchical representations of functions. However, in some cases, these hierarchies were experienced to be casedependent. To give a fictive example, while driving, the battery of a car provides a current for the ignition plug in a standard petrol engine. “Providing current” here serves as a sub-function of driving. In contrast, for giving another car a jump start, “providing current” serves as one of the main functions. Different options for adequately illustrating such case-dependencies in the hierarchical relations of functions were being evaluated in the company at the time of the study.

2. Improve consistency 3. Managing modelling of modelled content effort

3.a)

a) Introduction of a function model including all disciplines 2.b)

b) Establish top-down traceability 2.a) traceability c) Establish bottom-up

d) Linking function models with models from later design stages 1. Foster comprehensiveness of function modelling

2. Improve 3. Managing consistency modelling of modelled effort content

1. Foster comprehensiveness of function modelling

1.d): Closely related to the issue of traceability is the demand for linking function modelling with design models from later design stages, such as, for instance, CAD modelling and behaviour simulation. This was explicitly demanded in one company already using system-level function modelling. Expressed reasons are essentially twofold: on the one hand to advance traceability between functions and solutions into even later design stages; on the other hand, in order to facilitate comparison and validation of selected and designed solution elements with respect to requirements and function 3.b) fulfilment.

1.d)

a) Improve completeness of the generated function models 1.c)

b) Support consistency of contents across different models a) Support determining the adequate level of detail 1. b) in function modelling b) Support delimitating the modelling scope 1.a) 0

1

02

13

24

3

1. Foster comprehensiveness of function modelling

No cross-disciplinary function modelling used (n=6) Cross-disciplinary function modelling limited to level 3 (n=16) Cross-disciplinary function modelling adcanced to level 4 (n=10)

1.a) 4 5 0

1. b) 0 3 0

1.c) 0 3 3

1.d) 0 0 2

5

4

6

5

7

6

8

7

98

9 10

2. Improve consistency of 3. Managing modelled modelling effort content 2.a) 2.b) 3.a) 3.b) 3 0 1 0 3 2 3 1 1 3 0 2

Figure 4-11: Support considered useful in different companies 2: Another formulated concern is the issue of consistency of contents shared between associated function models. Shared contents that are changed in one model need to be updated in associated 102

Chapter 4: Function Modelling in Practice – An Empirical Study models as well. As, e.g., described in Section 4.3.6, failure to do so can cause design errors. A support for ensuring that changed information is updated across associated models was considered highly valuable. A related issue is the completeness of function models, particularly regarding the issue of missing information. This mainly refers to inconsistencies e.g. in the logical sequence of functions, i.e. missing steps in a function flow. 3: Various participants expressed a desire to be able to manage or even reduce the time spent for function modelling. This includes delimitating the specific scope for modelling, i.e. selecting a-priori, which specific contents should be modelled and which may be left out, if not required in a specific design project. Similarly, a support for selecting the adequate level of detail was desired, in order to avoid spending more time on modelling than required, but still to provide enough detail for the generated function model to provide value to the users. Discussion Desire for shared function modelling The findings suggest that cross-disciplinary function modelling is generally widely desired in the visited companies. Out of the ten companies, six either already have introduced function modelling including all involved disciplines (n=2 on system-level) or expressed the desire to do so (n=4). The expressed reasons and motivations correspond by and large with those from the three cases described in Section 4.3.6. The experiences from these cases suggest that the specific benefits expected from introducing shared function modelling (see descriptions of 1.d) in the previous section) can indeed be addressed. Three companies did not express a desire for further integration of disciplines in function modelling. In all three companies (Companies A, B, and J), discipline-specific design is performed either sequentially or partly sequentially (see Table 4-2). One potential explanation why the related participants did not ask for further support regarding interdisciplinary function modelling could thus be that consecutively involved disciplines can make use the already generated product models from the disciplines working prior to them in the overall design process. Because such concrete information is already available to them, the need to share abstract function models between the disciplines is not as large. Traceability through matrices It seems, in particular the aspect of (top-down and bottom-up) traceability is or had been one of the key motivations for those three companies that have already taken steps towards shared function modelling. All three companies – independently from each other – are either using (Company F), currently evaluating (Company E) or are considering (Company H) matrices or similar representations for this particular purpose. Experiences made with matrices in Company F are strongly positive. The same was expressed regarding the initial insights from Company E on the on-going evaluation of matrices. Although matrices were not among the most preferred types of representation for functions (see Section 4.3.7), this suggests, they may provide adequate means for the representation of the links between functions and solutions, i.e. means for supporting traceability. Consistency in function modelling should be supported The findings further suggest a considerable desire for the support of consistency of modelled information. This seems particularly important with respect to change management in separately used 103

function models. Inconsistencies between models may lead to design errors, as already experienced by some of the visited companies (see Section 4.3.6). Although Company F claims to have improved consistency substantially through the introduction of a function model on system level, participants still expressed a need for further support. A potential explanation for these problems could be the separation between the different models. System-level function models (if available), derived sub-system specifications, and function models on level 2 and 3 of participation are currently widely disconnected in all the companies. Changes made to single models, therefore, have to be separately communicated to other designers each time. This disconnectedness of the models poses a risk, as some changes may be forgotten and not communicated (properly) to other designers (which was also the case, for instance, in the company from the described example in Section 1.1). Enable managing modelling scope and required effort The shortage of time in a typical design project requires the designers to work efficiently. Being able to focus on what is really needed in a design project is considered a large benefit and ought to be supported. At the same time, completeness and consistency of modelled information needs to be maintained, which may increase the time needed for modelling. In practice, it seems hardly possible to apprehend a-priori which specific information or level of detail will be required in a design project. However, facilitating reuse of contents from existing models and allowing for flexible adaptation with respect to which contents are included or omitted in a design project, may support managing and delimitating modelling efforts in an integrated function model in general. 4.3.9

Addressed notions of function

Research Question 8 is intended to explore different notions of function addressed by the designers in practice. To answer this research questions, all participants were asked the question: “What is your understanding of function?” A total of 33 participants provided answers to this question. The provided answers are largely variant, both in terms of contents as well as with respect to the way the participants explained their personal understanding of function. This is described in the following. Variances in explaining function The provided answers range from rather formal definitions of function (n=11 participants) to answers provided by participants who resorted to using examples of what was regarded to be a typical function (n=4). Most participants provided informal definitions (n=18), wherein the understanding of function was circumscribed. Table 4-11 presents a few examples of formal and informal definitions provided by the participants. From the total of 33 participants, ten seemed to have difficulties in trying to provide an answer to the posed question. Such difficulties manifested themselves, for instance, in the fact that some interviewees noticeably struggled to find the right words. Three participants explicitly said that they had difficulties answering the question. Expressed reasons for the difficulties include that participants claimed function was a fixed term to them (n=2), which makes it difficult to find adequate synonyms. Another participant claimed that function can have different meanings depending on the specific context it is used in, which made it difficult for him to provide a definition. 104

Chapter 4: Function Modelling in Practice – An Empirical Study Table 4-11: Examples of provided formal and informal definitions Type

Example Q8: “A function is the specification of an either expected or already existing behaviour of a quantity greater than zero of components. Therein – ultimately, from my point of view – technical components can be both hardware or software.”

formal definitions of function

Q9: “We have [main product] functions, which are defined as a [specific behaviour of the product] from a helicopter or management point of view and are intended to split up the [product] into its functional parts. […] These [main product] functions can be further subdivided or partitioned, respectively, into sub-functions. These sub-functions that is what we call “virtual functions”. So [main product] functions are decomposed into an amount of virtual functions. Beneath these virtual functions there is another layer of “real functions”, which can be 1 till n. And these real functions implement the virtual functions [in the associated components]. The sum of all real functions should thus lead to an executable [main product] function.” Q10: “Function is an essential property that the product is supposed to possess and that needs to be realised through a technical solution.“

informal definitions of function

Q11: “[A] function has different parameters as input […] and gives out some kind of value as result or changes [an] internal state.“ Q12 “A function is […] a specification of what the [product] is intended to do.”

Notions of function addressed by the participants All provided answers were analysed and evaluated with respect to addressed themes and concepts, in order to identify different notions of function addressed by the participants. Overall, nine different notions of function could be identified (see Table 4-12). Provided answers frequently addressed multiple notions of function (n=11 participants). Therein, four notions are particularly prominent and were addressed by numerous participants, while the remaining five notions were addressed by only one participant each. No discipline-specific accumulation of the different notions of function could be found. Each of the four central notions was addressed by participants across disciplines. Table 4-12: Notions of function addressed in the interviews

Prominent notions of function:

Function as related to  purpose  the capability to show behaviour  an input/output relation (including an associated state change)  behaviour in general or as differentiated into intended behaviour perceivable behaviour

Other:

    

the capability to cause an effect the amount of selectable options for a system a requirement, which can be evaluated against a certain criteria an essential property of a system, which is related to its purpose features of the system that deliver value.

Overall, a majority of 20 participants described an understanding of function directly related to the notion of behaviour (see Figure 4-12), which includes the notions of intended behaviour and perceivable behaviour. However, most participants (n=12) did not differentiate between the two and

105

addressed behaviour in general (n=9) or addressed both intended and perceivable behaviour alike (n=3, see e.g. Q8 in Table 4-11). Six participants explicitly differentiated between alternative meanings of the term function. The differentiation was employed in relation to  

hierarchical levels related to the system (n=3), as well as whether the concerned system is already existing or not (n=3).

Regarding the former, participants differentiated between ”high-level” and “low-level“ functions. For high-level functions the notions of purpose (n=2) or intended behaviour (n=1) were used, respectively. For low-level functions the notions of input/output relation (n=2) or capabilities to show behaviour (n=1) were addressed, respectively. Regarding the latter, in Q9, for instance, functions are divided into “virtual” and “real” functions. Virtual functions refer to intended behaviour; real functions refer to perceivable behaviour. A similar differentiation was conveyed in the answers from two more participants. This case-dependency of the notion of function addressed by these six participants is indicated in Figure 4-12 by using different colours: red refers to notions of function which were case-independently addressed; green refers to those, which are case-dependently addressed by the participants. 3

Purpose (n= 5)

2 4

Capability to show behaviour (n= 5)

1 4

Behaviour (total=20)

Input/ Output relation (n=6)

2 4

Perceivable behaviour (n=6)

2 6

Intended behaviour (n=8)

2 8

in general (n=9)

1 0

1

2

3

Case-indenpendently addressed

4

5

6

7

8

9

Case-dependently addressed

Figure 4-12: Notions of function addressed in the provided answers from the participants Two companies had introduced a shared formal definition of function prior to this study (as briefly discussed in Section 4.3.6). All provided answers from participants within one of these companies (n=7) corresponded to the respectively introduced definitions; however, not necessarily using the same formulation. In all other companies more variance was found. Attributes associated to the notions of function Apart from what are considered different notions of functions by the researcher, the provided answers frequently conveyed further attributes that the participants associated to function. These include: 

Pre-conditions (n=2) – two participants defined function in relation to a specific behaviour of the system, which is executed only in case a specific pre-condition is fulfilled. For instance, in a manufacturing machine, a hole can only be drilled if the metal sheet is ‘in position’.

106

Chapter 4: Function Modelling in Practice – An Empirical Study 



Solution-neutral formulation (n=3) – participants complemented the provided definition of function with the demand that functions need to be formulated in a way which does not already suggest their potential implementation; thereby, the designers are expected not to become fixated on a specific solution early in the process. Constraints (n=6) – participants described function as bound to specific target values or constraints for their fulfilment, e.g. referring to the capability of a system to show a specific behaviour in a specific time or perform within a specific accuracy (or similar constraints). As discussed in Sections 3.1.2 and 4.3.4, this information is occasionally also explicitly included in function modelling.

Discussion Different notions of function exist side-by-side in design practice The presented findings suggest that function as an abstract concept is difficult for many designers to grasp and to explain their personal understanding of it. Despite the found variance in provided answers, four of the identified notions of function are particularly prominent irrespective of disciplines that the participants are associated to: function as related to purpose, capacity to show behaviour, input/out relation, and behaviour. In addition, various interviewees differentiated between different notions of function in relation to the specific context in which it is used. These findings support the insights from the review of literature that different notions of function exist side-by side in design (as already discussed in Section 2.6). The four central notions of function found in this study by and large correspond to the archetypical notions of function derived from Vermaas (2011, 2013a, see Section 2.3.2). Other notions of function, which were addressed by only a single participant, may be specific to the respective person’s field of work. For instance, the notion of function as related to the amount of selectable options for a system (see Table 4-12) was expressed by a product manager, who has to decide which (new) functions will be implemented in a system to be developed and which will not. The notion of function as features of the system that deliver value was addressed by a service designer, who is mainly involved with value analysis related to total cost of ownership for the machines that the offered services are associated to. Behaviour is a central notion of function across disciplines The notion of function as related to behaviour was found to be the most central. Intended behaviour was repeatedly related to the prospective behaviour of a not yet existing system by the participants, whereas perceivable behaviour was addressed in relation to the actual, measurable behaviour of an existing system. Although only few participants explicitly made this differentiation, the comparison of the concrete perceivable behaviour of a system with the before-specified functions was frequently referenced as the key criteria for verification of function fulfilment in a system. The notion of function as related to capability to show behaviour is strongly related to this (implicit or explicit) comparison between what is required or expected from the system and what it is capable of doing (i.e. its actual behaviour). The notion of function as input/output relation is similarly directly related to the behaviour of system, though providing a more abstract point of view on it (as already discussed in Section 2.3.1, see also Figure 2-4).

107

In light of these considerations, it can be derived that 27 out of the total of 33 participants addressed notions of function which are directly related to behaviour of the system. Because of this striking centrality in the collected answers, the notion of function as the behaviour of a system may be suitable for establishing a common basis for the discussions in practice of what function refers to. This does not oppose the idea of different notions of function to exist side-by-side. However, it seems sensible for the discussions and shared reasoning about functions between practicing designers to reference function to the behaviour of a (sub-)system, as most of the practitioners in the interview study already seem to have a similar understanding of function in their minds. Following the discussions in Section 2.3.4 and the fact that five participants in the interview study explicitly referred to the notion of function as related to purpose, function is considered as something that is deliberately designed into the system, in order to serve a designated objective. That means, function can be regarded to centrally address the behaviour that the designers intend the system to have or that an already existing system exhibits, which is intended to fulfil a designated purpose.

4.4 Summary and discussion of the results 4.4.1

Function and function reasoning in the companies

The findings in the conducted interview study support the initially discussed insights regarding the coexistence of different notions of function in system development (see Chapter 2). For many participants, function as an abstract concept is difficult to grasp and may also have alternative meanings to them. Although deviant understandings of function as such were not expressed to be a reason for difficulties in (cross-disciplinary) communication, those companies that introduced a shared definition of function along with guidelines on how to formulate functions in created models and related documents claimed that these measures have helped reducing experienced problems with miscomprehensions (see Section 4.3.6). These insights suggest that for the purpose of modelling and discussing about function using a shared definition may provide a support in design practice. Individual designers may still have different notions of function in their minds (as discussed in Section 2.5.3); however, having one shared definition to reference to during discussions about functions with colleagues may nevertheless provide a support. Based on the derived insights from the interviews, the notion of function as related to the intended or perceivable behaviour of a system in relation to a purpose is considered a suitable base for the discussions about function. In the two companies that introduced a shared definition of function, function was also defined in relation to the behaviour of the system and this definition was described to be suitable, as discussed before. The overall function reasoning process during conceptual design that was found in the companies (see Sections 4.3.2 and 4.3.9) seems to progress iteratively top-down from the intended behaviour of the system under development (see the definition of functional requirements in Section 4.3.2 that was derived from the interviews) to different solution elements. As discussed in Section 4.3.9, the intended behaviour is frequently evaluated against the actual behaviour exhibited by the selected solution elements to verify function fulfilment. A similar pattern can be found in the FBS framework (Gero 1990, see Section 2.4.2). The transition from function to an initial solution concept is typically facilitated by reuse of an existing system structure (as discussed in Section 4.3.2). Overall, conceptual design in practice seems strongly solution-oriented. The large number of in-house developed function models that were found in the different companies, seems to be a direct result of this solution-oriented process. Classical function models from mechanical engineering (requiring solution-neutral modelling), 108

Chapter 4: Function Modelling in Practice – An Empirical Study for instance, seem widely rejected, because they are considered to be too abstract. Mechanical engineers in general were found considerably less often to perform function modelling. 4.4.2

Interdisciplinary function modelling can support collaborative design

Facilitating integration in PSS design The increasing integration of technical products with associated services in different industrial branches, which is discussed in literature, could also be found in three of the participating companies (Companies J, I, and H). This refers to both a more service-oriented business model as well as advanced integration of service development (as a discipline) into the development process of technical products. Company J in particular expected further integration of services with their technical products in the coming product generations. The employed change towards a more service-oriented business model required specific adaption and expansion of the functions of the technical product. Apart from adapting the respective requirements specifications accordingly, this was facilitated by function modelling, in Company J, but most notably in Company H. The used function models were described to have substantially helped determining the new required technologies, resources, and in particular the new or adapted functions of the developed technical product (see Section 4.3.6). These experiences suggest a large potential for function modelling to facilitate the integration of technical product development with service design. Supporting the exchange of information The findings substantiate that miscomprehension between individual designers in the early stages can lead to design errors and thus may result in iterations in system development or even to problems during their use. Shared function modelling (within and across different disciplines) may provide a substantial support to address this issue, as particularly highlighted by the experiences made in three companies from Cases 2 and 3 in Section 4.3.6 (see also Section 4.3.3). The achieved improvements from introducing new function models in these companies may be seen as a direct result from the reduction of inconsistencies between discipline-specific sub-systems, systematisation of the design process, improving system comprehension, and enhancing collaboration between designers within and across different disciplines. Introduction of a shared function model cannot be seen as a guarantee for the improvement of crossdisciplinary collaboration. Even within Company F, which can be considered the most advanced in establishing system-level function modelling and traceability in conceptual design, the achieved improvements varied strongly between sub-systems. However, the achieved improvements for selected, highly interdisciplinary sub-systems are a strong indicator for the large potential of an adequate function modelling approach to improve interdisciplinary design in the early stages of system development. The reduction of up to 30% in development time in one of the companies is particularly notable. It seems, the main contribution regarding improvement of (cross-disciplinary) communication between designers results from an increased comprehension of the system, its functions, and context. The findings, hence, strongly support the initial assumption in this thesis that shared function modelling can indeed support the establishment of a shared understanding among involved designers and facilitate integration and collaboration between disciplines. The suggested benefit seems particularly high in large, distributed design teams that are working in parallel. Companies primarily working sequentially did not express a similar demand for shared, interdisciplinary function modelling. 109

However, providing these companies with an adequate function modelling approach may nevertheless trigger collaborative modelling involving all disciplines. 4.4.3

Further integration is expedient

The function models used on system-level and the function models used within (or between selected) disciplines, so far, are widely disconnected from each other. This separation is considered one of the main reasons for inconsistencies in their contents, which resulted in design errors and iterations in the design process. In addition, all reviewed system-level function models merely address a limited set of function modelling perspectives, mainly focusing on central transformation processes (see Section 4.3.4). Separate function models are used within the involved disciplines, such as e.g. finite state machines, function flow charts, and use case modelling. This suggests that further perspectives are defacto required for the individual designers from involved disciplines. In order to facilitate integration and support consistency in function modelling, an integrated function modelling approach thus ought to be able to allow interlinked function modelling from system-level to sub-system level, and ought to represent all function modelling perspectives prominently addressed within and across disciplines. 4.4.4

Limitations

Limitations regarding the validity of the discussed results are essentially twofold:  

the limited comparability between provided answers in semi-structured or guided interviews, potential “experimenter bias”.

Experimenter bias refers to an unintentional influence from the interviewer on the interviewee through implicitly communicating prior expectations regarding what the answer might or should be (Blessing and Chakrabarti 2009). In order to reduce the potential effect of experimenter bias, transcriptions were critically reviewed and any potentially biased parts were excluded from the analysis; however, this was rarely necessary (as already discussed in Section 4.2.5). Regarding both limitations, wherever possible, answers provided by a participant were compared with the answers of other participants from the same company and scrutinised with regard to their logical consistency. In addition, participants were encouraged to provide examples of e.g. difficulties they experienced, in order to support comprehension and interpretation of the provided answers. Finally, in order to verify specific issues and provided answers during the analysis, selected participants were contacted again for clarification. Another limiting factor concerns the sample size of 35 interviews in ten companies (see also Bender et al. 2002). The study covers companies from a variety of market areas, all of which involved in interdisciplinary system development. Recruitment of participants, data collection, and analysis consumed more time than was expected, which limited the realisable sample size. However, the interview study provided very rich data. Furthermore, central findings could be similarly found in different companies, which supports the confidence in the discussed results and fosters the assumption that the findings may also apply to other companies involved in interdisciplinary design. The selected interview format led to detailed discussions during many of the conducted interviews. These conveyed compelling insights into conceptual design and function modelling applied in practice. In the discussions, individual questions and answers could be extensively investigated, which eventually allowed a differentiated analysis of the raised issues. For this kind of explorative empirical research, the selected study design is thus considered to have been appropriate. 110

Chapter 4: Function Modelling in Practice – An Empirical Study

4.5 Conclusions from literature reviews and empirical study Both the presented literature reviews in Chapter 3 and the interview study presented in this chapter belong to the DS-I phase in the overall research approach (see Figure 1-2). The presented empirical study complements the initial insights derived from the conducted literature reviews with insights into the actual application of different function models in the companies. This further allows for differentiated classification and prioritisation pertaining to addressed modelling perspectives, used morphologies, as well as their dependencies. The presented findings suggest that different function models proposed in literature or applied in the companies (by designers from different disciplines) are insufficiently interlinked, as they represent different function modelling perspectives and use frequently incompatible modelling morphologies. They hence do not sufficiently support a consistent exchange of information between designers. This is particularly apparent regarding the separation between system-level function models and those used in disciplinary design in practice. In addition, function modelling is performed highly variably and was found to depend on personal preferences of designers, as well as the specific progression and degree of novelty in a design project. Thus, depending on individual designers, involved disciplines, and the specific design project at hand, different combinations of modelling perspectives and modelling morphologies are required. In order to provide designers with an adequate integrated modelling approach, the following conclusions are drawn: 



 





All found modelling perspectives need to be integrated in a shared modelling approach, while explicitly allowing for flexible application; that includes - different starting points and - sequences for function modelling, in order to support flexible function reasoning (see Sections 3.3 and 4.3.4). Apart from the function modelling perspectives and additional contents identified in the literature reviews (see Section 3.1.2), in addition, bilateral impacts between allocated solution elements are prominent in specific function models in practice (see Section 4.3.4) and ought to be integrated, as their integration into function modelling seems to be one of the main pieces of information facilitating traceability and system comprehension. Time flow-oriented representations of processes may serve as a suitable basis in integrated function modelling as they are most prominent across all disciplines. The hierarchical role of specific functions can be case-dependent with respect to the targeted application (see Section 4.3.8). This case-dependency effectively corresponds to the specific conception of use cases, which differentiate functions with respect to different (intended or purposeful) applications of the system. This suggests that separating between different use cases in an integrated function modelling approach may provide a considerable benefit, as it enables to distinguish different applications that a system may be put to and thus to adequately represent the respectively required functionality. An exceptional role seems to apply to the effects perspective. It is only addressed in a single model in practice facilitating the detailed analysis of individual transformation processes and related state changes (see Section 4.3.1). This suggests that effects may only be relevant in specific cases, primarily related to function analysis, in design practice. Designers need to be able to adapt modelled contents and the applied level of detail to the requirements of a design project, in order to manage and delimitate modelling efforts (see Sections 4.3.5 and 4.3.8). 111

The combination of required adaptability regarding contents while being able to integrate different modelling perspectives and morphologies poses a particular challenge to the development of an integrated function modelling approach. These considerations and the described problems with inconsistencies between separated models do not suggest usage of an existing function modelling approach (found in literature or practice). A new type of representation is required, in order to address these issues and provide designers with a flexible modelling support in the early stages of system development (see also Sections 4.3.7 and 4.3.8). Based on the conclusions discussed in this section, specific needs and requirements for the development of an integrated function modelling approach are formulated in the following chapter. These serve as vantage point guiding the development and proposition of a novel approach for integrated function modelling.

112

5 A FRAMEWORK FOR INTEGRATED FUNCTION MODELLING

The obtained insights from the conducted literature reviews and interviews helped deriving an understanding of what is specific to function modelling within and across disciplines in terms of addressed contents and ways of representing functions. Furthermore, specific needs and preferences of practicing designers were explored. The empirical study presented in the previous chapter supports the fundamental assumption in this thesis that shared, cross-disciplinary function modelling can facilitate the establishment of a shared understanding among collaborating designers, which eventually can support the design process and improve the design of interdisciplinary systems. Despite the advances achieved in some of the visited companies, integration of function modelling across disciplines is still hampered and various shortcomings remain (see Sections 4.3.5 and 4.3.8). Further support for shared function modelling is needed and was explicitly requested in several of the visited companies. This chapter presents a new function modelling framework, which is intended to provide a suitable support for shared, cross-disciplinary function modelling23.

5.1 Towards integrated function modelling In order to adequately support cross-disciplinary function modelling and overcome the remaining shortcomings, a new type of function modelling approach is needed, which is able to relate between different function modelling perspectives and modelling morphologies. As discussed before, such an approach is ultimately expected to improve the designers’ understanding of the system beyond their own disciplines and provide an increased vocabulary for modelling and communicating about the functions of a system. Requirements Insights obtained from the interviews with practicing designers and from the literature reviews are equally considered in the formulation of specific requirements for the development of an adequate, integrated function modelling approach. Based on the previous discussions, two fundamental specifications can be pre-defined, which are regarded compulsory for the development: 1.

23

Integrated function modelling should conciliate between using a single model integrating a large amount of diverse information, in comparison to using multiple, separated models that complementarily address the respective information. This is required in order to address the conflicting issues of preventing inconsistencies, managing modelling complexity, and supporting

An earlier version of the modelling framework presented here has been published in Eisenbart et al. (2013d).

113

flexibility in modelling, while at the same time enabling the required integration of all relevant information (as discussed in Sections 3.3.3 and 4.3.8). Because of the striking centrality of function models that represent functions related to their flow in time (see Sections 3.2.9 and 4.3.4), an integrated function modelling approach should similarly use the time flow as basis for representing different aspects of system functionality.

2.

Based on the discussions in the previous chapters, further requirements can be formulated. Accordingly, an integrated function modelling approach should: 



















enable linking all identified function modelling perspectives; wherein, - effects should be arranged in a way that allows detailed analysis of specific transformation processes (see Section 4.3.4); - functions should be differentiable per use case, in order to enable making explicit eventual application-dependent relations and dependencies between functions (see Sections 3.2.2, 3.2.6, and 4.3.8). enable switching flexibly between considered function modelling perspectives, in order to facilitate flexible application, which refers to different modelling sequences and different entry points (e.g. whether function modelling starts by determining the required state changes of operands or by determining different use cases, etc., as discussed in Sections 3.2.9 and 4.3.4). be able to integrate different modelling morphologies, as all information about specific links and dependencies between functions that is conveyed in them (hierarchical or flowdependencies) can be either technically relevant in function modelling or sought after by individual designers, e.g., for preference reasons (see Sections 4.3.4 and 4.3.7). provide a condense and clearly structured representation, in order to ease comprehension of the modelled information among collaborating designers. Retrieval of specific information from a complex model can be a difficult cognitive task and may require a considerable effort (see Section 3.3.3); it should, therefore, be facilitated and made as easy and as quick as possible. allow flexible adaptation of modelled contents, i.e. addition or omission of specific information in relation to whether it is required in a design project should be enabled (see e.g. Section 4.3.4). support modelling functions both on system-level and during disciplinary conceptual design, in order to enhance consistent function modelling top-down from system-level to disciplinespecific design (see Section 4.3.8). allow for combined modelling of system functionality and solution elements (i.e. the function and the function carriers foreseen for their implementation), in order to facilitate top-down and bottom-up traceability of represented information during modelling and support evaluation of (alternative) solution concepts (see Section 4.3.6). allow different ways of formulating functions, in order to enable the application of either different function taxonomies or less formalised approaches, depending on whichever is preferred by the designers in a company (see Section 4.3.6). enable modelling to start on paper, i.e. function modelling should not necessitate software tool support to be performed, in order to provide designers with a large degree of freedom in modelling, which is particularly important in the early stages of a development project (see Section 4.3.7). finally, facilitate possibilities to perform consistency analysis in relation to represented information, in order to prevent design errors (see Section 4.3.6). 114

Chapter 5: A Framework for Integrated Function Modelling Beyond the function modelling perspectives and the information about links and dependencies between functions, additional contents were found that should be integrated (see Sections 3.1.2 and 4.3.4): 

 

impacts from and on the environment, although this is only discussed by few authors and only addressed in a single model from the visited companies, inclusion of this information may support the evaluation of viable solution concepts (as also discussed in Section 4.3.1); constraints and target values to support selection of suitable solution concepts; bilateral impacts and dependencies between solution elements, which were also comprehensively discussed in Sections 4.3.3 and 4.3.6 and were identified to be a key element in relation to supporting system comprehension and – eventually – communication between designers (across disciplines).

In the development of the integrated function modelling approach, different variants were generated and evaluated with regard to the formulated requirements as well as comparatively with one another. Each variant was tested by re-modelling multiple examples of function models from different disciplines provided in literature and of a function model of a mechatronic system provided by participants in Company F during the interview study. The development and detailing process of the selected variant was further supported by feedback from four senior researchers from the fields of engineering design research and software development. In addition, feedback was obtained from a practicing designer involved in aerospace design, who has a background in systems engineering and engineering design research. The resulting function modelling framework is described in the following.

5.2 The Integrated Function Modelling (IFM) framework A specific barrier for integrated function modelling is the found incompatibility of existing disciplinespecific function models, due the differences in morphology and addressed contents. In order to overcome this barrier, a different kind of representation was selected for the developed modelling framework, namely a combination of modular matrices. Matrices were chosen as they offer a clearly structured representation, which allows modelling and retrieving information quickly. In addition, matrices are already successfully applied for the representation of specific information in shared function modelling in multiple of the visited companies (see Section 4.3.8) which suggests suitability for the intended utilisation. 5.2.1

Overview

The matrices in the Integrated Function Modelling (IFM) framework represent different views onto the functionality of a system. An overview of the framework is provided in Figure 5-1. The matrix-based representation used in the framework is related to the concept of Design Structure Matrices (DSM) or Multi-domain Matrices (MDM), respectively (see e.g. Lindemann and Maurer 2007). These kinds of matrices map different design information, in order to facilitate representation and analysis of specific dependencies between the represented entities. They are used in the developed modelling framework to clearly structure information associated to the identified function modelling perspectives as well as their specific links and mutual dependencies in the different views. The views are strongly interlinked through mutually shared header rows and header columns in the specific, adjacently placed matrices forming the individual views (see Figure 5-1). 115

USE CASES TIME

State view ACTORS OPERANDS

PROCESSES

Process flow view

Effect view

PROCESSES

OPERANDS ACTORS

Interaction view

Use case view

Actor view

Figure 5-1: The Integrated Function Modelling framework The entities encompassed in the framework correspond to the discussed function modelling perspectives and additional contents addressed in the reviewed function models. In a few cases, the definitions of the entities representing the different function modelling perspectives are slightly adapted to allow embedding them in the matrix-based framework. Furthermore, the links between functions that are conveyed in the modelling morphologies (e.g. their sequence in time or flow of operands, etc.) are encompassed in associated matrices. In the following, the entities and their relations are described; subsequently, the different views and their interconnections are introduced. 5.2.2

Entities and relations

A fundamental notion of function is associated to the intended or perceivable behaviour of a system under consideration (see Section 4.3.9). The entities in the framework and their relations are defined in accordance with this notion of function. They comprise uses cases, processes, effects, states, operands, and actors. A description of the entities is provided in Table 5-1. Table 5-1: Description of entities addressed in IFM framework Entities

Process

Use Case

Description Different cases of applying the system. This is typically associated to the interaction of actors with the system under development, which may require subsequent transformation processes to take place. The associated set of processes lead to an observable result, in order to provide some kind of value to users.

Processes executed by actors, which (from the designers’ perspective) are part of the system under consideration Transformation and may lead to a change of state of actors or of operands. Technical processes are transformation processes process related to technical sub-systems; human processes are related to stakeholders (thus, including service activities). Interaction process

Representation of interaction processes of actors, which (from the designers’ perspective) are not part of a system, with actors, which are part of the system under consideration. Representation of the required physiochemical effects, which have to be provided, in order to enable or support transformation and/or interaction process(es).

States

Representation of the states of actors or of operands before (input) and after (output) a transformation process.

Operands

Operands are typically specifications of energy, material, and information.

Actor

Effects

Stakeholder

Stakeholder comprises (groups of) animate beings affected by or affecting the system under consideration (including any related services).

Environment

Environment includes all active and passive parts of nature in general surrounding the system under development.

Technical subsystem

Technical sub-systems encompass technical systems (i.e. technical products, potentially combining mechanical, electrical, and software systems with associates services), which are part of the system under consideration. They can be composed of more technical sub-systems.

116

Chapter 5: A Framework for Integrated Function Modelling With regard to the entities in the framework, function in relation to behaviour may be regarded through the consideration of different use cases and/or the specific inherent transformation and interaction processes. Associated state changes of involved operands and/or actors, further, provide a more abstract perspective onto the behaviour of a system (as discussed in Sections 2.3.1 and 4.3.9). Actors – alone or in combination with others – behave by providing required physiochemical effects and bilateral impacts contributing to function fulfilment. The specific relations between the different entities and their contribution to the functionality of a system under consideration are illustrated in the UML-based class diagram in Figure 5-2. The entity-relations are further explained in the following. States *

Use Case

1..*

1

Operand

Effect Effect

States

1 1

1

1..* 1..*

System1 under consideration 1

1..*

1..*

Actors

1..*

1..*

Process 1

1..*

*

Stakeholders

1..* 1..*

Environment

1..* 1..*

Technical (Sub-)System

*

Transformation processes Interaction processes

1

Figure 5-2: Class diagram of the IFM framework A system under consideration may support one or more use cases. Each use case may be decomposed into sub-use cases. Use cases may have dependencies among each other that may be bound by specific constraints (mutually exclusive, mutually inclusive, etc.). For all other situations, in Figure 5-2, the dependencies shown are used to depict similar constraints. A use case may have one or more processes associated to it. Processes include transformation processes and/or interaction processes. There may be dependencies between individual processes, which may further be composed of subprocesses. A process may result in the transformation of the state of one or more operands and/or actors from a given state into another state. Processes which only indirectly contribute to a state change are regarded as supporting or auxiliary to the system functionality. Processes are enabled or supported, respectively, by effects. Effects are provided by actors. Actors – by providing the necessary effects – serve as operators or function carriers. Actors contain the sub-classes of stakeholder, technical (sub-)system, and environment (see Table 5-1). They may also have dependencies among each other. Operands may similarly interact and have dependencies among each other. Operands may temporarily assume the role of an actor during a use case by supporting the state transition of actors or other operands in relation to the execution of specific processes (as discussed by Nevala 2005). 5.2.3

Different views for representing system functionality

In the IFM framework six central views are proposed, which represent the different entities and their dependencies: process flow view, state view, actor view, use case view, effect view, and interaction view. In the following, the specific setup of individual views and their combination in the framework (see also Section 5.2.4) are described. The descriptions are complemented by an example of a mechatronic system to illustrate the representation of information in the views. 117

The chosen example is a customary coffee vending machine, which can provide a variety of warm drinks24. The selectable options of offered drinks represent different use cases associated to the vending machine (see Table 5-1). They include (but are not limited to):     

prepare a cup of coffee, prepare a cup of cappuccino, prepare a cup of espresso, prepare hot tea water, and automated cleaning.

The examples of the different views that are presented in the following are associated to the use case of “prepare a cup of coffee”. Finally, Figure 5-13 (see Section 5.2.4) illustrates how the different views for this use case are combined in the framework. Process flow view The process flow view is constitutive for the framework and is centrally arranged (see Figure 5-1). A process flow view is associated to one use case and represents the flow of processes required for use case fulfilment. Processes are represented as chronologically numbered blocks (see Figure 5-3). The vertical direction visualises their flow in time. This allows for indicating qualitatively, whether represented processes are to be carried out sequentially, in parallel or overlapping with each other. In addition, reuse of processes in a sequence may be indicated (see Process 4 in Figure 5-3). It further matches the flow of states from initial to final related to operands and actors in the state view (see also Figure 5-7). In horizontal direction, the process blocks are spread from left to right to enable a direct link to actor view and use case view. process 1

TIME

process 2 process 3

process 4 process 5 process 6 process 4

Figure 5-3: Schema of a process flow view Example: Figure 5-4 illustrates the flow of processes (P1 till P6) that are required for fulfilment of the use case “prepare a cup of coffee”. Several of these processes contain further sub-processes. For instance, Process 1 “coffee is ordered” encompasses the sub-processes P1.1 to P 1.3 (as indicated in the more detailed excerpt at the bottom of Figure 5-4). Similarly, Process 6 “dispose of waste” involves a separate flow of sub-processes that are associated to a service provider who cleans the machine regularly. The sub-processes are modelled in a separate partial process flow view (as indicated in Figure 5-4). Alternatively, an eventual existing service blueprint or activity flow model can be attached. 24

Parts of the presented example and the potentials for applying the framework for modelling and analysing system functionality presented in Sections 5.2.3 to 5.2.6 have also been published in Eisenbart et al. (2014).

118

Chapter 5: A Framework for Integrated Function Modelling Processes can also be specified further by adding quantities or constraints, as indicated for Process 2 “heat water” in Figure 5-4. UC: "Prepare a cup of coffee" P1: Coffee is ordered P2: heat water

P3: grind coffee beans P4: mix water and powder P5: fill drink in cup

P6: dispose of waste

Process 6 P1.1: user chooses to order coffee P1.2: user pushes "coffee" button

P1.3: coffee making is initialised

Option: inclusion of quantities or constraints

P2: heat water

P3: grind coffee beans

sec 0.2 litres in 60 sec.

Figure 5-4: Example of process flow view for use case “prepare a cup of coffee” Actor view The actor view indicates the specific involvement of one or more actors in the realisation of individual processes in a use case. Involvement can be differentiated between e.g. either “affecting”, “supporting” or “being affected by” a process; however, other distinctions may be used, if preferred by designers. The view allows differentiating actors according to whether they – from the designers’ point of view – are part of the system (e.g. service operators as part of a PSS) or not (e.g. the targeted users or external service providers). This differentiation also separates transformation processes (enabled by actors that are part of the system) from interaction processes (enabled by actors that are not part of the system, as defined in Table 5-1).

Actors

Technical subsystems Internal stakeh.

External stakeh. Environment

process 1 process 2 process 3 process 4

TS 1.1 Technical subTS 1.2 system 1 TS 1.3 Technical sub-system 2 Service operator 1 Service operator 2 Targeted user External service provider Environment

being affected affecting

supporting being affected affecting

System Border supporting

Figure 5-5: Schema of actor view 119

Example:

X

X

X X

X

X

X X O X

O

Cup Control unit

P6: dispose of waste

O

P5: fill drink in cup

X

P4: mix water and powder

Actors

Grinder

X O O

P3: grind coffee beans

Heating system

P2: heat water

"Coffee" button

P1: coffee is ordered

Figure 5-6 illustrates the allocated actors for the main process flow illustrated in Figure 5-4. Actors include technical sub-systems, such as the heating system, grinder, etc., stakeholders, such as service provider and user, as well as the environment. The specific role of the allocated actors in the realisation of the different processes is indicated with “X” for affecting or “O” for being affected by, respectively.

X

…

X

Service provider

System Border

X

User

O

Environment

O

Figure 5-6: Example of actor view for the use case “prepare a cup of coffee” State view The states view (Figure 5-7) represents the specific states from initial (s1) to final (sf) of operands (o) and actors (a), as well as the state changes caused by individual processes (p). In addition, it can be indicated whether operands and actors are merely supporting a process without necessarily being changed in their states themselves. The view consists of the actor state matrix and the operand state matrix. The adjacent placement of state view and process flow views allows for consideration of the required changes from initial to final states in parallel to the creation of the process flow view to facilitate their parallel development and mutual consistency.

State view Actors initial states processes states processes states processes states processes final states

Process flow view

Operands

Actor 1

Actor 2

Operand 1

Operand 2

a1-s1 p1 a1-s2

a2-s1 supporting p1

o1-s1 p1 o1-s2 supporting p2

o2-s1

a1-sf

process 1 process 2

p3

p4 o1-s3

supporting p3

a2-sf

o1-sf

o2-sf

Actor state matrix

process 4 process 3

Operand state matrix

Figure 5-7: Schema of the state view – comprising the actor state and operand state matrices Example: Figure 5-8 illustrates the state view corresponding to the given process flow view (see Figure 5-4) with the allocated actors from the actor view (see Figure 5-6). States of actors and operands are 120

Chapter 5: A Framework for Integrated Function Modelling transformed associated to the corresponding processes in the flow. For instance, the state of water (operand) will change from 20 degrees to 100 degrees Celsius through Process 2 (P2) “heat water” and is finally transformed in its state from water to coffee through Process 4 (P4) “mix water and powder”. An example for an actor state change is the state of the cup, which changes from “empty” at the beginning to “filled” through Process 5 (P5) “fill drink in cup”. Actors "Coffee" button

Heating system

ready for use switched off

Grinder

Cup

Control unit

switched off

empty

active

P1

P1

P1

locked

switched on

switched on

inactive

User

Environment

Water

Coffee beans

Energy

desires coffee

N.A.

20°

whole

electrical

supporting P1

supporting P2 and P3

switched off

spporting P4

P6 ready for use switched off

…

P1

supporting P2 supporting P3 switched off

Operands Service provider

switched off

Supporting P4

P5

supporting P5

supporting P6

P5

filled

active

inactive

has coffee

P2

supporting p2

P3

100°

coffee powder

heat

P4

P4

coffee

waste powder

coffee

emtptied

P6 heat

Figure 5-8: Example of state view for the use case “prepare a cup of coffee” Effect view The effect view represents the effects, which enable individual transformation processes and are provided by actors. For each process block in the process flow view, a separate effect view may be modelled, preferably using a similar representation (see Figure 5-9). Effect views may be modelled for one or more process blocks to allow for detailed analysis of the specific processes in relation to the required physiochemical effects that are affecting them and/or contribute to their fulfilment. Example: Figure 5-9 illustrates an effect views for the example of Process 2 “heat water”, using a similar representation as in the process flow view in combination with an associated state view. The process requires the transformation of electrical energy into heat (through the effect E1 “transform energy”), which needs to be channelled towards the involved water (E2), in order to heat it. Water

Energy

20°

electrical

E1, E2

E1, E2

100°

heat

E1: tranform energy

E2: channel heat

Figure 5-9: Effect view with associated partial state view for Process 2 “heat water” Use case view The use case view lists the different use cases associated with the system under consideration and indicates the involvement of individual processes within them. Dependencies between processes, which hinder their parallel or sequential execution, could affect the operability of use cases in which these processes are involved. The use case view is intended to support analysis of this kind of dependencies as well as of dependencies between actors involved in the processes in different use cases. This is further discussed in Section 5.2.6. Use cases are listed in the header column. The flow of processes builds up the header row, which links the use case view with the process flow view. 121

Example:

Prepare hot tea water Automated cleaning

x x

x

x x x

x x x

P3: grind coffee beans P4: mix water and powder P5: fill drink in cup P6: dispose of waste

Prepare a cup of espresso

P2: heat water

x x x x

Prepare a cup of capuccino

P1: coffee is ordered

Use Cases

Several of the transformation processes in the use case “prepare a cup of coffee” are also involved in multiple of the alternative use cases, as illustrated in Figure 5-10. For instance, Process 2 “heat water” is also involved in the use cases of “prepare a cup of cappuccino”, “automated cleaning”, etc. However, while the use case “prepare a cup of coffee” requires 0.2 litres of water of 95 to 100 degrees Celsius, other use cases, such as “prepare hot tea water” or “automated cleaning”, require different quantities of water and different temperatures to which it is heated (e.g. 75 degrees for tea). These dependencies need to be considered and will require alternative parameterisation of Process 2 in different use case.

Figure 5-10: Example of use case view for the coffee vending machine Interaction view The interaction view essentially represents the bilateral impacts between actors and operands, as well as their complementary contributions to the realisation of a use case, associated processes, etc. As an addition, information about the embodiment of specific bilateral impacts may be included. Hence, this view essentially results in an initial system structure or interface matrix of the system, respectively. The view is comprised of an actor DSM, an operand DSM, as well as actor/operand and operand/actor MDM, as indicated in Figure 5-11. In principle, all kinds of bilateral dependencies between actors can be represented in this view, more technical ones but also, e.g., business relations, monetary flows, etc. (see also Section 2.1). The specification of the interactions between actors or operands includes the number of the respective process (to provide clarity, as numerous interactions may be relevant related to different processes in a flow) and a short statement specifying the interaction. The roles of actors and operands, as either affecting a process or being affected by it, is indicated by the impact direction. OPERANDS

ACTORS

ACTORS

OPERANDS

IMPACT

Figure 5-11: Schema of interaction view 122

Chapter 5: A Framework for Integrated Function Modelling Example: For illustration purposes, occurrence of bilateral impacts is simply indicated with an “X” in Figure 5-12. Examples of bilateral impacts to “prepare a cup of coffee” include,

X X X

Heating system Grinder Actors

Environement

User

Service provider

…

Operands

X

"Coffee" button

Cup

X X X

X X

1

(P3) send signal (12V) for grinder to start (P4) send signal (12 V) for grinder to stop

X X

Control unit …

X

Service provider

X X

User Environment Operands

Control unit

Cup

Grinder

Heating system

"Coffee" button

Actors

Energy



Coffee beans



the control unit (actor) impacts on the grinder (actor, see ① in Figure 5-12) through signals triggering the grinder to start or stop, which are embodied through an electrical current; the hot water (operand) impacts on the cup (actor, see ②) and the user (actor, see ③) through transmitting heat, which is embodied through physical contact and radiation; operands may also impact on each other, as e.g. energy (in form of heat) impacts on the water (see ④) during Process 4 “heat water”.

Water



X

2

X X X X X X X X X

Water Coffee beans Energy

X

X

3

X X X X X X X4 X X X X X

Impact direction Figure 5-12: Example of interaction view for use case “prepare a cup of coffee” 5.2.4

A synthesis of views

Interlinking different views onto the functionality of a system The views in the framework represent the functionality of system in terms of providing alternative – but interrelated – abstract viewpoints onto the behaviour of a system under consideration. The aim behind the specific setup of the IFM framework is to interlink the represented information via the central process flow view. This is expected to allow designers to take different perspectives in function modelling and reasoning during conceptual design, i.e. flexibly switching between viewing system functionality by looking at the flow of operands or the flow of processes in time, etc. The combination of the views allows for integrated modelling of the flow of transformation and interaction processes for each use case, and associated (bilaterally impacting) actors and operands contributing to their implementation, as well as eventual changes in their states.

123

The allocated actors in the framework can combine mechanical, electrical or software systems, as well as human (or other animate) beings and their respective functionalities and dependencies. The combination of views is therefore expected to allow integrated modelling of various engineering technologies as well as services and thus enable integration of function modelling by designers from different disciplines. This is intended to facilitate cross-disciplinary exchange of ideas and joint selection of suitable solution concepts. Furthermore, the explicit allocation of actors in the actor view in combination with making explicit the bilateral impacts among them in the interaction view, is assumed to endorse the desired traceability (top-down and bottom-up) between functions and solution elements foreseen for their implementation (i.e. the actors). Figure 5-13 illustrates the combination of the central views for the example of the coffee vending machine, which was presented in the previous section. The interconnections of entities represented in the individual views in the framework offer various possibilities to do function analysis (which are discussed in detail in Section 5.2.6), due to the matrix-based representation. A modular framework allowing flexible combination of views Views are modular, as they may be flexibly added or omitted. This is expected to allow for demandspecific adaptation of the framework related to the needs and preferences of designers in a design project. Adaptation includes  

augmenting, i.e. adding further information in the views (or depth in the descriptions of represented entities, respectively), as well as tailoring, i.e. omitting details in the different views or omitting entire views if not required in a specific project, thus leading to a reduction of modelling efforts and complexity.

That means, depending on the specific disciplines involved and design approaches applied, the designers can flexibly select (and thus focus on only) the specific views and detail of information represented in them that they require. For instance, through combination of the process flow view with the state view and actor view, the specific information typically represented in IDEF-0, service blueprints or e.g. Hubka and Eder’s transformation process structure can be similarly modelled (and augmented by further views if desired). As a further example, combined modelling of process flow view and operand state matrix (in the states view) can be used in mechanical engineering, e.g. for function modelling similar to function structures after Ehrlenspiel (2007) or Ulrich and Eppinger (2008). Adaptation of the framework to match different modelling approaches from literature and practice is investigated in detail in Section 5.3. Apart from the views presented in Section 5.2.3, it may prove beneficial for individual designers to add entirely new views, in case specific information is particularly important in a design context or situation at hand. Essentially, any additional view addressing information about specific dependencies of (multiple) entities may be added. For instance, in electrical engineering, petri nets or finite state machines were identified to be particularly prominent (see Section 3.2.3). Thus, electrical engineers may benefit from including a state/state matrix, indicating all possible transitions between actor and/or operand states. Such a matrix can be conveniently embedded into the structure of the IFM framework (e.g. in form of a state/state view), if desired by individual designers.

124

switched off

spporting P4

switched off

supporting P2 supporting P3

P1

switched on

P1

switched on

ready for use switched off switched off

P6

locked

P1

ready for use switched off switched off

Grinder

Heating system

"Coffee" button

125

X

…

Impact direction

X X X X

X

X X X

X

X X

X

X

X

heat

Energy

Coffee beans

Water

Environment

User

Service provider

…

Control unit

Cup

Grinder

Heating system

"Coffee" button

Actors

X

X X X

X

X X X

X

Service provider

X

Environement

X

Control unit

X

Coffee beans

X

User

X

Water

X

emptied

Operands

P1: Coffee is ordered

X

O

X O O

Process 1: Coffee is ordered

X

coffee

initial states process states process states process states process final states

Automated cleaning

O

X

X

P4: mix water and powder

X

X

X X

System Border

X

X

P3: grind coffee beans

P2: heat water

Process 2: heat water

X

has coffee

P6

P4 waste powder

P4 coffee

P3 heat

supporting p2 coffee powder

electrical

P2

whole

100°

20°

Process 3: grind coffee beans

X

inactive

N.A.

X

Process 4: mix water and powder

X

active

Actors

P5

supporting P1

desires coffee

X X X X

X X O X

O

X

X

O

P6: dispose of waste

X

X X

P5: fill drink in cup

X X X

Process 5: fill drink in cup

X

Cup

X X

inactive

supporting P5 supporting P6

Supporting P4

supporting P2 and P3

P1

active

Prepare hot tea water

Prepare a cup of espresso

Process 6: dispose of waste

X

filled

P5

empty

Use case: "Prepare a cup of coffee" Prepare a cup of capuccino

Chapter 5: A Framework for Integrated Function Modelling

Operands

Energy

Figure 5-13: Combination of associated views for the use case “prepare a cup of coffee”

5.2.5

Hints on the application of the IFM framework

Modelling activities and steps The framework – through its modular and interlinked character – is explicitly intended to allow for flexible application in alternative ways, as indicated in the previous section. That includes different entry points and sequences for modelling. Both may also strongly depend on eventually available models from former design projects, which can potentially be reused (at least in parts) in subsequent projects. Essentially, the framework offers the designers a set of views that they may choose from and combine during modelling, depending on which information is needed in a specific situation. In the following, one potential way for applying the IFM framework in an original design project is described. The proposed sequence of modelling activities is inspired by existing modelling approaches, which similarly differentiate inherent processes with respect to alternative use cases (see e.g. Cockburn 2000 or Kruchten 2004). Furthermore, established practices in the visited companies that already use some sort of shared function model on system level were taken into account. In an original design project, the requirements list is analysed in an initial step by system-level designers and/or key designers from involved disciplines. In this analysis, central expected functions as well as associated sub-functions are derived from the provided functional requirements. In the next step, the central use cases can be determined and specified based on the collected central functions. In this step, use cases can simply be listed and roughly textually outlined (e.g. in terms of central goals and involved actors) in a few sentences. The specific applications that a system is used in, can change in the course of its life cycle. This is of particular relevance for life-cycle oriented systems, such as PSS (as discussed in Section 2.1). Changes in the application of a system over its life-cycle may be regarded as variant use cases and specified as such in the list of use cases and/or in the use case view. Modelling with the IFM framework may then start by sorting expected functions into the outlined use cases, i.e. as flow of associated transformation and interaction processes. Subsequently, the respective process flows are gradually detailed and complemented by required sub- and supporting transformation processes. Considering the respective associated state changes of operands and/or involved actors and their states can support this step. On the next level of detail, individual process blocks may then themselves be decomposed into sub-processes. This can be supported by modelling the effects required for process fulfilment. Considering the required effects, furthermore, can support actor allocation in the next step. During actor allocation, specific actors are gradually allocated to the determined processes. Allocated actors may initially be modelled as general function carriers or abstract organs (see Section 2.4.2). The designers may subsequently concretise these general function carriers, as soon as more information becomes available (as discussed in Section 2.4.1). Thereby, the framework is intended to allow for modelling the functions and actors of a system under development from very abstract to detailed and specific. Actor allocation essentially marks the transition to the potential solution concept. The selected combination of actors defines the specific technologies to be integrated, i.e. whether the developed system combines mechanical with electrical components or further involves software systems, as well as eventual services and their providers. In this step, the designers thus have to decide what kind of system is going to be developed: a mechanical, an electro-mechanical, a mechatronic system or a PSS. The selection of actors, their combination and functional interrelations define the discipline-specific and cross-disciplinary development duties. Based on the allocated actors, designers can proceed to model associated actor states and their changes, as well as their mutual impacts. 126

Chapter 5: A Framework for Integrated Function Modelling Table 5-2 collocates the central described modelling activities for the application of the IFM framework. They are expected to be iteratively performed in the transition from a requirements specification to a potential solution concept (see also Figure 5-14), in order to detail the views gradually. Table 5-2: Potential modelling activities for applying the IFM framework Modelling activity Description …includes the consolidation of the different use cases (and their sub‐use cases, if applicable) the system under Use case development is expected to support in the different phases of its life‐cycle. The use cases are then listed in the respective ① definition column in the use case view.

②

…involves determining separate flows of required processes related to each use case. A multitude of alternative process flows may fulfil a use case. While modelling the process flows, the involvement of individual processes in multiple use Process flow cases needs to be considered. Modelling and selecting an alternative process flow may be facilitated through considering modelling the required state changes of operands and actors in parallel (i.e. by combination of the process flow view with the state view). Different criteria may be used by designers during optimisation and selection of the most suitable process flow. Operand

③ state ④

modelling Effect modelling

…includes modelling the state changes of involved operands in the operand state matrix (as part of the state view) related to the established flow of processes. …involves establishing the required effects related to specific process blocks that are of particular interest to the designers for detailed analysis.

Actor

…includes allocation of the actors, which are involved in the individual processes, either as affecting (i.e. contributing to process fulfilment by providing the required effects) or as being affected by the respective processes.

Actor state

…includes modelling the state changes of allocated actors in the actor state matrix (as part of the state view) related to the chosen process flows.

Interaction

…involves analysing and detailing the specific bilateral impacts among actors, among operands, and between actors and

⑤ allocation ⑥ modelling

⑦ specification operands.

Associated views Interaction view USE CASES

Actor states matrix

Actor view State view

3

Operand states matrix

Modelling step

6

ACTORS OPERANDS

Iteration

Process flow view

Modelling activity 1

2

3

4

5

6

7

Use case definition

Process flow modelling

Operand state modelling

Effect modelling

Actor allocation

Actor state modelling

Interaction specification

Use case view

Interaction 7 view

Use case view PROCESSES

Process flow 2 view

Effect view 4

PROCESSES

OPERANDS ACTORS

Effect view

TIME

1

Actor5view

Figure 5-14: Potential sequence of modelling activities and associated views (only main steps shown, further iterations may occur between any point in the illustrated progression) Detailing of views may be achieved through decomposition of individual actors, process blocks etc. Alternatively, associated partial views may be generated, which focus on one specific process block (i.e. “zooming in” on individual process blocks, see e.g. Figure 5-4). Furthermore, the users of the model may choose, whether they would like to address the entire system at a time or focus on a specific subsystem (e.g. a discipline-specific sub-system). What is considered at a specific point in time may be changed by shifting the position of the system border (see Figure 5-6). In this way, individual designers may focus on discipline-specific sub-systems (if desired) while conceptual design progresses to disciplinary design (see also Section 4.3.2). 127

Recommendations for applying the IFM framework in interdisciplinary design From the insights into the experiences with cross-disciplinary function modelling gained in the visited companies, a few general recommendations for the application of the IFM framework can be derived. In particular, the experiences made while newly introducing function models (see Section 4.3.4) suggest a variety of measures, which may substantially support shared function modelling between different disciplines. They are described in the following: 









Starting on paper and/or using lists: In an initial step, the derived central expected functions and use cases may be simply be listed, in order to develop an overview among involved designers of what is required for the system to be developed. Initial process flow views can be generated on paper before adding associated views and move to more detailed modelling (potentially using software tools). Starting on paper and simple lists is considered advantageous to facilitate quick and flexible adaptation of the represented information, particular during the early modelling stages. Collaborative model generation: Key designers from involved disciplines should jointly model system functionality with the IFM framework, particularly on system level. This is intended to ensure that discipline-specific information which is also relevant across the involved disciplines is included in the model. This may be further substantiated by - joint definition of central terms used in the model, - regular, guided meetings to communicate advances in the design process and eventual changes made to the shared function model. Appointment of responsible system-level designer: In addition to the collaborative model generation, a system-level designer (e.g. a systems engineer or project manager) should be appointed as responsible person for supervision and maintenance of the generated model, in order to facilitate consistency and regular updating of represented information throughout a design project. Guided formulation of functions: Highly formalised ways for the formulation of functions are rejected by practicing designers25. Based on the conveyed experiences in the companies (see Section 4.4.1), it is recommended, to - propose a shared definition of function among designers in the company, - prepare guidelines and training on how to formulate functions, - use concise statements in natural language, describing what is expected to happen (i.e. the behaviour of the system); this can be complemented with information about constraints or target values. Involving designers in the introduction process: Introducing a new modelling approach in a company requires an initial learning effort and training for the designers to get acquainted with it. Experiences from the visited companies suggest that involving designers in this process and clearly communicating purpose and expected benefits can support acceptance of a new model by the involved designers.

25

The framework is open to alternative ways of formulating functions. This can include alternative function taxonomies (see Section 2.5.1), if the designers desire to use one of them, or other, less restrictive approaches, as discussed before. The freedom in this respect is expected to enable companies to develop and use their own specific guidelines for the formulation of functions in the framework. The possibility to do so was described to be an advantage in different visited companies (see Section 4.3.6).

128

Chapter 5: A Framework for Integrated Function Modelling 5.2.6

Potentials for supporting function analysis

The specific setup of interconnected matrix-based views in the IFM framework is assumed to allow for application of established analysis methods for DSM and MDM (see e.g. Lindemann et al. 2009, Maurer and Meisenbacher 2013, Eppinger and Browning 2012, and Schmidt et al. 2013). In the following, a few examples of applicable analyses methods are briefly discussed. They may be performed for a completed IFM model or already during the process of model generation. Conflict analysis Dependencies between processes and involved actors can affect the inter-operability of individual use cases. For instance, Process 2 “heat water” in the provided example is associated to alternative quantities or constraints in different use cases. As already indicated in the description of the use case view in Section 5.2.3, regarding the preparation of coffee, Process 2 is expected to heat 0.2 litres of water to about 95 to 100 degrees Celsius (see Figure 5-4), whereas in the use case of “automated cleaning” more water, namely about 500 ml up to a litre, but of only 60 degrees Celsius (or similar temperatures) are required for flushing the hoses. Thus, both use cases are mutually exclusive and cannot not be performed in parallel, due to the deviating quantities and temperatures associated to the same operand. Similarly, actors and operands may be mutually exclusive, such as e.g. nuclear radiation and humans as well as any related use case these are involved in (unless precautions are taken). For other examples additional steps may be required before switching between use cases. The framework can support the designers in the analysis of such interdependencies and related conflicting actors and processes. In addition, changes in individual use cases over the system’s life cycle (e.g. as variant use cases discussed before) and their effects on expected functionality (i.e. process, involved actors, and operands) can be analysed. Consistency analysis Analysing internal consistency between the information represented in the different views is of particular importance, in order to prevent flaws in modelling, particularly during change management. Facilitating consistency analysis is one of the central needs for supporting shared function modelling in interdisciplinary design projects, as discussed before. Individual views are strongly interlinked through the shared header rows and columns of inherent matrices in adjacently placed views. This facilitates verification of their mutual consistency and thus the parallel development of different views in the entire framework. For instance, considering the required changes from initial to final states of operands and actors in the state view facilitates the parallel development of the process flow view and vice versa. In the process of modelling and developing one particular view in the framework, the corresponding header rows and columns in adjacent views are simultaneously filled. Furthermore, completeness of process flows related to individual use cases can be evaluated using logical consistency analysis of associated actor and operand states, e.g. in order to identify missing steps or eventual additionally required actors etc. With regard to the provided example, it allows for consolidation whether e.g. the logical flow of states from water and coffee beans to become coffee and waste is complete, as are the related transformation processes (heating water, grinding, etc.) and involved actors (e.g. heating system, grinder, etc.). This kind of analysis can be particularly important while gradually detailing respective process flows, as described in Section 5.2.5. 129

Property analysis and change prediction In redesign projects a completed IFM framework may already exist. Property analysis and change prediction may be applied in two ways:  

(a) reasoning from a changed set of requirements towards the required changes of use cases and inherent processes, involved actors etc. or (b) reasoning backwards from a changed actor, use case etc. towards resulting changes in the offered functionality of the system.

This corresponds to the concept of top-down and bottom-up traceability. The analysis is expected to facilitate feasibility analysis for redesign projects through quick analysis and estimation of the design efforts required for changing the existing system. The IFM framework particularly aims to support designers in reasoning from required functionality towards the structure of a potential solution concept. Information about how actors and operands impact on each other facilitates the design of the interfaces between them in later design stages. Similarly, analysis of interferences between actors and/or operands may highlight problems with function fulfilment or even with malfunctioning in use. This can be of particular benefit while analysing the specific reasons for system failure. Analysis and identification of possibilities for system improvement Typically, alternative variants of actors and process flows may fulfil desired requirements and use cases for a system under development. Depending on the design context, alternative solutions can offer specific advantages over other variants. For instance, reducing complexity within a technical product or associated to stakeholder interaction processes is a desirable goal in a development project. This also explicitly refers to function sharing considerations (see Section 3.1.2). Using the IFM framework, designers can directly analyse and evaluate the amount of actors within the system and complexity of their bilateral impacts. Thus, alternative combinations for process flows and involved actors can be compared and evaluated. Related methods and tools for complexity management of systems based on DSM and MDM are discussed in detail e.g. by Eppinger and Browning (2012). Analysing possibilities for system modularisation In case a set of actors possesses particularly many bilateral impacts and dependencies among each other, but only few to other surrounding actors, they may be regarded as a “cluster” (Lindemann et al. 2009). Integrating these into one system module with defined inputs and outputs towards other actors may support modularisation. Established methods for such analyses can directly be applied to the matrix representations used in the IFM framework (see also Maurer and Meisenbacher 2013). Analysis of consistency between requirements and potential solution concepts As discussed before, one particular benefit of the IFM framework is to facilitate moving from function modelling towards an initial system structure or interface matrix, respectively. It thus allows analysis of consistency between specific interfaces or functional requirements predefined in the requirements specification and the structure as well as offered functionality, established in a potential solution concept. Furthermore, the DSM-based representation allows for direct links to a variety of established system simulation tools (as indicated by Eisenbart et al. 2013a), which offers quick and impartial means for evaluation of alternative solution concepts with respect to requirements and function fulfilment (as already discussed by Paredis et al. 2001). 130

Chapter 5: A Framework for Integrated Function Modelling

5.3 Comparison of the IFM framework with existing modelling approaches 5.3.1

Approach

The proposed modelling framework is intended to support function modelling in different disciplines and across. In the following, it is explored in which specific way the IFM framework may be used and adapted, in order to support exemplary function modelling approaches discussed in the previous chapters. The comparison is further intended to identify any potential conflicts between what is supposed to be modelled in the respective steps and how it can be modelled in the IFM framework. The comparison is guided by the question: Which particular adaptations are required, in order to apply the IFM framework to function modelling approaches proposed in different disciplines and across? For the analysis, the different views in the IFM framework are mapped onto the function models proposed in the different steps in the reviewed function modelling approaches. For this mapping, the provided descriptions of the main modelling steps (see Section 3.2) and provided example models are used as a basis26. 5.3.2

Adapting the IFM framework to different function modelling approaches

The approaches selected for this analysis are considered particularly prominent within the different disciplines or across. They originate from Hubka and Eder (1988, Eder 2008), Pahl et al. (2007), Buur (1990), Dewey (2000), Spath and Demuss (2005), Sakao and Shimomura (2007), and Weilkiens (2008). The mapping between Weilkiens’ modelling approach and the IFM framework is further considered representative of the RUP by Kruchten (2004) and the function modelling approach proposed in Company D, as these propose similar sets of function models27. From practice, in addition, the function modelling approach proposed in Company A is considered in the analysis. Firstly, the different models proposed by Hubka and Eder (see Section 3.2.2) are mapped to the IFM framework. As described before, Hubka and Eder propose different “duty cycles” for the system which resemble use cases. While Hubka and Eder (H&E) do not propose a separate model for their representation, different use cases may simply be listed in an initial step while modelling with the IFM framework (see Section 5.2.5) or, alternatively, be listed in the use case column of the use case view (IFM). The remaining models (H&E) can be directly mapped onto the different views in the IFM framework, as illustrated in Table 5-3. The function structure (H&E) does not itself use a flow in time like the process flow view, but a flow of operands related to transformation processes and effects. For modelling a function structure using the views in the IFM framework, the vertical direction in the process flow view illustrates the causal flow between transformation processes. That means, the sequence and parallelism between different transformation processes and effects is derived from the chronological succession, in which operands are transformed from input to output of the system (see also Section 3.1.3). The concept auf causal flows in the process flow view similarly applies to the function structure after Pahl et al. (see Section 3.2.2) and related function modelling approaches (see Section 2.4.2). In these kinds of models, transformation processes and effects are not separated, but in fact are 26

Initial results from the presented comparison have been published in Eisenbart et al. (2013c). In addition, a detailed comparison between the IFM framework and SysML following the approach proposed by Weilkiens (2008) can be found in Eisenbart et al. (2015). 27

131

interconnected and modelled in the same representation. In the IFM framework, the effect view is primarily included to support detailed analysis of specific transformation processes. Nevertheless, the combination of both views allows for representation of the same information. Combining process flow view and effect view is possible, as they use a similar representation (see also Figure 5-9). This is exemplified in Figure 5-15 for the example of the function structure provided in Figure 1-1. Table 5-3: Mapping between IFM framework and approach proposed by Hubka and Eder (1988) Step

1

Related models/views Hubka & Eder IFM framework Initial list of use cases (column in use case No separate model view)

Description Establishing the different duty cycles the technical system may encounter in the different life-cycle phases Establishment of the desirable or required output (operand in final state) of the transformation process Establishment of a suitable transformation process from the desirable output Establishment of an appropriate input (initial state of operand), if needed or considered helpful Allocating which operator28, alone or in cooperation with others, will perform which transformation processes; and which technical system(s) need to be designed Choice of technology (i.e. a general technical principle) to enable the transformation process(es), e.g. hydraulic cylinder, mechanical fixture etc.

Transformation process structure (see Figure 3-4)

7

Establishing what the technical system under development needs to be able to do (its internal functions and functions performed “cross-boundary”, in cooperation with other operators)

Function structure

Process flow view, effect view, interaction view

8

Establishing the function carriers (organs and/or parts), which can perform these functions

Organ structure, parts structure

Actor view

2 3 4 5 6

ELoad

Process flow view

Sf

Measure deformation

S Edeformation Specimendeformed

Load specimen

Specimen

Operand state matrix

Actor view

Measure force

Change energy into force and movement

S

Operand state matrix

Operands Specimen

Control signal

Measurement data

EnergyLoad

undeformed

controlling deformation

pending

electrical

E1

E1: Change energy into force and movement

Force, Movement

P1

supporting P1

supporting P1

deformed

pending

EnergyDeformation

supporting P2 and P3 deformed

P1: Load specimen

P2: Measure force

P2 and P3 pending

P3: Measure deformation

measured force EnergyDeformation + deformation

Figure 5-15: Rebuilding the example of a function structure from Figure 1-1 with the IFM framework, combining effects and processes in the process flow view 28

Hubka and Eder propose a slightly different distinction between actors; however, from a modelling point of view, there is no barrier for adopting Hubka and Eder’s or any other specific differentiation between actors into the actor view, as different types of actors are simply listed in the respective column.

132

Chapter 5: A Framework for Integrated Function Modelling Buur (see Section 3.2.6) proposes a function modelling approach which, to a certain extent, builds on Hubka and Eder, as discussed before. However, Buur does not propose an initial differentiation between internal and external actors and related transformation processes. Nevertheless, the modelling approach can to a large extent be mapped to the IFM framework in a similar manner. One particular aspect that is emphasised by Buur is the differentiation of use cases (called “system states”) and the specific transitions between them (see Figure 5-16). The IFM framework requires slight adaptation, in order to model transitions between use cases explicitly. Suggested adaptations are discussed in detail in the following section.

States & Transitions 2 Idle

Calling

0 3

Speaking 1 Sending number

Figure 5-16: States and transitions partial model for the example of the telephone proposed by Buur (1990) As discussed before, Dewey (see Section 3.2.3) and similar function modelling proposed in electrical engineering most prominently address system states and their transformations, in order to derive the necessary (logical) functional building elements in an electrical system. Different system states can be represented in the actor state matrix encompassed in the state view (IFM). Transformation processes changing the respective states (if applicable) can be modelled in an associated process flow view (IFM). As discussed in Section 5.2.5, alternatively, a new state/state view may provide electrical engineers conveniently with a more concise representation of the different system states and their transitions. Such a view can be added quickly, if preferred by designers. Spath and Demuss (see Section 3.2.5) propose function structures after Pahl et al. in combination with service blueprinting or IDEF-0 modelling, respectively. Both can be directly mapped to the different views in the IFM framework, as discussed earlier in this chapter (see Section 5.2.4). Sakao and Shimomura (see Section 3.2.7) propose a multitude of associated models. The essential steps and related models proposed by Sakao and Shimomura and how they can be mapped to the IFM framework are presented in Table 5-4. No barriers were found for mapping the IFM framework to the proposed modelling approach. Table 5-4: Mapping between IFM framework and approach by Sakao and Shimomura (2007) Step

Related models/views Sakao & Shimomura IFM framework Initial interaction view Flow model (for initial set of actors) Actor state matrix (in Scenario model states view) Process flow view and Chain of actions associated actor view Detailed actor state Scenario model matrix View model with Detailed actor view realisation structure

Description

1

Making a preliminary flow model

2

Setting the goal of a scenario

3

Describing a chain of actions for service receivers

4

Identifying the goal parameter

5

Generating a realisation structure

133

Weilkiens (see Section 3.2.8) proposes a particularly detailed function modelling approach. Similar to Kruchten’s RUP (see Section 3.2.4) and the function modelling approach proposed in Company D (see Appendix D.III), central models from SysML/UML are proposed to facilitate conceptual design. In contrast to the latter approaches, Weilkiens proposes a highly iterative modelling approach, which clearly separates between an external and internal perspective on the system to be developed. Furthermore, function modelling is substantiated with state diagrams, which are not proposed by Kruchten or in Company D. In Table 5-5, the central proposed models are mapped to the views in the IFM framework. The differentiation between internal and external actors and processes can be similarly represented in the IFM framework using separate actor, process flow, or state views. However, alternatively, the IFM framework also allows for modelling both internal and external actors into the same model, if preferred by the designers. The position of the system border can be used to make the separation between internal and external entities explicit. As discussed in Section 3.2.8, the proposed function models by Weilkiens are complemented with block diagrams showing the initial system structure in SysML. These are to be modelled separately. The specific dependencies and bilateral impacts between the different actors can be integrated into the function model generated with the IFM framework by using the interaction view. Similar to the finite state machines discussed in relation to Dewey (2000), a new state/state view can be added to provide a more concise representation of different actor states and their transitions. Activity flow diagrams (and similar function models) may illustrate alternative process flows, e.g. in case of error scenarios. In the IFM framework these have to be modelled using alternative process flow views. Table 5-5: Mapping between IFM framework and approach proposed by Weilkiens (2008) Step

Related models/views Weilkiens IFM framework

Description

1

Modelling the context of the system to be developed; identifying external stakeholders and peripheral technical systems contributing to the system or otherwise interacting with it

2

Identifying and prioritising use cases and respectively involved users

3

Modelling activity flows related to the different use cases

4 5

Modelling specific interaction processes between sub-systems and users per use case Deriving and modelling system and user states and their transitions for the use cases

Block diagram, Use case schematic Use case schematic, use case activity flow model Sequence diagram, internal block diagram

Actor view Use case view

Process flow view with associated state view and actor view

State diagrams

Company A uses Grafcet-modelling (see Figure 4-5), in order to support conceptual design in electrical engineering and software development. The associated function modelling approach (see Appendix D.III) can be directly mapped onto different views proposed in the IFM framework. This is illustrated in Table 5-6. The central functions that are derived from the requirements list in an initial step, may simply be listed initially (as discussed in Section 5.2.5). Allocation of electrical components and their states can be conveniently represented combining the process flow view, state view, and actor view.

134

Chapter 5: A Framework for Integrated Function Modelling Table 5-6: Mapping between IFM framework and modelling approach proposed in Company A Step

Related models/views Company A IFM framework

Description

1

Determining central functions and sub-functions

Initial list of functions

Initial list of central functions

2

Establishing and modelling flow of functions

Grafcet

Process flow view

Circuit diagram

Actor view

Grafcet, circuit diagram

Process flow view, Actor view, Actors state matrix,

3 4

5

5.3.3

Determining initial set of electrical components associated to the functions Determining required states before and after each function (pre- and post-conditions) and design electrical ports accordingly to enable detecting the states of allocated electrical components in the system. Detailing of models and transfer of function flow into PLC programming environment.

Implications

The IFM framework is compatible with the reviewed function modelling approaches The presented comparison focused on how the specific contents, which are to be modelled in the proposed steps of the selected function modelling approaches, may be represented using the different views in the IFM framework. The determined sequences of mapped views are illustrated in Figure 5-17 for the exemplarily discussed function modelling approaches. Each diagram uses the different views related to the proposed sequence of steps as axes; the steps proceed from left to right. Circles represent combined modelling within multiple views. Iterations within and between individual steps are represented using dashed arrows. Associated views Interaction view

Hubka and Eder

Actor states matrix Actor view

Legend

Pahl et al.

Modelling step

Effect view

Iteration

Operand states matrix Process flow view

Use case view

Modelling steps

Dewey Spath and Demuss

Buur

Weilkiens

Company A

Sakao and Shimomura

Figure 5-17: Mapping reviewed function modelling approaches to the views in the IFM framework 135

The comparison once more illustrates the diversity of the reviewed modelling approaches from the different disciplines in terms of the proposed sequence and the specific entry points. No single modelling approach addresses all the views offered in the IFM framework. However, the performed comparison supports the claim that the IFM framework can be applied to support the reviewed function modelling approaches from the disciplines and across. The views may be applied in alternative combinations and sequences. All information addressed in the individual steps of the reviewed approaches can be directly represented in and mapped onto the different views in IFM framework. The only exception in this respect is the specific information about transitions between different use cases, as proposed by Buur (1990), which requires a slight adaptation of the framework. This and other suggested adaptations of the IFM framework are discussed in the following. Suggested adaptations of the IFM framework Adaptation of the IFM framework to the needs of designers in a specific situation is explicitly foreseen, in order to support demand-specific augmenting or tailoring (see Section 5.2.4). This may be achieved either by omitting views not required in a specific design project or expanding the framework with additional views. Alternatively, specific existing function models may simply be attached, as described before. Suggested adaptations from the conducted comparison comprise:    

representation of the transitions between use cases; providing a more concise representation of transitions between actor states; combining modelling of effects and processes into one view; presentation of alternative paths in a process flow in variant process flow views.

Modelling the transitions between use cases can support the analysis of dependencies and conditions for changing from one particular application of the system to another. This can be relatively easily added to the IFM framework by creating and including an additional matrix, e.g. a new use case/use case view. Such a view could potentially even go much further than what is proposed by Buur (1990), as any kind of dependencies between use cases can be modelled in such a DSM. In a similar manner, the concise representation of transitions between actor states can be realised in a state/state view as already implied earlier in this chapter. The separation between effects and processes in different views was deliberately chosen in the IFM framework. It is considered closer to function modelling applied in practice, as the specific classical function structures concerned here seem rarely applied in practice (see Sections 4.3.1 and 4.3.4). Nevertheless, transformation processes modelled in the process flow view may simply be exchanged or complemented by a set of effects, provided that they can be modelled related to (the same) flows of operands, which is exemplarily illustrated in Figure 5-15. The last issue concerns modelling alternative paths within a flow of processes. In the process flow view, process blocks are spread from left to right. The inclusion of alternative process flows into the process flow view can be realised by simply adding the corresponding process blocks as alternative, parallel processes on the right-hand side of the process flow view. This is indicated in Figure 5-18 for the coffeemaker example for the alternative path P’ “abort drink preparation”, which will be executed e.g. in case the user cancels the preparation of the ordered drink. However, for larger variants, alternative process flows will have to be modelled, which may be less convenient compared to e.g. use case activity flow models. 136

Chapter 5: A Framework for Integrated Function Modelling

TIME

P1: Coffee is ordered P2: heat water

P3: grind coffee beans

P': abort drink preparation P4: mix water and powder P5: fill drink in cup

P6: dispose of waste

Figure 5-18: Process flow view with potential alternative path P’ “abort drink preparation” All contents addressed in the reviewed function modelling approaches can be represented using the IFM framework. No fundamental changes were necessary in the analysis. The suggested adaptations facilitate the application of the framework in the discussed modelling approaches and were successfully applied while remodelling example models taken from these.

5.4 Summary and discussion The developed IFM framework is intended to provide designers with an interdisciplinary modelling approach that is capable of linking specific information about function modelling perspectives (and their dependencies) prominently addressed in the different disciplines. This information is represented and linked in the framework by using interconnected matrices, which represent different views onto the functionality of a system under consideration. In summary, the framework 







    

is based on the established concept of DSM and MDM, in order to provide a clearly structured representation and thereby facilitate modelling and analysing the functionality of (complex, interdisciplinary) systems; considers all identified function modelling perspectives and additional contents prominently addressed in function models from literature and found in practice, thus exceeding all other reviewed function modelling approaches; is expected to ease and facilitate communication across disciplines, as the different views are interlinked via a central view addressing process flows, which were found to be commonly prominent in function modelling within and across disciplines; is modular, in the sense that it enables addition or omission of views or specific information within them, in order to allow flexible adaptation (augmenting and tailoring) depending on the needs of designers in a specific design context29 and to delimitate modelling efforts; allows focusing on a limited set of modelling perspectives in each view, thus supporting quickly modelling and retrieving information relevant to an individual designer; (furthermore) allows switching flexibly between different views taken; allows different entry points and alternative sequences for function modelling; can address the functionality of a system on different level of detail or abstraction; finally, allows for inclusion of alternative function taxonomies or less restrictive formulations, depending on designers’ preferences or company requirements, guidelines and standards.

29

Here, context refers to the type of system to be developed, its maturity stage, and the specific methods and tools applied in other respects in a development project (after Gericke et al. 2013b).

137

The framework fulfils all the requirements listed in Section 5.1. In particular, it conciliates between having one single model integrating a set of information in contrast to using separate (partial) models complementarily representing the respective information, which was one of the key goals for the development. Furthermore, the selected setup in the framework is based on a flow in time, but nevertheless integrates flows of operands and any other information that was found in the function models from different disciplines (in literature and practice). The specific potentials for function analysis that originate from the matrix-based representation go beyond the formulated requirements and are expected to provide additional benefits to the designers. The possibilities for function analysis (particularly regarding malfunctioning analysis of existing systems, modularisation, and change prediction) may proof particularly valuable in redesign projects, as discussed before. Possibilities for flexible adaptation and application are specifically foreseen to allow utilisation of the framework in different disciplines and design approaches. The presented comparison to existing function modelling approaches substantiate the claim that the IFM framework is indeed interoperable with diverse modelling approaches proposed across disciplines and found in practice. The specific suggested adaptations can be relatively easily performed in the framework. Thus, it is presumably applicable in the disciplines without necessitating fundamental changes. Only, modelling alternative flows in variant process flow views may be less convenient in those cases, when particularly many alternative flows are relevant. The framework may generally be less attractive to designers who do not typically use flow representations of functions in their design process. Some of the interviewed designers in the empirical study, for instance, mainly apply simple function lists or state machines (see Section 4.3.5). It is aspired that the additional possibilities for modelling and analysing system functionality provided by the IFM framework will nevertheless inspire designers to look beyond the specific contents that they typically focus on and lead to increased interest in applying the framework.

5.5 Implications The Integrated Function Modelling framework was developed to satisfy the specific needs and requirements derived from the insights into function modelling obtained from the literature reviews and interviews in industry presented earlier in this thesis. By fulfilling these, the framework is expected to overcome the identified shortcomings of the reviewed modelling approaches with regard to supporting interdisciplinary conceptual design. The framework furthermore provides additional benefits to the designers, such as the possibilities for demand-specific adaptation and application, as well as relating between different viewpoints onto system functionality, which – because of the potentials for parallel function analysis – is expected to facilitate establishment of a comprehensive, shared understanding of the system. The modular character of the IFM framework may further support conscious selection of information to be modelled and thus to facilitate awareness about limitations of the created function model, which is another advantage over other existing approaches. Furthermore, the framework integrates all function modelling perspectives and provides traceability between system functionality on system level and the (discipline-specific) function carriers collaboratively implementing them. This is expected to enable consistent function modelling from system level to discipline-specific conceptual design. A review of current modelling techniques for system simulation suggests that the interaction view in the IFM framework provides links to selected tools for early system simulation and thus to models from later design stages (see Eisenbart et al. 2013a).

138

Chapter 5: A Framework for Integrated Function Modelling None of the reviewed function modelling approaches was found to provide a similar combination of possibilities and benefits. The framework is, hence, expected to provide designers with a highly valuable modelling approach capable of supporting joint function modelling and reasoning in (interdisciplinary) conceptual design. Because matrices are an established means for representation of information in practice, designers should be quickly able to work with the framework. The following chapter presents an initial evaluation of the framework based on feedback obtained in different companies and from academic partners.

139

6 INITIAL EVALUATION STUDY

6.1 Intention and research questions Empirical evaluation is required, in order to validate the usefulness and practical applicability of a developed support, as well as to identify eventual potentials for further improvement (Blessing and Chakrabarti 2009). The evaluation belongs to DS-II in the overall research approach and represents the final phase of this research project (see Figure 1-2). The developed IFM framework is intended to provide practicing designers with a modular, adaptable function modelling approach which is capable of integrating information about system functionality relevant within and across different disciplines. Through its specific setup it is intended to enhance joint modelling, analysing, and reasoning about functions in interdisciplinary conceptual design. Evaluation of the success of using the framework in interdisciplinary system development requires studying multiple design projects in different companies and design contexts, which is not feasible within the time available for this research project. The conducted empirical study presented in this chapter represents an initial evaluation of the potential usability and usefulness of the IFM framework. The study is guided by the following research questions: 1. Which specific contents and views in the IFM framework are considered useful, which are not considered useful for function modelling? 2. What is considered particularly beneficial and what are potentials for further improvement?

6.2 Study Design 6.2.1

Research method selection

The presented evaluation study mainly focuses on receiving feedback from practicing designers. These are expected to be able to assess the usefulness of the contents encompassed in the framework (Research Question 1) as well as to evaluate its benefits and potentials for further improvement with regard to its practical applicability during conceptual design (Research Question 2). In addition, feedback from researchers in academia is collected, in order to address Research Question 2 in relation to what they consider crucial for function modelling from a more theoretical point of view. Participants from industry should include specialist designers from different disciplines, as well as system-level designers and project leaders in different design contexts to ensure receiving broad feedback. This delimitates the realisable sample size due to their limited availability. Required efforts for the participants should be minimised. It was decided to use presentation workshops in which the IFM framework and its central characteristics are presented to practicing designers, who are then 141

asked to provide feedback. Such workshops allow the involvement of multiple designers at a time, thus increasing the realisable sample size. For collecting the feedback it was decided to combine questionnaires with open discussions. Questionnaires offer designers the possibility to give anonymous feedback, while the complementary discussions allow for clarification of eventual queries and issues raised during the workshops in detail (Blessing and Chakrabarti 2009, see also Section 4.2). Participants in academia should involve senior researchers, who have knowledge about a variety of existing conceptual design and modelling approaches in engineering design research. It was decided to use expert discussions to allow thorough exploration of the IFM framework and its central characteristics, and thus to obtain detailed feedback from the involved academic researchers. 6.2.2

Workshops in industry

The evaluation study with practicing designers, preparation, and post-processing essentially comprised four phases:    

preparation, including a pilot study, recruitment of participants, data collection, and data analysis.

Preparation Preparation of the workshops included generation of the questionnaire (see Appendix C.II) and preparation of the presentation to be used. The formulation of questions in the questionnaire was supported by feedback from two experienced researchers in the field of engineering design research. In addition, the designs of the questionnaire and the workshop were tested in a pilot study. The pilot study involved a strategic manager with a background in engineering design research, who had developed and introduced a shared function modelling approach for mechatronic systems in his company himself prior to this study. He was therefore considered suitable to give feedback on the IFM framework, the workshop format, and the questionnaire. Based on the received feedback, the questionnaire was slightly adapted to improve the formulation of some of the questions. Workshop participants For the study, a total of 19 participants from six companies could be recruited. Five of these companies had already participated in the interview study from DS-I (presented in Chapter 4). In addition, an expert from a sixth company could be recruited, who has a background in engineering design research with a focus on PSS. An overview of the companies is provided in Table 6-1. The order of companies in the table corresponds to their size. Company sizes vary between a small sized company with just below 30 employees, with an annual turnover of about 3.4 million € (in 2012) to a company with more than 275 thousand employees and an annual turnover of more than 114 billion € (in 2012). The companies further differ with respect to whether design teams are globally distributed or located on one site. Participants comprise specialist designers (n=10, including team leaders) from different engineering disciplines and service development, as well as system level designers (n=9), such as systems engineers and project leaders. Of the 19 participants 14 had already participated in the interview study presented in Chapter 4. The majority of participants (n=12) possessed professional experience of ten or more 142

Chapter 6: Initial Evaluation Study years, with a minimum of 4 years and a maximum of 23 years. A detailed overview of the profiles of individual interview participants is provided in Appendix B.I. Table 6-1: Overview of companies and participants involved in the study

Mechanical engineering

Electrical engineering

5

1

2

Aerospace

< 50

one site

4

D

Automotive

50 - 250

global

3

J

Manufacturing machinery

50 - 250

global

5

F

Automotive

> 250

global

1

Hydraulics and energy systems

> 250

global

1

H

new

2 1

1 1

System-level design

Σ participants

one site

Service design

Distribution of different design teams

< 50

C

Main market area Aerospace

Software development

Σ designers in company

Companies (from DS-I (see Table 4-1)

Participants’ disciplines

1 1 1

2 1

1

2 1

1

Data collection methods Apart from the questionnaires, data was collected by audio recording the workshops. In addition, the researcher took notes of statements that seemed particularly relevant. Audio recording and note taking enabled collecting additional feedback that was only provided verbally by the participants during discussions in the workshops. Recordings and notes were further used during data analysis to support comprehension of specific issues raised by the participants. Finally, all questions from the participants to the researcher during discussions and the provided answers were put into a catalogue after each workshop for use in subsequent workshops. This was performed to ensure that similarly posed questions would be answered in a similar way in all workshops. It was required in one case. Setup Overall, six workshops were conducted (one for each company), typically at the site of the involved companies. One workshop was conducted via an online conference tool that allowed sharing documents and presentations in real-time in combination with telephone conferencing. Participation was voluntary for all participants. They were introduced to the objectives and nature of the study and were informed about their right to discontinue participation at any time without consequences. Furthermore, the copies of the questionnaire were provided to the participants prior to the start, in order for them to carefully read the instructions and confidentiality details (see Appendix C.II). On average the workshops lasted about 90 minutes, with a minimum of 67 minutes and a maximum of 111 minutes. Workshop procedure The workshops started by introducing the participants to the general aims of the IFM framework and used concepts. In particular, the intention of integrating information relevant to different disciplines in adjacent, modular views using matrix-based representations was described. Subsequently, the central entities, their representation, and mutual relations in the framework were introduced. The same presentation was used for all workshops. Participants were encouraged to ask questions at any time, in order to clarify miscomprehensions early in the workshops. 143

After introducing the general concept of the IFM framework, the presentation moved to the individual views, which were successively presented. For each view, the represented contents were introduced based on an earlier version of the coffee vending machine example presented in Chapter 5. In addition, for each view, possible options in the representation and the specific links to adjacent views were explained. The order of the views in the presentation corresponds to their succession in Question 1 in the questionnaire (see Appendix C.II). Participants were asked to answer the questions about a particular view in parallel to the presentation of this view. After presenting each view, participants were encouraged by the researcher to ask questions to clarify any miscomprehensions in the presentation or the questionnaire. Furthermore, participants were encouraged to comment on each view (both in the questionnaire and by giving open feedback). After the presentation of all views, participants were given the possibility to consider the contents of all views again and write down any information, which they would have liked or considered useful, but which is currently not included in the framework (Question 2 in the questionnaire). Subsequently, possibilities to do function analysis using the matrix-based setup in the IFM framework were briefly introduced. Finally, the central characteristics of the IFM framework were summarised and specific properties, such as the modularity of the views and their adaptability, were highlighted. Again, participants were encouraged to ask questions. They also had the possibility to discuss in the group and give remarks on the IFM framework or the study as such after this final part of the presentation. Questions 3 to 5 in the questionnaire were to be answered after the presentation. 6.2.3

Expert discussions in academia

In addition to the workshops with practicing designers, feedback was obtained from four senior academic researchers not directly involved in this research. The researchers are active in engineering design research in the fields of design theory (n=2), PSS design (n=1), and software support systems for engineering design (n=1). The expert discussions were conducted in parallel to the industrial workshops. Feedback from three researchers was collected through one-to-one discussions while visiting them individually. Discussions lasted between 70 minutes and nearly two hours. In these discussions, the same presentation as in the industrial workshops was used to introduce the IFM framework. Note taking was used to capture the provided feedback. Feedback from the fourth researcher was obtained from his reviews of publications on the IFM framework and from repeatedly exchanging letters and emails. 6.2.4

Data analysis

Of the total of 19 participants in the industrial workshops 17 answered the questionnaire; two participants only provided feedback during discussions in the workshops. After completion of the workshops, for each company, the answers provided in the questionnaires were digitalised and put into spreadsheets. The verbal feedback from the discussions during the workshops was retrieved from the notes taken and the audio recordings. Different issues raised in the verbal feedback were scripted and added to the prepared spreadsheets for the questionnaires from the corresponding workshop. Based on an initial analysis, the raised issues were added to the specific questions that they referred to. That means, for instance, issues raised in the discussions about a specific view, were separately added to complement the comments provided in the questionnaires on this view. Because the questionnaires were answered anonymously, no person-specific analysis (e.g. related to disciplines or

144

Chapter 6: Initial Evaluation Study roles of participants) or direct comparison between the questionnaires and the verbal feedback from individual participants could be performed. The feedback received from the academic researchers was scripted and analysed similarly to the verbal feedback from the workshops in industry. Overall, the feedback received from practicing designers is very rich and builds the main data set for the findings presented in the following. Most of the issues raised in the researchers’ feedback were also raised in the feedback from the practicing designers. Therefore, wherever applicable in the following sections, the (additional) issues raised by the experts from academia are added complementarily to the feedback from the practicing designers.

6.3 Findings The following section (Section 6.3.1) describes the findings related to Research Question 1. Subsequently, the findings related to Research Question 2 are presented in Section 6.3.2. 6.3.1

Contents and views considered useful in the IFM framework

Research Question 1 is addressed using the answers provided to Questions 1 and 3 in the questionnaires (see Appendix C.II), as well as the discussions in the workshops. Therein,  

Question 1 asks participants to indicate which of the represented “elements and aspects [in the different views] are considered useful” for their work; Question 3 asks participants to indicate in the provided picture which “particular views and links are considered useful or not useful”.

As discussed before, participants could further use the comment boxes in Question 1 to give additional feedback on the individual views. In Question 3, only in 5 out of the 17 returned questionnaires assessments of the links between views were provided, which prevents evaluation of their usefulness. Assessments of contents A total of 23 distinct elements and aspects (referred to as contents in the following) represented in the IFM framework were to be assessed by the workshop participants in Question 1. Overall, the assessments of the contents in the different views are very positive. Of the 17 returned questionnaires 16 considered 13 or more of the 23 contents to be useful; in twelve questionnaires even 17 or more contents were considered useful. Every single content was considered useful by at least eight participants. The specific combinations of which contents are considered useful or not useful vary considerably between the questionnaires. No combination occurred more than once. The minimum amount of contents considered useful is nine (n=1 questionnaire); the maximum amount is 22 (n=2 questionnaires). Only in eight questionnaires specific contents were marked to be considered not useful, with a minimum of one (n=2) and a maximum of five (n=3). In all but one questionnaire, specific contents were marked with “don’t know”, with a minimum of one (n=2) and a maximum of nine (n=1); in the majority of eleven questionnaires “don’t know” was selected for four or less contents. In five questionnaires, for a few contents no answer was provided by the respective participants: in three questionnaires for one content (n=1) and two contents (n=2), in the remaining two questionnaires for four contents and nine contents, respectively. Figure 6-1 illustrates the distribution of the provided assessments for each content in the different views. 145

considered useful

not considered useful 0

1

2

don't know 3

4

5

6

no answer provided 7

8

9

10 11 12 13 14 15 16 17

Process flow view

Technical processes Human processes Sequence/parallelism of processes Alternative flows of processes Quantities and/or Constraints

Actor view

Concerned stakeholders Concerned technical (sub-) systems Impacts on/from the environment Separating internal and external actors

Effect view

States view

Use case view

Roles of individual actors (e.g. as supporting.) Use cases (in general) Involvement of processes in multiple use cases Dependencies between alternative use cases Actor states Operand states Processes related to state changes

Physiochemical effects Effects related to different processes

Interaction view

Mutual impacts between actors General relations/ dependencies between actors Impacts between actors and operands Mutual impacts between operands Interfaces between entities (operands, actors)

Figure 6-1: Assessment of contents addressed in the IFM framework (n=17) The questionnaire in which no answer was provided to nine of the contents is particularly notable. Contents were either marked to be useful (n=14 contents) or no answer was provided, no other kinds of assessments (i.e. not considered useful or “don’t know”) occurred. The questionnaire comes from the newly recruited expert, who was also the only participant in his workshop (see Table 6-1). In one of the comment boxes in Question 1 he wrote that he was not sure how to assess some of the contents. He explained that he knew that these contents are important to some of his colleagues, and thus potentially also to him during collaborative design projects. It seems, he decided only to give an assessment for those specific contents that he was sure about to be useful. Two more participants in two other workshops verbally expressed similar difficulties during the assessments of the contents. One of those participants comes from the other workshop with only a single participant (in Company F). In his questionnaire a relatively high number of contents (n=6) were marked with “don’t know”, which is most likely related to the remarked uncertainty. The questionnaire in which for four contents no answers were provided comes from the workshop in Company C. No explanation was provided in the questionnaire; however, in the questionnaires from two of his colleagues, the same contents were 146

Chapter 6: Initial Evaluation Study marked with either “don’t know” or were marked to be considered not useful. This suggests that these specific contents are either not particularly relevant to the three participants or that they are generally not familiar with them and, therefore, they were not sure what to select in the assessment. For the remaining questionnaires in which no answers were provided to specific contents or contents were marked with “don’t know”, similar explanations may apply. Alternatively, participants may not have been able to understand all contents from the presentation; however, no such remarks were made during the workshops. Assessments of views Of the total of 17 returned questionnaires 14 provided answers to Question 3. In a striking majority of 13 of these 14 questionnaires at least half of the six views in the IFM framework were considered to be useful, with a maximum of six (n=2 questionnaires). In one questionnaire only two views were considered useful. Six participants considered one view (n=5 participants) or three views (n=1) to be not useful. Eight participants selected “don’t know” for one or more views (see Figure 6-2). Similar to the assessments of the contents, the specific combinations of which views are considered useful or not useful vary considerably between the questionnaires and only two combinations occurred more than once (twice and three times, respectively). Figure 6-3 illustrates the distribution of the provided assessments for each view.

3

2

Number of views marked with "don't know" Number views not considered useful Number of views considered useful

1 5

3

5

4

2

1 0

1

2

3

2

4

5

6

Figure 6-2: Amount of views (max. 6) assessed useful or not useful in the questionnaires (n=14)

considered useful 0

2

4

not considered useful 6

8

don't know 10

12

Process flow view Actor view

Use case view State view Effect view Interaction view

Figure 6-3: Assessments of views encompassed in the IFM framework (n=14)

147

14

One of the three participants who did not answer Question 3 wrote as an explanation in his questionnaire that he had difficulties deciding on an assessment for the views, because – based on his experience – not all the contents and thus not all views are relevant in all projects. In Question 1 the person had selected 22 of the 23 contents to be useful. This suggests that this participant – in principle – nevertheless considered all views to be useful, though simply not in every single project. For the other two participants who did not answer Question 3 no explanation was provided in the questionnaires or could be found in the audio recordings. However, one of them considered only the contents in the actor view, use case view, and effect view to be useful. All other contents (except for the “technical processes” in the process flow view) were marked with “don’t know” (n=9 contents) or considered to be not useful (n=5, all in the interaction view). This selection suggests that the participant may have been critical or not certain about large parts of the IFM framework in its current setup and therefore was not sure how to assess the views and their links in Question 3. Discrepancies of assessments provided to Question 1 and Question 3 Contents addressed in the process flow view, the state view, and actor view are considered useful the most number of times by the participants (see Figure 6-1). This corresponds to the assessments of the views (Figure 6-3) in the sense that those three views were also selected useful the most number of times. Similarly, the effect view is considered useful the least number of times in Question 3 which corresponds to the assessments of its contents in Question 1. For the use case view, both the represented contents and the view as such were marked with “don’t know” relatively often (see Figure 6-1 and Figure 6-3). Use cases primarily originate from software development and are not particularly prominent in other disciplines (see also Section 3.2). Participants from other disciplines may not be entirely familiar with use cases and thus were not sure what to select in Question 1 and Question 3. There are a few slight discrepancies between the amounts of participants that assessed specific contents of views useful in contrast to the number of participants that assessed the associated views useful. This is particularly notable for the effect view: while up to nine participants regarded specific contents addressed in the effect view useful (see Figure 6-1), only four considered the view as such useful, i.e. five questionnaires show a discrepancy in the assessments. For two of those five no explanation could be found. Two more participants did not answer Question 3; however one of them explained that he considered all views useful nevertheless, as discussed before. Finally, the fifth participant provided a concrete explanation in the questionnaire for his selection. He stated that the contents in the effect view were considered to be very useful; however, he would have preferred them to be integrated into the process flow view, which is why he did not select the effect view useful in Question 3. Slight deviations can also be found for other views. Where this occurred, participants only considered selected contents within views useful. However, no direct link could be found between the number of contents considered useful or not useful in a specific view and whether this view is considered useful or not by a participant. Influences for provided assessments The findings suggest that the specific combinations of which views and inherent contents are assessed useful in the IFM framework are strongly dependent on the individual participants that answered the questionnaires. No particularly apparent groups could be differentiated based on the provided answers in Question 1 and Question 3, which would suggest a specific accumulation in relation to disciplines or roles of participants. This may have been due to the relatively small sample size of 19 148

Chapter 6: Initial Evaluation Study participants in the industry workshops. Only the received verbal feedback during a few of the workshops suggests a certain influence on the assessment of the usefulness of views, coming from  

the discipline a participant is associated to and the conceptual design approach applied in a company.

An influence from the discipline that a participant is associated to is suggested in discussions of the effect view. In Question 3, six participants explicitly selected the effect view not to be useful (four more participants selected “don’t know”, see Figure 6-3); however, at the same time, two participants in two workshops (Company J and Company F) explicitly argued during the discussions that they regarded this view to be one of the most beneficial in the entire framework. The single participant from Company F also provided comments in the questionnaire that emphasise the importance of the effect view to him. Both participants have a background in mechanical engineering and the contents in the effect view also mainly originate from mechanical engineering literature (as discussed in Section 3.2.9). This suggests that – at least for the effect view – a participant’s disciplinary background can have an influence on the expected usefulness of a view. This is supported by verbal feedback from an electrical engineer in Company D. He explained that the contents in the effect view are not particularly relevant to himself, but that he knew his colleagues in the mechanical design department are working with such information in some of their projects. Other participants may also have had particular disciplinespecific preferences for specific views; however, they were not expressed. A larger influence is suggested for the conceptual design process applied in a company. This was particularly evident in two workshops (Company C and Company D). During the workshop in Company C three of the five participants repeatedly said during the discussions about individual views that to them the interaction view is the most important view and that they would want to use it as entry point for function modelling with the IFM framework. Currently, the company uses a matrix-based model, quite similar to the interaction view, for the representation of the structure of a system under development. This system structure is typically used as starting point for conceptual design in the company, as a newly developed system can frequently be derived and adapted to a large extent from a previous system generation (as already discussed in Section 4.3.2). Furthermore, the model, thus far, also serves as a central document for the definition of the development duties of the different departments in the company. In Company D, two of the three participants similarly expressed that – based on their current conceptual design approach – to them the use case view and states view would be particularly important and used as entry points to modelling with the framework. 6.3.2

Benefits and potentials for further improvement

Research Question 2 is addressed using the answers provided in the comment boxes for each view in Question 1, the answers provided to Questions 2, 4, and 5 in the questionnaires, as well as the verbal feedback obtained during the discussions in the presentation workshops and expert discussions in academia. Therein,  

Question 2 asks participants to indicate any additional “information they would have liked or considered useful” in the framework; Question 4 asks participants whether they would “consider using the framework in future design work” and provide an explanation for their selection;

149



Question 5 asks participants whether they would “generally prefer an alternative setup (to the concept of associated, modular views) or representation for the framework” and whether they had “any other comments”.

The comments provided to Questions 4 and 5 in the returned questionnaires are to a large extent overlapping so that both questions were jointly analysed30. Expected application of the IFM framework in future design work In all 17 returned questionnaires the first part of Question 4 was answered positively (see Figure 6-4). The large majority (15 out of 17) either stated to be willing to use parts of the IFM framework (e.g. a selection of views or specific contents only) or would be willing to apply it, provided that certain adaptations are implemented, e.g. concerning the addition of specific contents to a particular view. 12% 59%

Yes (n=2)

29%

With adaptations (n=5) Parts of it (n=10) No (n=0)

Figure 6-4: Provided answers to Question 4 (n=17) The two participants that selected “yes” come from the same company. Both assessed a high number of contents and views (one even all views) in Questions 1 and 3 to be useful. Overall, both these questionnaires and the questionnaire of a third participant from this company (who selected “parts of it” in Question 4) were among the most favourable in the entire study and also provided very positive comments. Expressed benefits of the framework are discussed in the following section. However, the fourth participant from the company was the person that considered the least number of contents to be useful in the entire study (n=9 contents). He also selected “parts of it” in Question 4. As discussed before, no further explanations or comments were provided by this participant. Of the five participants that selected the “with adaptations” box in Question 4, three also described specific adaptations in the second part of Question 4. They are discussed in detail in the following sections. Two participants did not suggest specific adaptations; however, both participants expressed concerns that the matrices in the framework may quickly become rather large and complex. Their selection in Question 4 thus seems to express the desire that the framework may be adapted in a way to address this issue. A similar concern was expressed by one of the ten participants who selected “parts of it”. Overall, only three of the ten participants in this last group also provided concrete 30

While several issues were repeatedly suggested in different workshops (either expressed verbally or in the questionnaires), others originate from a few participants only. Nevertheless, all raised issues are equally considered in the following, as other participants may have had the same thoughts, but did not express them, e.g., because another participant already did. The quantities provided in the following, therefore, are only to be considered as rough indication of the prevalence of an issue rather than as absolute values. They originate from the number of questionnaires or number of participants giving verbal feedback. In two workshops, a specific issue was raised both during a discussion and in questionnaires. As it is not possible to trace the questionnaires to individual participants, in these cases, the respectively higher number was counted, i.e. either the number of questionnaires or participants verbally raising a specific issue. This could potentially make a difference of two persons regarding the issue of complexity (i.e. n=6 instead of n=5) and the benefits expressed in relation to doing function analysis with the framework (i.e. n=8 instead of n=7) discussed in the following.

150

Chapter 6: Initial Evaluation Study explanations for their selection. The two other participants simply stated in the questionnaires only to require selected contents in the framework for their conceptual design work. The expressed benefits, additional contents, and desired adaptations discussed in the following are derived from the comments in the questionnaires as well as from verbal feedback provided during the workshops in industry and discussions with the academic experts. Expressed benefits Aspects that the participants expressed to be particularly beneficial comprise:    



clarity of the representation of contents and their relations in the framework (n=1); the matrix-based representation as being open to represent any kind of dependencies between entities in a system, also making it potentially applicable for business modelling (n=1); representing aspects of system functionality in relation to a time flow (n=2); making explicit the links between components that are developed in different departments, which may support exchange in the project management team as well as planning of disciplinespecific and collaborative design tasks (n=2); options for function analysis of a system (n=7), particularly referring to - analysing the impacts from and to the environment (n=2), - consistency and completeness analysis while gradually detailing the function model of a system (n=2) or in order to facilitate change management (n=1), - analysing the time-dependencies between functions (n=2), - modelling and analysing interconnections and dependencies between actors (n=3).

Just over half of the participants from industry (n=10) explicitly provided positive comments. In particular, the possibilities that the matrix-based representation in the IFM framework offers in terms of easing function analysis were considered highly beneficial by the practitioners and were also highlighted as beneficial by all four academic researchers. One of the practitioners further explained during a discussion that the combination of gradually filling the views in the framework and the possibilities for parallel analysis of the entered contents – to him – seems to be a substantial contribution to building a comprehensive and shared understanding of the system in the design team. The academic researchers generally considered the use of matrices for representation of the different aspects of system functionality to be novel and the clearly structured representation to be a considerable support for modelling and retrieving information in function modelling. Furthermore, the explicit interrelation of the entities across different matrices was considered particularly beneficial by all academic researchers, also because further entities may be included if considered useful in a specific design project. This corresponds to a large extent with the second above-listed issue. The third issue, i.e. the time flow of processes as central means for the representation of system functionality, was highlighted as particularly beneficial by the academic researcher involved in PSS design. The floworiented representation was considered beneficial, as it allows for associated analysis of which specific interactions and dependencies (such as the bilateral impacts) between individual actors are relevant at which point in time during function fulfilment. Finally, one of the academic researchers explained that – in his view – the combination of actor states with operand states in the state view, as well as their direct visual relation to the processes creating eventual state changes in the process flow view, is novel. This information is typically distributed over 151

different (partial) models in existing modelling approaches and he considered their combination in the framework as a considerable benefit. Furthermore, this researcher saw the combination of function modelling with an initial system structure (i.e. the interaction view) as highly beneficial and novel. Participants from two companies furthermore expressed interest in applying the framework in the future. In one of them, participants explicitly suggested implementing the framework in one of their upcoming projects. Desired additional contents Four participants from industry further expressed a desire for additional contents in the framework; they mentioned the following:   

making explicit the relation to the requirements (n=1); making explicit the conditions for function execution (n=1); illustrating the chronological sequence of use cases (n=2).

Making explicit the links between requirements and the different entities in the framework may facilitate top-down traceability from requirements to functions, as discussed in Section 4.3.3. The second issue refers to making explicit that some functions cannot (or should not) be executed unless specific (pre-)conditions are fulfilled. The participant explained that this may be useful, for instance, for safety-critical functions and could be indicated in the process flow view. The third issue was verbally raised by two system-level designers in Company H. The company develops mechatronic systems in the aerospace industry. Both participants expected benefits from the inclusion of sequences between use cases, in order to make explicit what is required from the system under development at which phase of its life-cycle. This was considered important during system operationalization. The inclusion of chronological sequences between use cases was also suggested by the academic researcher who is active in PSS design. Desired adaptations Desired adaptations and related issues raised in the workshops encompass:    

matrices may not be the most suitable representation for all designers (n=1); additional guidance on how to take decisions on the design of the system while modelling with the IFM framework may support conceptual design (n=1). evaluation of variants in the flow of processes should be facilitated more strongly (n=2); the framework may become very large and complex, if modelled for an entire system (n=2), - support is required for managing modelling complexity (n=2), - guidance should be provided in terms of how to make “trade-offs” between the contents to be modelled in the framework for a particular design project and the required modelling efforts (n=1);

The first issue was raised by the participant who also requested the integration of the information represented in the effect view into the process flow view, which was described before. This suggests that this participant is rather critical of the current setup of the IFM framework. Looking across all answers in this participant’s questionnaire, it seems, this person would have preferred a more condense representation similar to classical function structures from mechanical engineering (e.g. 152

Chapter 6: Initial Evaluation Study after Pahl et al. 2007). As discussed in Section 5.3.2, the IFM framework can be used to represent functions in a similar way (see also Figure 5-15). Overall, this participant and the one that considered the least number of contents to be useful seemed generally critical of the current concept of the IFM framework, although it was not explicitly criticised in the questionnaires or during discussions. The third issue was expressed by a systems engineer and also by one of the academic experts who explained that by facilitating early comparison of alternative paths, the designers might be able to dismiss less suitable solutions early in the process. This was expected by both the practitioner and the academic researcher to become particularly important in design processes with a considerably large solution space, such as in mechatronic system development and PSS design. The issue of complexity in modelling with the IFM framework seems to be of major concern. Participants from different companies expressed this specific concern and the desire for a support regarding how to manage modelling complexity and make trade-offs with respect to included contents and time required for modelling. Concerns about the complexity of the modelled matrices were similarly expressed by two academic researchers. An additional issue raised by a senior researcher concerns allowing alternative differentiations between the actors in the IFM framework. He expressed that it should be possible, for instance, to sub-divide stakeholders and technical sub-systems further, if preferred by the designers. As already discussed in Section 5.3.2, this can be relatively easily enabled in the IFM framework.

6.4 Discussion The specific intention behind the development of the framework has been to provide designers with a flexibly adaptable function modelling approach that is capable of integrating information about different aspects of system functionality, which are prominently addressed in function modelling within and across different disciplines. The presented initial evaluation study, involving practicing designers from different disciplines and experts from academia, tried to explore the expected usefulness and benefits of the IFM framework, as well as potentials for further improvement. 6.4.1

Limitations

Limitations of this study are essentially twofold:  

the intelligibility of the questionnaire and the presentations, as well as the limited number of participants.

The intelligibility of the questionnaire was tested and improved using feedback obtained from other researchers and during the pilot study. In addition, participants were encouraged repeatedly during the workshops to ask for clarification of questions and the presentation when needed. It is a general impression of the researcher that the participants were able to understand the presented concepts quickly. Participants frequently started asking rather specific questions about concrete aspects of the framework early during the workshops, which suggests that the presentation has been suitable to communicate the characteristics of the IFM framework. The limited number of participants prevents generalisation of the obtained insights. However, the received feedback is highly valuable and led to the identification of concrete potentials for further 153

improvement. Central aspects of the received feedback surfaced in different companies and similarly in the feedback from academia, which gives confidence in the presented findings. A general limitation of feedback-based evaluation studies is that – for various reasons – participants sometimes may feel reserved to express criticism (see Blessing and Chakrabarti 2009) or may have been influenced by an acquiescence bias (see Watson 1992). In the study, it was attempted to minimise both these effects by giving the participants the possibility to remain anonymous in the questionnaires. 6.4.2

Modularity and possibilities for function analysis are particularly beneficial

Overall, the received feedback on the IFM framework is very positive. The large majority of participants considered the different contents and views in the framework to be useful and no participant rejected using the framework in future design work in principle. None of the participants considered the central process flow view to be not useful; in fact, the view and its contents are considered useful the most number of times in the returned questionnaires. This can be regarded as a particularly positive, insofar as the process flow view is constitutive to the framework and its current setup. The found diversity in relation to which specific combination of views and contents are considered useful supports the earlier discussions that adaptability is required for function modelling with the IFM framework. The study suggests that, depending on the project at hand (although this was only suggested by one participant), as well as the disciplines, personal preferences, and the applied conceptual design approach of the individual designers, different combinations of views and individual contents will be relevant. This corresponds to the insights obtained from the studies in the DS-I phase (see Section 4.5). The possibilities for augmenting and tailoring of the framework (i.e. adding or omitting specific contents or entire views) in relation to the requirements or preferences of designers in a specific situation have explicitly been foreseen for this particular reason. The IFM framework is therefore considered suitable for application in different companies (i.e. in different conceptual design processes) and by different designers. The accented modular character of the framework is considered an advantage over existing approaches (see Section 5.5), as it enables the required adaptability. The benefit of the modular matrices is substantiated by the expressed positive feedback regarding the possibilities that the matrices offer to do function analysis. All views and contents are considered useful by a multitude of participants and no other function modelling approach was found to address a similar amount of function modelling perspectives (see Sections 3.3 and 5.4). Based on the insights from the evaluation study, the IFM framework may indeed provide a high potential for the support of function modelling in interdisciplinary conceptual design. As discussed before, one company expressed interest in implementing the framework in one of their upcoming projects. Due of the significant efforts (both regarding time and costs) required from a company for the implementation of a new modelling approach, this is a strong indicator that the company expects the IFM framework to provide a considerable benefit. 6.4.3

Potentials for further improvement

Desired additional contents The requested inclusion of conditions for function execution seems relatively easily realisable in the IFM framework. The corresponding process blocks may simply be expanded with a short textual note (similar to the optional quantities and constraints, see Figure 5-4) or required pre-conditions may be 154

Chapter 6: Initial Evaluation Study specially marked in the state view. In comparison, making explicit the links between requirements and aspects of system functionality represented in the IFM framework will require additional research. The benefit for making these links explicit lies in particular in advancing top-down traceability during conceptual design, as discussed in Section 4.3.6 and earlier in this chapter. However, adequate visualisation of the links is expected to be depending on how the requirements are documented in a company and which of the specific contents in the IFM framework they relate to. Further research is needed in order to determine adequate support for this step. The chronological sequence of use cases may similarly require additional research. In the described application of the IFM framework (see Section 5.2.5) this issue was already briefly addressed. However, explicit visualisation of sequences between use cases – so far – has not been implemented, as it was considered difficult to predict the sequences of different use cases a-priori in the development of a new system. In the example of the coffee vending machine provided in Chapter 5, for instance, it would be hardly possible to apprehend the sequence in which the use cases of preparing coffee or preparing cappuccino, etc. will be executed. Further research is required to determine how such a sequence can be adequately visualised and to which specific level of detail it is sensible to do so. Desired adaptations The evaluation of variant process flows and their representation was already discussed as potential expansion of the framework in the previous chapter. Due to the feedback received in industry and academia, this issue should be addressed and supported in the future. The most critical issues, however, concern modelling complexity, the requested additional support regarding adaptation of the framework to the requirements of individual designers in a specific situation, as well as taking design decisions while gradually moving towards a solution concept. The framework addresses the largest amount of function modelling perspectives going beyond any other reviewed modelling approach. The inherent matrices may thus become large rather quickly. DSM or other matrix-based modelling methods such as Quality-function deployment (QFD, see e.g. King 1989) are widely applied in engineering practice. These also frequently yield rather large matrices; they are nevertheless widely applied in design practice (as suggested by Eckert 2013). There is no reason, why this should not similarly apply to the IFM framework. Furthermore, adaptation of the IFM framework is explicitly foreseen, in order to support delimitating and focussing modelling efforts on only the required information about the system under development. In light of the received feedback, further development of the framework should nevertheless focus on developing specific guidance and other supporting measures (e.g. checklists and training material) for applying and adapting the framework in a specific design project. Further research is needed to determine which specific contents need to be included in order to gain benefit from the framework, while at the same time being able to manage modelling complexity and limiting modelling efforts. These parameters and their implications for the IFM framework will have to be studied in more detail, in order to determine and develop adequate support. In order to address the issues of complexity and modelling efforts, one potential supporting measure may be the development of a supporting software tool implementing the IFM framework. The matrixbased structure is expected to be easily transferrable into such a tool. A potential benefit could be automated placement of information into respective matrices, as soon as it becomes available. This could reduce modelling efforts considerably. 155

7 CONCLUSION

7.1 Summary 7.1.1

Goals and fundamental research questions

Interdisciplinary system development requires the integration of diverse expertise to combine different engineering technologies and – increasingly often – services, in order to provide users with expected value and desired functionality. The overall goal of the presented research has been the development of a function modelling approach, which is capable of facilitating integration of different design disciplines early in the development process. An adequate support for integrated function modelling is expected to enhance the establishment of a shared system understanding among collaborating designers and is eventually expected to support the exchange of expertise between disciplines, as well as shared function reasoning towards a potential solution concept. This specific goal raised two fundamental research questions: RQ I. RQ II.

7.1.2

What are barriers for integrated function modelling? How to support integrated function modelling, in order to enhance the establishment of a shared understanding of the interdisciplinary system under development among collaborating designers?

Main results

The research questions have been addressed using comprehensive literature reviews (see Chapters 2 and 3) and interviews in ten companies developing mechatronic systems and PSS in the areas of aerospace, automotive, telecommunication, and machine design (see Chapter 4). The literature reviews specifically focused on investigating function models and function modelling approaches proposed in disciplinary and interdisciplinary design approaches. The derived findings are complemented by the interviews with practicing designers exploring which function models are actually used in practice and how they are applied. In particular, good and bad experiences made with applying (and introducing) function models in practice were investigated, as well as specific needs and preferences of interviewed designers in relation to (interdisciplinary) function modelling. Interviewees comprise designers from different engineering disciplines and service development, as well as systemlevel designers, such as systems engineers and project managers. The insights obtained from the interview study support the initial assumption that shared function modelling can enhance interdisciplinary conceptual design. Introduction of shared function models in several companies was found to have facilitated the exchange of information among collaborating designers (from different disciplines), which – in turn – led to an improved shared understanding of 157

the system to be developed (see Section 4.3.6). This applies to the collaboration between designers from different engineering disciplines as well as their collaboration with service designers. One company claimed to have reduced development time by up to 30% for some of their sub-systems, due to the introduction of shared function modelling on system level, which is a strong indicator for the usefulness of shared function modelling to facilitate interdisciplinary design. However, in spite of the advances achieved in some of the companies, the designers still reported to be experiencing various difficulties in interdisciplinary conceptual design and the need for further support in cross-disciplinary function modelling remained. Barriers for integrated function modelling Function as a concept is diverse. Both in literature and the visited companies, a multitude of notions of function, function models, and function modelling approaches could be found within and particularly across different disciplines. Function models are specific with respect to the addressed contents (i.e. function modelling perspectives) and used modelling morphologies. Practicing designers tend to reason about functions in a rather flexible manner while gradually moving towards a potential solution concept (see Sections 2.5.3 and 4.3.2). Which function models and modelling steps are applied was found to be strongly depending on the preferences of individual designers, the disciplines they are associated to, and the design context, i.e. the system to be developed and the conceptual design approach used (see Sections 4.3.4 and 6.3.1). The differences in addressed function modelling perspectives, different modelling morphologies, and the deviant application of function models by different designers were identified as central barriers for shared function modelling. As a consequence, different function models are insufficiently linked and do not adequately support a consistent exchange of information between collaborating designers. None of the found models addressed all function modelling perspectives relevant to designers in different disciplines. Alternative function models remain to be used by individual designers, even if a shared function model (on system level) exists in the company. Because the different models used in the company are insufficiently linked, modelled information is frequently inconsistent between them, which can lead to design errors and iterations in the design process (see Section 4.3.8). A support for integrated function modelling – the IFM framework The obtained insights from both literature reviews and interviews furthermore led to the identification of specific opportunities which may support integration between different function models (see Sections 3.3.3 and 4.3.4). Several interviewees highlighted that supporting traceability between functions and solution elements as part of a shared function model has helped fostering system comprehension in the design team. This was further found to facilitate the exchange of information between collaborating designers. Based on these insights, specific needs and requirements guiding the development of an integrated function modelling approach were derived (see Sections 4.5 and 5.1). The result is the Integrated Function Modelling (IFM) framework (see Figure 7-1) that is intended to link all information about function modelling perspectives and their dependencies. The framework uses a different kind of representation, which is based on the concept of Design Structure Matrices (DSM). This is intended to evade the problem of incompatibility between different models, as it allows for representation and relation of manifold contents. The matrix-based setup in the IFM framework further enables application of established analysis methods (see Section 5.2.6). Depending on the specific design context and disciplines involved in system development, alternative combinations of 158

Chapter 7: Conclusion

State view

TIME

USE CASES

the views in the framework may be required and modelled in different sequences. The framework explicitly allows for such need-dependent adaptation and application (see Section 5.3). Adaptation includes augmenting, i.e. adding further information or depth in the description of represented entities, as well as tailoring, i.e. omitting individual views or specific contents, if not required in a specific design project.

ACTORS OPERANDS

PROCESSES

Process flow view

Effect view

PROCESSES

OPERANDS ACTORS

Interaction view

Use case view

Actor view

Figure 7-1: Schema of the developed Integrated Function Modelling framework The developed modelling framework was initially evaluated through feedback obtained during workshops with practicing designers in industry, as well as from expert discussion with senior researchers in academia (see Chapter 6). The received feedback is very positive, supporting the large potential of the framework to support interdisciplinary conceptual design. In particular, the clearly structured representation and the ease of performing function analysis are considered highly beneficial by the participants in the evaluation study. The IFM framework results in an initial system structure or an interface matrix, respectively, which allows for linking the framework to established models used in later design stages and even offers potentials for a consistent transition to selected techniques for early system simulation. Further evaluation is on-going and comprises application evaluation with students and designers in industry. Initial insights confirm the potential for the support of integration of different disciplines. Involved practicing designers described the framework to be very close to industrial design practice and to be quickly learnable. The IFM framework has been successfully applied for function modelling of different real-life examples as part of on-going research. This includes an electrically controlled vehicle cooling system (performed by practitioners in an automotive company) as well as a commercial Quadrocopter (as part of on-going research at the University of Luxembourg).

7.2 Contributions Apart from the development of the IFM framework, central contributions of the presented research project concern both research into function and function modelling across disciplines, as well as (interdisciplinary) design practice. This is discussed in the following sections. 7.2.1

Regarding engineering design research

Function modelling and function reasoning are (and have been) central topics in the international engineering design research community. Function as a concept is vividly discussed by researchers in a 159

multitude of research areas associated to engineering design. The provided review of different notions of function from literature and from practice are expected to contribute to this on-going discourse. The presented research is particularly novel as it extends the scope of investigation of function and function modelling to cover multiple disciplines and design contexts. In particular, the specific application of concrete function models on different levels of participation in the course of interdisciplinary conceptual design are expected to provide researchers with valuable insights beyond the limits of this research project. It should be a starting point for an increased interest in function modelling across disciplines. The concept of integrated function modelling to support interdisciplinary conceptual design is still novel in engineering design research. The project contributed to general knowledge on function modelling, which – in turn – can contribute to the development of further support for conceptual design in practice. In particular, the identified distinct function modelling perspectives and related findings from the review of found function models provide the basis for the comparative analysis of function modelling irrespective of disciplines. The contribution of this specific analysis to on-going research on function modelling in the engineering design community has been repeatedly highlighted as very valuable by several academic researchers. 7.2.2

Regarding function modelling in practice

The IFM framework is intended to support collaboration in interdisciplinary conceptual design, which is necessary to cope with today’s challenges in system development. Feedback received from designers in industry is very positive regarding the practical applicability of the IFM framework, whereas classical function modelling approaches are often regarded to be too abstract to be providing a benefit to actual design work. The results from this research project are expected to have an effect on design practice in industry, particularly because of the established collaborations with experts in different companies. In the evaluation study, participants from two companies expressed the intention of implementing the framework in their design team. Further collaboration regarding future research on the IFM framework is foreseen. None of the reviewed function modelling approaches proposed in literature or observed in industry were found to address all identified function modelling perspectives, information about the links and dependencies about functions (conveyed in different modelling morphologies), and additional contents prominently addressed in function models across disciplines. The differences in represented information and used morphologies were identified to be a central barrier for the integration of different function models. From this it follows that, because all modelling perspectives and morphologies are relevant to different designers, different function models remain to be used in the companies and, therefore, consistent modelling of system functions on system level and disciplinary design is hindered. The IFM framework addresses this issue and integrates all information prominently addressed in disciplinary and cross-disciplinary function modelling. This, in combination with the provided links to system modelling in later design stages, as well as the offered possibilities for flexible, adaptable modelling and analysing system functionality, are particularly novel. These possibilities are not provided in a similar manner by any other reviewed function modelling approach. The IFM framework is thus expected to provide a considerably benefit for function modelling in (interdisciplinary) design practice. The expressed intention of participants in the evaluation study to implement the framework in their company is a particularly strong indicator for this expected benefit.

160

Chapter 7: Conclusion

7.3 Review of research approach The central contribution of this research project is the development of the IFM framework based on comprehensive reviews of function modelling approaches proposed in literature, as well as on the interviews in the visited companies. Recruitment of participants, interview execution, and their analysis required more time than expected and delimitated the realisable sample size. Alternative research methods, such as online questionnaires, may potentially have provided insights from more companies and participants; nevertheless, the collected data provided compelling insights, which supported the researcher’s comprehension of the issues raised substantially. The main contributing factor towards this comprehension were the intensive discussions with participants during the interviews; it is unlikely that that particular part could have been substituted properly, e.g., by using online surveys, questionnaires, etc. In addition, central insights were similarly found in companies from different design contexts, which supports confidence in the derived conclusions. The design of the framework is to some extent a result of what was seen and experienced in the preceding studies. Because of the limited sample size in the interview study, an over-proportional influence of statements originating from a few participants on the development of the IFM framework may have occurred. However, discussions with researchers and practicing designers that were not involved in the studies related to this research project, were also very positive with respect to the central properties of the IFM framework. In particular, a designer working in a company that develops software support systems for a substantial customer base, supported the central concept of enhancing traceability of information in the early stages of system development with the IFM framework. This seems to be a general concern of the company’s client base and support in this regard been repeatedly demanded irrespective of industrial branches.

7.4 Outlook The initial evaluation study in relation to the IFM framework suggested a large potential for the support of function modelling in interdisciplinary system development. However, practicing designers and involved researchers from academia suggested a few potentials for further improvement of the framework’s applicability. In particular, these include 



the development of adequate guidance supporting practicing designers in the synthesis process towards a potential solution concept, as well as to enable them to perform the need-dependent adaptions of the framework flexibly; adequate inclusion of additional contents desired by participants in the evaluation study (see Section 6.3.2).

Further research is needed to determine the most appropriate ways to support practitioners wishing to augment or tailor the framework to suit their specific needs and that of the project. Furthermore, future work will include the development of a software prototype to assist the application of the IFM framework. Prototypical software implementation has already been started as part of an on-going research project in collaboration with an academic partner. Software support is specifically intended to reduce modelling efforts and to support management of represented information. It is further expected to facilitate use and reuse of data within a design team and across design projects. In order to support this development, existing software support tools that may provide inspiration for crossfertilisation are currently being evaluated. 161

Finally, thus far, evaluation comprises feedback workshops, expert discussions, and on-going application evaluation. Additional and expanded evaluation studies will be used to verify the usefulness and improve the applicability of the developed framework further. These should focus on the application of the framework in real-life design projects that encompass the central transition from the requirements specification to the development of a suitable solution concept. Interest of academic and industrial partners in the further development of the IFM framework is high. All companies involved in the conducted studies expressed interest in following and supporting future research is this respect.

162

REFERENCES

Ahmed, S. and Wallace, K. (2003), “Evaluating a Functional Basis”, Proceedings of the ASME Design Engineering Technical Conferences and Computers and Information in Engineering Conference IDEC/CIE. Alam, I. (2002), “An Exploratory Investigation of User Involvement in New Service Development”, Journal of the Academy of Marketing Science, Vol. 30 No. 3, pp. 250–261. Alam, I. and Perry, C. (2002), “A Customer-oriented New Service Development Process”, Journal of Services Marketing, Vol. 16 No. 6, pp. 515–534. Albers, A., Sadowski, E. and Braun, A. (2010), “Funktionsorientierte Produktentwicklung in frühen Phasen von Entwicklungsprozessen”, 8. Gemeinsames Kolloquium Konstruktionstechnik. Alink, T. (2010), “Bedeutung, Darstellung und Formulierung von Funktionen für das Lösen von Gestaltungsproblemen mit dem C&C-Ansatz”, Dissertation, Institut für Produktentwicklung, Karlsruhe Institute of Technology, Karlsruhe. Alink, T., Eckert, C., Ruckpaul, A. and Albers, A. (2010), “Different Function Breakdowns for One Existing Product. Experimental Results”, in Gero, J. (Ed.), Design Computing and Cognition – DCC, SpringerVerlag, Dordrecht, pp. 405–425. Alonso-Rasgado, T., Thompson, G. and Elfström, B. (2004), “The Design of Functional (Total Care) Products”, Journal of Engineering Design, Vol. 15 No. 6, pp. 515–540. Altschuller, G. (1999), The Innovation Algorithm: TRIZ, Systematic Innovation, and Technical Creativity, Technical Innovation Center, Worcester (USA). Andreasen, M.M. (1980), “Syntesemetoder på Systemgrundlag - Bidrag til en Konstruktionsteori”, Dissertation, Institute for Machine Design, Lund University, Lund. Andreasen, M.M. (1992), “The Theory of Domains”, in Ullman, D., Blessing, L.T.M. and Wallace, K. (Eds.), Understanding Function and Function-to-From Evolution: Workshop Report, CUED/C-EDC/TR 12, Engineering Design Centre, Cambridge (UK), pp. 21–47. Andreasen, M.M. (1994), “Modelling – the Language of the Designer”, Journal of Engineering Design, Vol. 5 No. 2, pp. 103-115. Andreasen, M.M. and Hein, L. (2000), Integrated Product Development, The Institute for Product Development, IPU, Copenhagen. Andreasen, M.M., Howard, T. and Bruun, H. (2014), “Domain Theory, its Models and Concepts”, in Chakrabarti, A. and Blessing, L.T.M. (Eds.), An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations, Springer-Verlag, Berlin. Atteslander, P. (1995), Methoden der Empirischen Sozialforschung, Schmidt-Verlag, Berlin, New York. Aurich, J., Fuchs, C. and Wagenknecht, C. (2006), “Life Cycle Oriented Design of Technical Product Service Systems”, Journal of Cleaner Production, Vol. 14 No. 17, pp. 1480–1494. 163

Aurich, J., Schweitzer, E. and Fuchs, C. (2007), “Life Cycle Management of Industrial Product-Service Systems”, in Takata, S. and Umeda, Y. (Eds.), Advances in Life Cycle Engineering for Sustainable Manufacturing Businesses – Proceedings of the 14th CIRP Conference on Life Cycle Engineering, Part 2, Springer-Verlag, London, pp. 171–176. Aurisicchio, M., Eng, N., Ortiz Nicolas, J., Childs, P. and Bracewell, R. (2011), “On the Functions of Products”, Proceedings of the 18th International Conference on Engineering Design – ICED. Avison, D. (1991), “MERISE – A European Methodology for Developing Information Systems”, European Journal of Information Systems, Vol. 1 No. 1, pp. 183–191. Badke-Schaub, P., Daalhuizen, J. and Roozenburg, N.F.M. (2011), “Towards a Designer-Centred Methodology. Descriptive Considerations and Prescriptive Reflections”, in Birkhofer, H. (Ed.), The Future of Design Methodology, Springer-Verlag, London, pp. 181–197. Baumgarten, B. (1996), Petri-Netze: Grundlagen und Anwendungen, HochschulTaschenbuch, Spektrum Akademischer Verlag, Heidelberg, Berlin, Oxford. Beck, K. (1999), Extreme Programming Explained: Embrace Change, Addison Wesley Longman Inc., Amsterdam. Belzer, J., Holzman, A. and Kent, A. (1975), Encyclopaedia of Computer Science and Technology, CRC Press, Boca Raton (USA). Bender, B. (2004), “Erfolgreiche Individuelle Vorgehensstrategien in Frühen Phasen der Produktentwicklung”, Dissertation, Chair of Engineering Design and Methodology, Technical University of Berlin, Berlin. Bender, B., Reinicke, T., Wünsche, T. and Blessing, L.T.M. (2002), “Application of Methods from Social Sciences in Design Research”, Proceedings of the 11th International Design Conference – DESIGN. Blanchard, B. and Fabrycky, W. (1998), Systems Engineering and Analysis, International Series in Industrial & Systems Engineering, Prentice Hall, Upper Saddle River (USA). Bleck, A., Goedecke, M., Huss, A. and Waldschmidt, K. (1996), Praktikum des Modernen VLSI-Entwurfs, Teubner Verlag, München. Blessing, L.T.M. (1994), A Process-based Approach to Computer-supported Engineering Design, Dissertation, Black Bear Press, University of Twente, Enschede. Blessing, L.T.M. (1996), “Comparison of Design Models Proposed in Prescriptive Literature”, Proceedings of the COST A3 / COST A4 International Workshop on "The role of design in the shaping of technology". Blessing, L.T.M. (1997), Applying Systematic Design: The Flight Refuelling Probe Project, CUED/CEDC/TR 48, EdC Cambridge Engineering Design Centre, Cambridge. Blessing, L.T.M. (2002), “What is That Thing Called Design Research”, Annals of the 2002 International CIRP Design Seminar. Blessing, L.T.M. and Chakrabarti, A. (2009), DRM: A Research Design Methodology, Springer-Verlag, London. Blessing, L.T.M., Chakrabarti, A. and Wallace, K. (1998), “An Overview of Descriptive Studies in Relation to General Design Research Methodology”, in Frankenberger, E., Birkhofer, H. and Badke-Schaub, P. (Eds.), Designers: The Key to Successful Product Development, Springer-Verlag, London, pp. 42– 56. Blessing, L.T.M. and Upton, N. (1997), “A Methodology for Preliminary Design of Mechanical Aircraft Systems”, AIAA/SAE World Aviation Congress, American Institute of Aeronautics and Astronautics, Reston (USA).

164

Bobrow, D. (1984), “Qualitative Reasoning about Physical Systems. An introduction”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 24 No. 1-3, pp. 1– 5. Boehm, B.W. (1988), “A Spiral Model of Software Development and Enhancement”, IEEE Software, Vol. 21 No. 5, pp. 61–72. Bone, M. and Cloutier, R. (2010), “The Current State of Model Based Systems Engineering. Results from the OMG SysML Request for Information 2009”, Proceedings of the 8th Conference on Systems Engineering Research. Bonnema, G.M. and van Houten, F.J.A.M. (2006), “Use of Models in Conceptual Design”, Journal of Engineering Design, Vol. 17 No. 6, pp. 549–562. Borches, P. and Bonnema, G.M. (2010), “System Evolution Barriers and How to Overcome Them!”, Proceedings of the 8th Conference on Systems Engineering Research. Bosman, D. (1978), “Systematic Design of Instrumentation Systems”, Journal of Physics E: Scientific Instruments, Vol. 11 No. 2, pp. 97–105. Braha, D. and Reich, Y. (2003), “Topological Structures for Modeling Engineering Design Processes”, Research in Engineering Design, Vol. 14 No. 4, pp. 185–199. Brandt, E. (2005), “How do Tangible Mock-ups Support Design Collaboration”, Proceedings of Nordic Design Research Conference. Brezet, H., Diehl, J. and Silvester, S. (2001), “From Ecodesign of Products to Sustainable Systems Design. Delft's Experiences”, Proceedings of EcoDesign 2001: Second International Symposium on Environmentally Conscious Design and Inverse Manufacturing. Brown, D.C. and Blessing, L.T.M. (2005), “The Relationship Between Function and Affordance”, Proceedings of the ASME International Design Engineering Technical Conferences & Computers and Information Engineering Conference IDEC/CIE. Browning, T.R., Deyst, J., Eppinger, S.D. and Whitney, D. (2002), “Adding Value in Product Development by Creating Information and Reducing Risk”, IEEE Transactions on Engineering Management, Vol. 49 No. 4, pp. 443–458. Bucciarelli, L.L. (2010), “From Function to Structure in Engineering Design”, online publication, available at: http://hdl.handle.net/1721.1/51789 (last accessed 30 May 2013). Bullinger, H.-J., Fähnrich, K.-P. and Meiren, T. (2003), “Service Engineering. Methodical Development of New Service Products”, International Journal of Production Economics, Vol. 85 No. 3, pp. 275– 287. Bunse, C. and von Knethen, A. (2008), Vorgehensmodelle Kompakt, Spektrum Akademischer Verlag, Heidelberg. Buur, J. (1990), “A Theoretical Approach to Mechatronics Design”, Dissertation, Technical University of Denmark, Copenhagen. Buur, J. and Andreasen, M.M. (1989), “Design Models in Mechatronic Product Development”, Design Studies, Vol. 10 No. 3, pp. 155–162. Cabrera, A., Woestenek, K. and Tomiyama, T. (2011), “An Architecture Model to Support Cooperative Design for Mechatronic Products. A Control Design Case”, Mechatronics, Vol. 21 No. 3, pp. 534– 547. Carrara, M., Garbacz, P. and Vermaas, P. (2011), “If Engineering Function is a Family Resemblance Concept. Assessing three Formalization Strategies”, Applied Ontology, Vol. 6 No. 2, pp. 141–163. Chakrabarti, A. (1992), “Functional Reasoning in Design. Function as a Common Representation for Design Problem Solving”, in Ullman, D., Blessing, L.T.M. and Wallace, K. (Eds.), Understanding 165

Function and Function-to-From Evolution: Workshop Report, CUED/C-EDC/TR 12, Engineering Design Centre, Cambridge (UK). Chakrabarti, A. and Blessing, L.T.M. (Eds.) (2014), An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations, Springer-Verlag, Berlin. Chakrabarti, A. and Bligh, T.P. (2001), “A Scheme for Functional Reasoning in Conceptual Design”, Design Studies, Vol. 22 No. 6, pp. 493–517. Chakravarthy, B., Albers, A. and Schweinerger, D. (2001), “Collaborative Environment for Concept Generation in New Products”, Proceedings of International Council of Societies of Industrial Design – ICSID. Chandrasekaran, B. (2005), “Representing Function. Relating Functional Representation and Functional Modelling Research Streams”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 19 No. 2, pp. 65–74. Chandrasekaran, B. and Josephson, J. (2000), “Function in Device Representation”, Engineering with Computers, Vol. 16 No. 3-4, pp. 162–177. Chiang, W.-C., Pennathur, A. and Mital, A. (2001), “Designing and Manufacturing Consumer Products for Functionality. A Literature Review of Current Function Definitions and Design Support Tools”, Integrated Manufacturing Systems, Vol. 12 No. 6, pp. 430–448. Cicourel, A. and Haug, F. (1974), Methode und Messung in der Soziologie, Suhrkamp Verlag, Berlin. Cockburn, A. (2000), Writing Effective Use Cases, Vol. 1, Addison Wesley Professional, Indianapolis (USA). Cockburn, A. (2003), Agile Software-Entwicklung: Die Prinzipien der Agilen Software-Entwicklung Dargestellt und Erläutert, Welche Methodik für Welches Software-Projekt?, Software-Entwicklung im Team, mitp, Bonn. Cooper, A. (2007), About Face 3.0: The Essentials of Interaction Design, Wiley Publishing, Indianapolis (USA). Cooper, R.G. (2010), Top oder Flop in der Produktentwicklung: Erfolgsstrategien: von der Idee zum Launch, Wiley-VCH-Verlag, Weinheim. Crilly, N. (2010), “The Role that Artefacts Play. Technical, Social and Aesthetical Functions”, Design Studies, Vol. 31 No. 4, pp. 311–344. Crilly, N., Maier, A. and Clarkson, P. (2008), “Representing Artefacts as Media. Modelling the Relationship Between Designer Intent and Consumer Experience”, International Journal of Design, Vol. 2 No. 3, pp. 15–27. Cross, N. (2008), Engineering Design Methods: Strategies for Product Design, John Wiley and Sons Ltd., Chichester (UK). Deng, Y. (2002), “Function and Behaviour Representation in Conceptual Mechanical Engineering”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 16 No. 5, pp. 343–362. Dewey, A. (2000), “Digital and Analogue Electronic Design Automation”, in Dorf, R.C. (Ed.), The Electrical Engineering Handbook, CRC Press, Boca Raton, London, New York. Diekmann, A. (2001), Empirische Sozialforschung: Grundlagen, Methoden, Anwendungen, Rowohlts Enzyklopädie, Rowohlt-Taschenbuch-Verlag, Reinbek bei Hamburg. DiManzo, M., Trucco, E., Giunchigia, F. and Ricci, F. (1989), “FUR: Understanding Functional Reasoning”, International Journal of Intelligent Systems, Vol. 4 No. 4, pp. 431–457.

166

Donaldson, K., Ishii, K. and Sheppard, S. (2006), “Customer Value Chain Analysis”, Research in Engineering Design, Vol. 16 No. 4, pp. 174–183. Dorf, R.C. (Ed.) (2000), The Electrical Engineering Handbook, CRC Press, Boca Raton, London, New York. Dorst, K. and Vermaas, P.E. (2005), “John Gero's Function-Behaviour-Structure Model of Designing: a Critical Analysis”, Research in Engineering Design, Vol. 16 No. 1-2, pp. 17–26. Dym, C.L. (1994), Engineering Design: A Synthesis of Views, Cambridge University Press, Cambridge (USA). Eckert, C. (2013), “That Which is not Form. The Practical Challenges in Using Functional Concepts in Design”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 27 No. 3, pp. 217–231. Eckert, C., Alink, T. and Albers, A. (2010), “Issue Driven Analysis of an Existing Product at Different Levels of Abstraction”, Proceedings 11th International Design Conference – DESIGN. ECSS‐E‐ST‐10C (2009), System Engineering General Requirements, European Cooperation for Space Standardizsation, Noordwijk. Eder, W. (2008), “Aspects of Analysis and Synthesis in Design Engineering”, Proceedings of the Canadian Engineering Education Association. Eder, W. and Hosnedl, S. (2008), Design Engineering: A Manual for Enhanced Creativity, CRC Press, Boca Raton, London, New York. Eder, W. and Hosnedl, S. (2010), Introduction to Design Engineering: Systematic Creativity and Management, CRC Press, Boca Raton. Edvardsson, B. and Olsson, J. (1996), “Key Concepts for New Service Development”, Services Industries Journal, Vol. 16 No. 2, pp. 140–164. Eger, T. (2005), “Design Freeze during Product Development. Supporting Change Prediction during Detail Design”, Dissertation, University of Cambridge, Cambridge (UK). Ehrlenspiel, K. (2007), Integrierte Produktentwicklung: Zusammenarbeit, Hanser-Verlag, München.

Denkabläufe,

Methodeneinsatz,

Eigner, M., Faisst, K., Hollerith, T. and Nem, F. (2010), “A View-based Modelling Approach for Representing Multidisciplinary Functions in PDM Systems”, Proceedings of 11th International Design Conference – DESIGN. Eisenbart, B., Blessing, L.T.M. and Gericke, K. (2012a), “Functional Modelling Perspectives Across Disciplines. A Literature Review”, Proceedings of 12th International Design Conference – DESIGN. Eisenbart, B., Dohr, F., Gericke, K., Vielhaber, M. and Blessing, L.T.M. (2013a), “Potentials for Realising a Consistent Transition Between Function Modelling with the IFM Framework and Early System Simulation”, Proceedings of the 19th International Conference on Engineering Design – ICED, Vol. 2, pp. 213–222. Eisenbart, B., Gericke, K. and Blessing, L.T.M. (2011), “A Framework for Comparing Design Modelling Approaches Across Disciplines”, Proceedings of the 18th International Conference on Engineering Design – ICED, Vol. 2, pp. 344–355. Eisenbart, B., Gericke, K. and Blessing, L.T.M. (2012b), “A Shared Basis for Functional Modelling”, Proceedings of the 9th NordDesign Conference. Eisenbart, B., Gericke, K. and Blessing, L.T.M. (2013b), “An Analysis of Functional Modell Approaches Across Disciplines”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 27 No. 3, pp. 281–289.

167

Eisenbart, B., Gericke, K. and Blessing, L.T.M. (2013c), “Adapting the IFM Framework to Functional Approaches Across Disciplines”, Proceedings of the 19th International Conference on Engineering Design – ICED, Vol. 2, pp. 163–172. Eisenbart, B., Gericke, K. and Blessing, L.T.M. (2014), “Application of the IFM Framework for Modelling and Analysing System Functionality“, Proceedings of the 13th International Design Conference – DESIGN. Eisenbart, B., Mandel, C., Gericke, K. and Blessing, L.T.M. (2015), “Integrated Function Modelling. Comparing the IFM Framework with SysML”, in Proceedings of the 20th International Conference on Engineering Design – ICED. Eisenbart, B., Qureshi, A.J., Gericke, K. and Blessing, L.T.M. (2013d), “Integrating Different Functional Modelling Perspectives”, in Chakrabarti, A. and Prakash, R. (Eds.), Global Product Development, ICoRD’13, Lecture Notes in Mechanical Engineering, Springer-Verlag, London, pp. 85–97. Eppinger, S.D. and Browning, T.R. (2012), Design Structure Matrix Methods and Applications, MIT Press, Cambridge (USA). Erden, M., Komoto, H., van Beek, T.J., D'Amelio, V., Echavarria, E. and Tomiyama, T. (2008), “A Review of Function Modeling. Approaches and Applications”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 22 No. 2, pp. 147–169. Ericson, A. and Larsson, T. (2005), “A Service Perspective on Product Development. Towards Functional Products”, Proceedings of 12th International Product Development Management Conference – CBS. Fähnrich, K.-P. and Meiren, T. (2007), “Service Engineering: State of the Art and Future Trends”, Advances in Service Innovations, Vol. 1, pp. 3–16. Far, B.H. and Elamy, H. (2005), “Functional Reasoning Theories. Problems and Perspectives”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 19 No. 2, pp. 75– 88. Fisher, C. and Schutta, J.T. (2003), Developing New Services: Incorporating the Voice of the Customer into Strategic Service Development, ASQ Quality Press, Milwaukee (USA). Fowler, M. (1998), Analysis Patterns: Reusable Object Models, Addison Wesley Longman Inc., Boston. Frankenberger, E., Birkhofer, H. and Badke-Schaub, P. (Eds.) (1998), Designers: The Key to Successful Product Development, Springer-Verlag, London. Freeman, P. and Newell, A. (1971), “A Model for Functional Reasoning in Design”, Proceedings of 2nd International Joint Computer Conference on Artificial Intelligence. Fricke, G. and Pahl, G. (1991), “Relationship between Personally Conditioned Procedure and Quality of Solution ”, Proceedings of the 8th International Conference on Engineering Design – ICED. Friedenthal, S., Moore, A. and Steiner, R. (2006), “OMG Systems Modeling Language (OMG SysMLTM) Tutorial”, INCOSE - International Symposium. Gantt, H. (1910), Work, Wages, and Profits: Their Influence on the Cost of Living, The Engineering Magazine, New York. Garbacz, P., Borgo, S., Carrara, M. and Vermaas, P.E. (2011), “Two Ontology-driven Formalisations of Function and Their Comparison”, Journal of Engineering Design, Vol. 22 No. 11-12, pp. 733–764. Gausemeier, J. (2006), “Spezifikationstechniken”, TransMechatronic. Gausemeier, J., Frank U., Donoth J. and Kahl S. (2009), “Specification Technique for the Description of Self-Optimizing Mechatronic Systems”, Research in Engineering Design, Vol. 20 No. 4, pp. 201–223. Gausemeier, J. and Möhringer, S. (2001), “Integration der Funktions- und Prinziplösungsmodellierung Mechatronischer Systeme”, Beiträge zum 12. Symposium "Design for X“. 168

Gericke, K. (2011), “Enhancing Project Robustness. A Risk Management Perspective”, Dissertation, Chair of Engineering Design and Methodology, Technical University of Berlin, Berlin. Gericke, K. and Blessing, L.T.M. (2011), “Comparison of Design Methodologies and Process Models Across Disciplines: A Literature Review”, Proceedings of the 18th International Conference on Engineering Design – ICED. Gericke, K. and Blessing, L.T.M. (2012), “An Analysis of Design Process Models Across Disciplines”, Proceedings of 12th International Design Conference – DESIGN. Gericke, K., Meissner, M. and Paetzold, K. (2013a), “Design Context”, Proceedings of 19th International Conference on Engineering Design – ICED. Gericke, K., Qureshi, A.J. and Blessing, L.T.M. (2013b), “Analyzing Transdisciplinary Design Processs in Industry. An Overview”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDEC/CIE. Gero, J.S. (1990), “Design Prototypes. A Knowledge Representation Scheme for Design”, AI Magazine, Vol. 11 No. 4, pp. 26–36. Gero, J.S. and Kannengiesser, U. (2002), “The Situated Function - Behaviour - Structure Framework”, Artificial Intelligence in Design 02, pp. 89–104. Gero, J.S. and Kannengiesser, U. (2013), Commonalities across Designing: Evidence from Models of Designing and Experiments, online publication, available at: http://mason.gmu.edu/~jgero//publications/Progress/12GeroKannengiesserCommonalitiesJourn al.pdf (last accessed 14 December 2013). Gero, J.S. and Kannengiesser, U. (2014), “The Function‐Behaviour‐Structure Ontology of Design”, in Chakrabarti, A. and Blessing, L.T.M. (Eds.), An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations, Springer-Verlag, Berlin. Goedkoop, M., van Halen, C., Riele, H. and Rommens, P. (1999), Product Service Systems, Ecological and Economic Basics, Dutch ministries of Environment (VROM) and Economic Affairs (EZ), Amsterdam. Goel, A. (2013), “One Thirty Year Long Case Study. Fifteen Principles: Implications of the AI Methodology for Functional Modelling”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 27 No. 3, pp. 203–215. Goel, V. (1995), Sketches of thought, MIT Press, Cambridge (USA). Goldschmidt, G. and Porter, W.L. (2004), Design Representation, Springer-Verlag, Berlin. Gries, B. (2007), “Design Flaws and Quality-Related Feedback in Product Development”, Dissertation, Chair of Engineering Design and Methodology, Technical University of Berlin, Berlin. Gries, B. and Gericke, K. (2009), “A Method for Identifying Improvement Potentials within Product Development Processes”, Proceedings of the 17th International Conference on Engineering Design – ICED. Hale, C. (1987), “Analysis of the Engineering Design Process in an Industrial Context”, Dissertation, University of Cambridge, Cambridge (UK). Hall, A. (1962), A Methodology for Systems Engineering, Van Nostrand Company, Inc., Princeton, NJ. Halmos, P.R. (1974), Naive Set Theory, Springer-Verlag, New York. Hatchuel, A. and Weil, B. (2003), “A New Approach of Innovative Design”, Proceedings of the 14th International Conference on Engineering Design – ICED. Henderson, K. (1999), On Line and On Paper: Visual Representations, Visual Culture, and Computer Graphics in Design Engineering, The MIT Press, Boston. 169

Hitchins, D. (2007), Systems Engineering: A 21st Century Systems Methodology, John Wiley & Sons, Chichester. Hirtz, J., Stone, R.B., Szykman, S., McAdams, D. and Wood, K.L. (2001), “Evolving a Functional Basis for Engineering Design”, Proceedings of the ASME Design Engineering Technical Conference: DETC2001. Houkes, W. (2006), “Knowledge of Artefact Functions”, Studies in History and Philosophy of Science, Vol. 37 No. 1, pp. 103–113. Houkes, W. and Vermaas, P.E. (2010), Technical Functions: On the Use and Design of Artefacts, Philosophy of Engineering and Technology, Springer-Verlag, Dordrecht. Howard, T. and Andreasen, M.M. (2013), “Mindsets of Functional Reasoning in Engineering Design”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 27 No. 3, pp. 233–240. Howard, T., Culley, S. and Dekoninck, E. (2008), “Describing the Creative Design Process by the Integration of Engineering Design and Cognitive Psychology Literature”, Design Studies, Vol. 29 No. 2, pp. 160–180. Hubka, V. (1980), Principles of Engineering Design, Butterworth-Heinemann Ltd, Oxford. Hubka, V. (1984), Theorie Technischer Systeme: Grundlagen einer Konstruktionslehre, Springer-Verlag, Berlin, Heidelberg, New York, Tokyo.

Wissenschaftlichen

Hubka, V. and Eder, W. (1988), Theory of Technical Systems: A Total Concept Theory for Engineering Design, Springer-Verlag, Berlin, Heidelberg, New York, Tokyo. Hundal, M. (1990), “A Systematic Method for Developing Function Structures, Solutions and Concept Variants”, Mechanism and Machine Theory, Vol. 25 No. 3, pp. 243–256. IABG (2006), “V-Modell XT”, online publication, available at: http://www.v-modell.iabg.de/ (last accessed 14 March 2014). INCOSE (2010), Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, INCOSE‐TP‐2003‐002‐03.2, International Council on Systems Engineering, San Diego. ISO (2012), ISO/EC 19505-1: Information technology – Object Management Group, Unified Modeling Language (OMG UML), International Organization for Standardization, Geneva. Iwasaki, Y., Fikes, R., Vescovi, M. and Chandrasekaran, B. (1993), “How Things are Intended to Work. Capturing Functional Knowledge in Device Design”, Proceedings of International Joint Conference AI, AAAI Press, Palo Alto (USA), pp. 1616–1522. Jacobson, I., Christerson M., Jonsson P. and Övergaard G. (1992), Object-oriented Software Engineering: A Use Case Driven Approach, ACM Press; Addison-Wesley Publications, New York, Wokingham, Reading. Jänsch, J. (2007), “Akzeptanz und Anwendung von Konstruktionsmethoden im Industriellen Einsatz. Analyse und Empfehlungen aus Kognitionswissenschaftlicher Sicht”, Dissertation, Produktentwicklung und Maschinenelemente, Technical University of Darmstadt, Darmstadt. Kajitani, M. (1986), “Advanced Information Society and Mechatronics”, Journal of the Japanese Society of Mechanical Engineering, Vol. 89 No 810. Kaufman, J.J. and Woodhead, R. (2006), Stimulating Innovation in Products and Services: With Function Analysis and Mapping, Wiley Series in Systems Engineering and Management, Wiley-Interscience, Hoboken (USA). Kim, Y.S., Lee, S.W., Jin, H., Shin, J.H., Park, J.A., Lee, Y.G.K.C.D., Seo, B.H. and Lee, S.J. (2011), “ProductService Systems (PSS) Design Process and Design Support Systems”, in in Hesselbach, J. and 170

Herrmann, C. (Eds.) Functional Thinking for Value Creation: Proceedings of the 3rd CIRP International Conference on Industrial Product Service Systems, Springer-Verlag, Berlin. King, B. (1989), Better Designs in Half the Time: Implementing QFD Quality Function Deployment in America, GOAL/QPC, Methuen (USA). Kitamura, Y. and Mizogushi, R. (2007), “Ontology-based Systematization of Functional Knowledge”, Journal of Engineering Design, Vol. 15 No. 4, pp: 327-351. Kitamura, Y., Takafuji, S. and Mizogushi, R. (2007), “Towards a Reference Ontology for Functional Knowledge Interoperability”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDETC/CIE. Kleinsmann, M. and Valkenburg, R.C. (2008), “Barriers and Enablers for Creating Shared Understanding in Co-design Projects”, Design Studies, Vol. 29 No. 4, pp. 369–386. Koller, R. and Kastrup, N. (1998), Prinziplösungen zur Konstruktion Technischer Produkte, SpringerVerlag, Berlin, Heidelberg. Kompridis, N. (2000), “So We Need Something Else for Reason to Mean”, International Journal of Philosophical Studies, Vol. 8 No. 3, pp. 271–295. Kroes, P. and Meijers, A. (2001), The Empirical Turn in the Philosophy of Technology, Research in Philosophy and Technology, Vol. 20, 1st ed., JAI, Amsterdam, New York. Kroll, P. and Kruchten, P. (2003), “The Rational Unified Process Made Easy. A Practitioner’s Guide to the RUP”, Addison Wesley Longman Inc., Amsterdam. Kruchten, P. (2004), The Rational Unified Process: An Introduction, Pearson Education, Upper Saddle River (USA). Kruchten, P. (2005), “Casting Software Design in the Function-Behavior-Structure Framework”, IEEE Software, Vol. 22 No. 2, pp. 52–58. Kurfman, M., Stock, M., Stone, R.B., Rajan, J. and Wood, K.L. (2003), “Experimental Studies Assessing the Repeatability of a Functional Modeling Derivation Method”, Journal of Mechanical Design, Vol. 125 No. 4, pp. 682-639. Latour, B. (1986), “Visualisation and Cognition. Thinking with Eyes and Hands”, Knowledge and Society, Vol. 6 No. 1, pp. 1–40. Lawson, B. and Dorst, K. (2009), Design Expertise, Architectural Press, Oxford, Burlington. Leemhuis, H. (2005), “Funktionsgetriebene Konstruktion als Grundlage Verbesserter Produktentwicklung”, Dissertation, Chair of Engineering Design and Methodology, Technical University of Berlin, Berlin. Lindemann, U. and Maurer, M. (2007), Facing Multi-domain Complexity in Product Development, Springer-Verlag, Berlin. Lindemann, U., Maurer, M. and Braun, T. (2009), Structural Complexity Management, Springer-Verlag, Berlin. Liu, X. and Li, Y. (2012), Advanced Design Approaches to Emerging Software Systems. Principles, Methodologies, and Tools, Information Science Reference, Hershey (USA). Maier, A., Kreimeyer, M., Herfeld, U., Deubzer, F., Lindemann, U. and Clarkson, J. (2006), “Reflecting Communication. A Key Factor for Successful Collaboration Between Embodiment Design and Simulation”, Proceedings of the 9th International Design Conference – DESIGN. Maier, J.R. and Fadel, G.M. (2001), “Affordance. The Fundamental Concept in Engineering Design”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDEC/CIE. 171

Maier, J.R. and Fadel, G.M. (2002), “Comparing Function and Affordance as Bases for Design”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDEC/CIE. Maier, A., Wynn, D., Howard, T. and Andreasen M.M. (2014), “Perceiving Design as Modelling: A Cybernetic Systems Perspective”, in Chakrabarti, A. and Blessing, L.T.M. (Eds.), An Anthology of Theories and Models of Design: Philosophy, Approaches and Empirical Explorations, SpringerVerlag, Berlin. Matthiesen, S., Meboldt, M., Ruckpaul, A. and Mussgnug, M. (2013), “Eye Tracking, a Method for Engineering Design Research on Engineers' Behaviour while Analyzing Technical Systems”, Proceedings of the 19th International Conference on Engineering Design – ICED. Matzen, D. (2009), “A Systematic Approach to Service Oriented Product Development”, Dissertation, DTU Management Engineering, Technical University of Denmark, Copenhagen. Maurer, M. and Meisenbacher, S. (2013), “Modeling and Analyzing Systems in Application”, in Chakrabarti, A. and Prakash, R. (Eds.), Global Product Development, ICoRD’13, Lecture Notes in Mechanical Engineering, Springer-Verlag, London, pp. 707–719. Maussang-Detaille, N. (2008), “Méthologie de Conception pour les Systèmes Produits-Services”, Dissertation, Université de Grenoble, Grenoble. McAloone, T.C. (2011), “Boundary Conditions for a New Type of Design Task. Understanding Product/Service-Systems”, in Birkhofer, H. (Ed.), The Future of Design Methodology, SpringerVerlag, London, pp. 113–124. McAloone, T.C. and Andreasen, M.M. (2004), “Design for Utility, Sustainability and Societal Virtues: Developing Product Service Systems”, Proceedings of the 8th International Design Conference – DESIGN. McAloone, T.C. and Andreasen, M.M. (2006), “What Happens to Integrated Product Development Models with Product/Service-System Approaches?”, Integrated Product Development Workshop – IPD. Merriam-Webster (2003), Merriam-Webster's Collegiate Dictionary, Merriam-Webster Incorporated, Springfield. Metzler, T. and Shea, K. (2011), “Taxonomy of Cognitive Functions”, Proceedings of 18th International Conference on Engineering Design – ICED. Möhringer, S. and Gausemeier, J. (2002), “An Interface Specification for Principle Solutions Supporting the Cross-Domain Design of Mechatronic Systems”, Proceedings of the 7th International Design Conference – DESIGN. Mont, O. (2004), “Institutionalisation of Sustainable Consumption Patterns Based on Shared Use”, Ecological Economics, Vol. 50 No. 1-2, pp. 135–153. Moser, H. (2014), Systems Engineering, Systems Thinking, and Learning: A Case Study in Space Industry, Springer-Verlag, Cham (a.o.). Mougaard, K., Howard, T., McAloone, T.C. and Bey, N. (2012), “Establishing Collaborative Networks for the Conceptualization of PSS”, Proceedings of 12th International Design Conference – DESIGN. Müller, P. (2013), Integrated Engineering of Products and Services: Layer-based Development Methodology for Product-Service Systems, Fraunhofer Verlag, Berlin. Müller, P., Schmidt-Kretschmer, M. and Blessing, L.T.M. (2007), “Function Allocation in ProductService-Systems – Are there Analogies Between PSS and Mechatronics?”, Proceedings of the AEDS Workshop.

172

Nagel, R.L., Midha, P.A., Tinsley, A., Stone, R.B., McAdams, D. and Shu, L. (2008), “Exploring the Use of Functional Models in Biomimetic Conceptual Design”, Journal of Mechanical Design, Vol. 130 No. 12, pp. 2–13. NASA (2007), Systems Engineering Handbook, NASA/SP-2007-6105 Rev1, National Aeronautics and Space Administration, Washington D.C. (USA). Nevala, K. (2005), “Content-based Design Engineering Thinking. In the Search for Approach”, Dissertation, University of Jyväskylä, Jyväskylä. OMG (2012), “OMG Systems Modeling Language (OMG SysMLTM) Specification”, available online at: http://www.omg.org/spec/SysML/1.3 (last accessed 12 April 2014). Ookubo, M., Koji, Y., Sasajima, M., Kitamura, Y. and Mizogushi, R. (2007), “Towards Interoperability Between Functional Taxonomies Using an Ontology-based Mapping”, Proceedings of 16th International Conference on Engineering Design – ICED. Paetzold, K. (2006), “On the Importance of a Functional Description for the Development of Cognitive Technical Systems”, Proceedings of 9th International Design Conference – DESIGN. Pahl, G. and Beitz, W. (1977), Konstruktionslehre, Springer-Verlag, Berlin. Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.-H. (2007), Engineering Design: A Systematic Approach, Springer-Verlag, Berlin, Heidelberg, New York, Tokyo. Paredis, C., Diaz-Calderon, A., Sinha, R. and Khosla, P. (2001), “Composable Models for SimulationBased Design”, Engineering with Computers, Vol. 17 No. 2, pp. 112–128. Patton, M.Q. (2002), Qualitative Research and Evaluation Methods, Sage Publications, Thousand Oaks (USA). Pires, A., Duprat, S., Faure, T., Besseyre, C., Beringuier, J. and Rolland, J. (2012), “Use of Modelling Methods and Tools in an Industrial Embedded System Project. Works and Feedback”, Proceedings of Embedded Real Time Software and Systems – ERTS. Poon, J. and Maher, M. (1997), “Co-evolution and Emergence in Design”, Artificial Intelligence in Design, Vol. 11 No. 3, pp. 319–327. Pugh, S. (1991), Integrated Methods for Successful Product Engineering, Addison-Wesley Publications Co., Wokingham, Reading. Qureshi, A.J., Gericke, K. and Blessing, L.T.M. (2013), “Design Process Commonalities in Transdisciplinary Design”, Proceedings of the 19th International Conference on Engineering Design – ICED. Rajan, J., Stone, R.B. and Wood, K.L. (2003), “Functional Modelling of Control Systems”, Proceedings of the 14th International Conference on Engineering Design – ICED. Redenius, A. (2006), “Verfahren zur Planung von Entwicklungsprozessen für Fortgeschrittene Mechatronische Systeme”, Dissertation, Heinz Nixdorf Institute, University of Paderborn, Paderborn. Reyman, I.M.M., Hammer, D.K., Kroes P.A., van Aken, Dorst, C.H., Bax, M.F.T. and Basten, T. (2006), “A Domain-Independent Descriptive Design Model and its Application to Structured Reflection on Design Processes”, Research in Engineering Design, Vol. 16 No. 4, pp. 147–173. Rodenacker, W.G. (1970), Methodisches Konstruieren, Springer-Verlag, Berlin, Heidelberg, New York, Tokyo. Roozenburg, N.F.M. and Eekels, J. (1995), Product Design: Fundamentals and Methods, A Wiley Series in Product Development Planning, Designing, Engineering, Wiley, Chichester (a.o.).

173

Ropohl, G. (2009), Allgemeine Technologie – Eine Systemtheorie der Technik, Univ.-Verl. Karlsruhe, Karlsruhe. Ross, D. (1977), “Structured Analysis (SA): A Language for Communicating Ideas”, IEEE Transactions on Software Engineering, Vol. 3 No. 1, pp. 16–34. Roth, K. (1986), “Modellbildung für das Methodische Rechnerunterstützung”, VDI Z, Vol. 128 No. 1, pp. 21–25.

Konstruieren

ohne

und

mit

Sachse, P. and Leinert, S. (2002), “Skizzen und Modelle - Wieso Hilfsmittel des Denkens und Handelns beim Konstruieren?”, in Hacker, W. (Ed.), Denken in der Produktentwicklung: Unterstützung der frühen Phasen, Mensch-Technik-Organisation, vdf, Zürich, pp. 63–81. Sadek Hassanein, T. (2008), “Ein modellorientierter Ansatz zur Konzeptentwicklung Industrieller Produkt-Service Systeme”, Dissertation, Ruhr-Universität Bochum, Bochum. Sage, A.P. and Rouse, W.B. (Eds.), Handbook of Systems Engineering and Management, Wiley, Hoboken. Sager, I. (2012), “Before IPhone and Android Came Simon, the First Smartphone”, online publication, available at: http://www.businessweek.com/articles/2012-06-29/before-iphone-and-androidcame-simon-the-first-smartphone (last accessed 1 February 2014). Sakao, T. and Shimomura, Y. (2007), “Service Engineering. A Novel Engineering Discipline for Producers to Increase Value Combining Service and Product”, Journal of Cleaner Production, Vol. 15 No. 6, pp. 590–604. Salminen, V. and Verho, A.J. (1989), “Multidisciplinary Design Problems in Mechatronics and Some Suggestions to its Methodical Solution in Conceptual Design Phase”, Proceedings of 6th International Conference on Engineering Design – ICED. Salminen, V. and Verho, A.J. (1992), “Multidisciplinary Problems in Mechatronics and Some Solutions”, Computers & Electrical Engineering, Vol. 18 No. 1, pp. 1–9. Scheele, M. (2006), “Function and Use of Technical Artefacts. Social Conditions of Function Ascription”, Studies in History and Philosophy of Science, Vol. 37 No. 1, pp. 23–36. Scheffer, L., Lavagno, L. and Martin, G. (2006), EDA for Implementation, Circuit Design, and Process Technology, CRC Press, Boca Raton, London, New York. Scheuing, E. and Johnson, E. (1989), “New Product Development and Management in Financial Institutions”, International Journal of Bank Marketing, Vol. 7 No. 2, pp. 17–21. Schmidt, D., Schenkl, A., Wickel, M., Saucken, C. von and Maurer, M. (2013), “Multiple-Domain Matrices and Knowledge Maps for Visualizing Knowledge-Driven Scenarios”, Proceedings of the 15th International Dependency and Structure Modelling Conference – DSM. Schneider, K., Daun, C. and Wagner, D. (2005), “Vorgehensmodelle und Standards zur systematischen Entwicklung von Dienstleitungen”, in Bullinger, H.-J., Schneider, K. and Scheer, A.-W. (Eds.), Service Engineering: Entwicklung und Gestaltung innovativer Dienstleistungen, Springer-Verlag, Berlin, Heidelberg, pp. 113–138. Schwaber, K. (2007), Agile Project Management with Scrum, Microsoft Press, Redmond (USA). Segan, S. (2012), “Enter the Phablet: A History of Phone-Tablet Hybrids”, online publication, available at: http://www.pcmag.com/slideshow/story/294004/enter-the-phablet-a-history-of-phonetablet-hybrids (last accessed 1 February 2014). Sen, C., Summers, J.D. and Mocko Gregory M. (2010), “Topological Information Content and Expressiveness of Function Models in Mechanical Design”, Journal of Computing and Information Science in Engineering, Vol. 10 No. 3, pp. 1–11.

174

Sen, C., Summers, J.D. and Mocko Gregory M. (2013), “A Formal Representation of Function Structure Graphs for Physics-based Reasoning”, Journal of Computational and Information Science in Engineering, Vol. 13 No. 2. Shai, O. and Reich, Y. (2004), “Infused Design. I. Theory”, Research in Engineering Design, Vol. 15 No. 2, pp. 93–107. Shostack, G.L. (1982), “How to Design a Service”, European Journal of Marketing, Vol. 16 No. 1, pp.49– 63. Shostack, G.L. and Kingman-Brundage, J. (1991), “How to Design a Service”, in Congram, A. and Friedman, M. (Eds), The AMA Handbook of Marketing for the Service Industries, AMACOM, Saranac Lake, pp. 243–263. Simon, H. (1973), “The Structure of Ill-Structured Problems”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 4 No. 3-4, pp. 181–201. Spath, D. and Demuss, L. (2005), “Entwicklung Hybrider Produkte. Gestaltung Materieller und Immaterieller Leistungsbündel”, in Bullinger, H.-J., Schneider, K. and Scheer, A.-W. (Eds.), Service Engineering: Entwicklung und Gestaltung Innovativer Dienstleistungen, Springer-Verlag, Berlin, Heidelberg, pp. 463–502. Srinivasan, V. and Chakrabarti, A. (2010), “An Integrated Model of Designing”, Journal of Computing and Information Science in Engineering, Vol. 10 No. 3. Srinivasan, V., Chakrabarti, A. and Lindemann, U. (2012), “A Framework for Describing Functions in Design”, Proceedings of 12th International Design Conference – DESIGN. Stachowiak, H. (1973), Allgemeine Modelltheorie, Springer-Verlag, Wien. Stacy, M. and Eckert, C. (2003), “Against Ambiguity”, Computer Supported Cooperative Work, Vol. 12 No. 2, pp. 153–184. Stark, R., Beier, G., Wöhler, T. and Figge, A. (2010), Cross-Domain Dependency Modelling: How to Achieve Consistent System Models with Tool Support, INCOSE, San Diego (USA). Stechert, C. (2010), “Modellierung Komplexer Anforderungen”, Dissertation, Institute for Engineering Design, Technical University of Braunschweig, Braunschweig. Stone, R.B. and Wood, K.L. (2000), “Development of a Functional Basis for Design”, Journal of Mechanical Design, Vol. 122 No. 4, pp. 359–370. Suh, N. (2001), Axiomatic Design: Advances and Applications, Oxford University Press, London. Szykman, S., Racz, J. and Sriram, R. (1999), “The Representation of Function in Computer-Based Design”, Proceedings of the International Conference on Design Theory and Methodology – DTM. Tan, A.R. (2010), “Service-oriented Product Development Strategies”, Dissertation, Management Engineering, Technical University of Denmark, Copenhagen. Tan, A.R., McAloone, T.C. and Gall, C. (2007), “Product/Service-System Development. An Explorative Case Study in a Manufacturing Company”, Proceedings of the 16th International Conference on Engineering Design – ICED. Tjalve, E. (1978), Systematische Formgebung für Industrieprodukte, The Institute for Product Development, IPU, Copenhagen. Torry-Smith, J. (2013), “Designing Mechatronic Products. Achieving Integration by Means of Modelling Dependencies”, Dissertation, Technical University of Denmark, Copenhagen, Denmark, 2013. Tukker, A., van den Berg, C. and Tischner, U. (2006), “Product-Services: A Specific Value Proposition”, in Tukker, A. and Tischner, U. (Eds.), New Business for Old Europe, Greanleaf Publishing Ltd, Sheffield. 175

Ullman, D. (2010), The Mechanical Design Process, McGraw-Hill Series in Mechanical Engineering, 4th ed., McGraw-Hill Higher Education, Boston. Ullman, D., Blessing, L.T.M. and Wallace, K. (Eds.) (1992), Understanding Function and Function-toFrom Evolution: Workshop Report, CUED/C-EDC/TR 12, Engineering Design Centre, Cambridge. Ullman, D., Dietterich, T. and Stauffer, L. (1988), “A Model of the Mechanical Design Process Based on Empirical Data”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 2 No. 1, pp. 33–52. Ulrich, K. and Eppinger, S.D. (2008), Product Design and Development, McGraw-Hill Higher Education, New York. Umeda, Y. and Tomiyama, T. (1997), “Functional Reasoning in Design”, IEEE Expert, Vol. 12 No. 2, pp. 42–48. US DoD (2001), Systems Engineering Fundamentals, Defence Acquisition University Press, Fort Belvoir (USA). Valkenburg, R.C. (2000), “The Reflective Practice in Product Design Teams”, Dissertation, Delft University of Technology, Delft. van Alven, W. (1964), Reliability Engineering, Prentice Hall, Englewood Cliffs (USA). van Beek, T.J. and Tomiyama, T. (2009), “Connecting Views in Mechatronic Systems Design, a Functions Modelling Approach”, Proceedings of ASME 2009 International Conference on Mechatronic and Embedded Systems and Applications. van Eck, D. (2010), “On the Conversion of Functional Models. Bridging Differences Between Functional Taxonomies in the Modelling of User Actions”, Research in Engineering Design, Vol. 21 No. 2, pp. 99–111. Vandermerwe, S. (2000), “How Increasing Value to Customers Improves Business Results”, Sloan Management Review, Vol. 42 No. 1, pp. 27–37. VDE (2004), Dokumentation in der Elektrotechnik, Darstellungsregeln, Beuth Verlag, Berlin. VDI (1993), VDI 2221 – Systematic Approach for the Design of Technical Systems and Products, Beuth Verlag, Berlin. VDI (2004), VDI 2206 – Design Methodology for Mechatronic Systems, Beuth Verlag, Berlin. Vermaas, P. (2009), “The Flexible Meaning of Function in Engineering”, Proceedings of 17th International Conference on Engineering Design – ICED. Vermaas, P. (2010), “A Conceptual Ambiguous Future for Engineering Design”, Copenhagen Working Papers on Design, Vol. 2, pp. 1–6. Vermaas, P. (2011), “Accepting Ambiguity of Engineering Functional Descriptions”, Proceedings of 18th International Conference on Engineering Design – ICED. Vermaas, P.E. (2013a), “On the Co-Existence of Engineering Meanings of Function. Four Responses and Their Methodological Implications”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM), Vol. 27 No. 3, pp. 191–202. Vermaas, P.E. (2013b), “On the Formal Impossibility of Analysing Subfunctions as Parts of Function in Design Methodology”, Research in Engineering Design, Vol. 24 No. 1, pp. 19–32. Visser, W. (1991), “Evocation and Elaboration of Solutions: Different Types of Problem-Solving Actions. An Empirical Study on the Design of an Aerospace Artifact”, Proceedings of the Third COGNITIVA Symposium. Walker, R.A. and Thomas, D.E. (1985), “A Model of Design Representation and Synthesis”, Proceedings of Conference on Design Automation. 176

Warell, A. (1999), “Introducing a Use Perspective in Product Design Theory and Methodology”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDEC/CIE. Watanabe, K., Mikoshiba, S., Tateyama, T., Shimomura, Y. and Kimita, K. (2011), “Service Design Methodology for Cooperative Services”, Proceedings of the ASME International Design Engineering Technical Conferences & Computer and Information in Engineering Conference IDETC/CIE. Watson, D. (1992), “Correcting for Acquiescent Response Bias in the Absence of a Balanced Scale. An Application to Class Consciousness”, Sociological Methods Research, Vol. 21 No. 1, pp. 52–88. Weber, C. (2007), “Looking at ‘DFX’ and ‘Product Maturity’ from the Perspective of a New Approach to Modelling Product and Product Development Processes”, Proceedings of the 17th CIRP Design Conference. Weilkiens, T. (2008), Systems Engineering mit SysML: Modellierung, Analyse, Design, dpunkt.verlag, Heidelberg. Welp, E.G., Sadek, T., Müller, P. and Blessing, L.T.M. (2007), “Integrated Modelling of Products and Services. The Conceptual Design Phase in an Integrated IPS2 Development Process”, Beiträge zum 18. Symposium "Design for X". Wynn, D. and Clarkson, J. (2005), “Models in Designing”, in Clarkson, J. and Eckert, C. (Eds.), Design Process Improvement: A Review of Current Practice, Springer-Verlag, London. Wynn, D., Eckert, C. and Clarkson, J. (2007), “Modelling Iteration in Engineering Design”, Proceedings of the 16th International Conference on Engineering Design – ICED. Yin, R.K. (2009), Case Study Research: Design and Methods, Applied Social Research Methods Series, Sage Publications, Los Angeles. Zafirov, R., Kiefer, J. and Eigner, M. (2010), “Functional Modelling for Efficient Generation of Mechatronic Design and Validation Models of Automated Production Installations”, Proceedings of 11th International Design Conference – DESIGN. Zimmerman, T. (2008), “Implementing PLM Across Organisations. For Multi-disciplinary and Crossfunction Product Development”, Dissertation, Chalmers University of Technology, Gothenburg. Zwicky, F. (1989), “Entdecken, Erfinden, Forschen im Morphologischen Weltbild. Mit Diagrammen”, Baeschlin-Verlag, Glarus (Germany).

177

178

CLASSIFICATION OF FUNCTION MODELS PROPOSED IN LITERATURE

Function tree Function-Means-Tree

(x)

x

Functions list

x*

Hubka, Eder 1988, Eder and Hosnedl 2008

Transformation process structure

(x)

x

x

Hundal 1990

Black box model

x

x

(x)

Pahl et al. 2007

Black box model

x

x

(x)

Rodenacker 1970

Black box model

(x)

x

(x)

Stone, Wood 2000

Black box model

x

x

(x)

Ullman 2010

Function tree

x

(x)

Ulrich and Eppinger 2008

Black box model

x

x

x

o

o

x

x

(x)

x

x

x

x

x

x

x

x

Pugh 1991 Ullman 2010

Black box model

Hubka, Eder 1988, Andreasen and Hein 2000 Tjalve 1978

Process-function chart

x

x o

x

x o o

o

o (x)

o

o

x x

Man/machine separation list

Tjalve 1978

Process flow model

Tjalve 1978

Black box model

x

x

(x) o

Process-function chart

Tjalve 1978

Man/machine separation list

x

x

x

Process structure

Blessing and Upton 1997

Transformation process structure

Hubka, Eder 1988, Eder and Hosnedl 2008

Black box model

x

User action sequence

Ulrich and Eppinger 2008

Black box model

x

Use concepts

Roozenburg and Eekels 1995

x

x

x

x

x*

(x)

o x

M

x

M

x x

x

o

x x

179

Flow of operands (input/output relation)

Hierarchical structure

Stakeholder allocation

x

Ehrlenspiel 2007

Energy, Material, Signals (E, M ,S)

Mechanical engineering

Function structure

Model builds upon

Morphologies

Technical system allocation

Ehrlenspiel 2007

Use case

References

Functions list

Interaction processes

Function models

Effects

function modelling perspective may be included implicitly addressed in function model changed states included after each operation states proposed as pre- or post condition of operation

States

(x) o x* x**

Function modelling perspectives

Flow in time

Legend: empty does not apply; not included black cell driving aspect grey cell function modelling perspective is explicitly addressed

Transformation processes

APPENDIX A:

x x

x

x

x x x

E,M,S

Iwasaki et al. 1993

Finite state machine Function block diagrams Function tree Function table Petri net Sequence diagram (V)HDL specification Feature list Function flow diagram IDEF-0 (SADT) Release backlog Sequence diagram Storyboarding Use case descriptions

Belzer et al. 1975

Use case schematics

Service development and PSS design

Use case activity flow diagram Block diagram Customer activity cycle (CAC) Customer chain (CC) model FAST (Function Analysis System Technique) Functional block diagram (FBD) Interactor network IDEF-0 (SADT) Service blueprint Service process model Scenario model (transition graph) Flow model Scope model Chain of actions View model View model and realisation structure

x x x

van Alven 1964

Scheffer et al. 2006

x (x) x

Scheffer et al. 2006, Baumgarten 1996 ISO 2012 Dewey 2000, Bleck et al. 1996 Kroll and Kruchten 2003, Kruchten 2004 Bosman 1978

x*

Ross 1977 Schwaber 2007 Use case description and schematics

(x)

Cooper 2007 Kruchten 2004, IABG 2006

Use case description

(x)

Feature list

Kruchten 2004, IABG 2006

Use case schematics

Fisher and Schutta 2003 Tan 2010 Donaldson et al. 2006

x

Kaufman and Woodhead 2006 Maussang-Detaille 2008 Maussang-Detaille 2008

(x) (x)

o

x x x x x x x x x

x

x*

Shostack 1982, Shostack and Kingman-Brundage 1991

x* x

Watanabe et al. 2011

x

x x x x x (x) x

x x x x x x x

(x) x

x x x

x x x

x

(x)

o o

x (x)

x x

180

x x x

x

(x) x

x x (x)

x x x

x x (x)

x

x

x

x

(x) (x) x (x) x x x x (x) x x

x (x) x x

x x x (x) (x)

(x)

Flow of operands

x x

(x)

o

M,S S

(x) x x

(x)

x x x

Flow in time

x (x)

(x)

x x (x) x x x x

x

Sakao and Shimomura 2007

Hierarch. structure

Stakeh. allocation

Technical system allocation

x (x) (x)

(x)

Maussang-Detaille 2008 Ross 1977, Maussang-Detaille 2008

Use case

o (x)

x

IABG 2006, ISO 2012 Kruchten 2004

Interact. processes

Transform. processes

x

x x

Scheffer et al. 2006

Kruchten 2004, IABG 2006

Effects

States

Electrical engineering Software development

Causal Functional Representation Language (CFRL)

o x

x x x

x x x x x x

o

x x x

M,S

Function tree

x

Purpose & transformation fct. model

x

x

Salminen and Verho 1989 Gausemeier et al. 2009 Kajitani 1986 (as quoted by Buur 1990)

Hybrid function/solution model

Möhringer and Gausemeier 2002

(Initial) behaviour diagram

Gausemeier et al. 2009

(Active) purpose functions

Buur 1990

State diagram

Salminen and Verho 1989

Context and flow diagram

Buur 1990

Functional Flow Blok Diagram (FFBD)

US DoD 2001, NASA 2007

IDEF-0

INCOSE 2010, US DoD 2001

N2-matrix

US DoD 2001, NASA 2007

State diagram

NASA 2007

Time Analysis Sheet

NASA 2007, US DoD 2001

(x)

System structure

x x

x

x

x

E,M,S

x x

x

E, S

x

(x)

x

x

o

x

o

(x) x

x

x

(x)

x

(x)

(x)

Use case schematics

(x) x

(x)

x

x x x

Use case schematic

x

(E,M,S)

(x) x x

x

x (x)

x

x

x

x

x

(x)

Use case schematic

x (x)

x Use case description and schematics

Weilkiens 2008

E,M,S

x

x

Sequence diagram

Use case activity flow diagram

x

(x)

Activity flow diagram (flow of use cases) State diagram

x

x (x)

x x*

** o x

x

x

Buur 1990

Transformation functions

(x) x

Black box model

Flow of operands

x

x x

Flow in time

x

x

Hierarch. structure

x

Use case

x x x

x

Event list

Function structure

State transition diagram

Stakeh. allocation

Buur 1990

Technical system allocation

Function-Means-Tree (expanded)

Interact. processes

Salminen and Verho 1989

Transform. processes

Salminen and Verho 1989

Event list

Effects

States

Mechatronic system development Systems engineering

Context and flow diagram

x

x

** “discrete”, “continuous”, and “signal event” flows

181

APPENDIX B: STUDIES I.

PARTCIPANTS OF EMPIRICAL

Participants’ profiles – Initial evaluation study

Strategic manager (n=5)

4-6

x

x

Electrical engineering

4-6

x

x

Electrical engineering

4-6

Software development

> 20

Geography

> 20

x x x

Educational background

Σ years of professional experience

Electrical engineering

System level design

Software development x

Service design

Electrical engineering

Mechanical engineering

x

x

Mechanical engineering

10 - 20

Further expertise acquired in former employments Product designer in after-market services

Electrical engineering

10 - 20

Electrical engineering

10 - 20

Specialist designer

Robotics and automation, energy management

10 - 20

Software service and machinery design

x

Mechanical engineering

10 - 20

x

Aerospace technology, electro-mechanics

10 - 20

x

Mechanical engineering

x

Aerospace technology

x

Mechanical engineering

x

Mechanical engineering, engineering design research

10 - 20

Project management

x

Electrical engineering

10 - 20

Systems engineering

x

x

Mechanical engineering, engineering design research

7-9

x

x

Mechanical engineering

7-9

Specialist designer

x

x

Mechanical engineering

> 20

Specialist designer, project manager

x x x

x

Middle manager (n=3)

Systems eng. (n=2)

Team leader (n=4)

Specialist designers (n=6) Current role

Discipline(s) participant is typically involved in

4-6 10 - 20 4-6

183

Consulting in project management

II.

Participants’ profiles – Interview study

Software development

Mechanical engineering

4-6

x

Aerospace technology, eng.design research

7-9

x

Mechanical engineering

7-9

x

Mechanical engineering

4-6

x

Mechanical engineering

10 - 20

Electro-mechanics

10 - 20

x

System-level design

Mechanical engineering, eng.design research

Service design

x

Electrical engineering

Educational background

Σ years of professional experience

Specialist designer (n=11)

Current role

Discipline(s) participant is typically involved in

x x

x

Electrical engineering

4-6

x

x

Electrical engineering

> 20

x

x

Electrical engineering

4-6

x

Software development

> 20

Geography

> 20

x x

Electrical engineering

10 - 20

x

Electrical engineering

10 - 20

x

Electrical engineering

10 - 20

x

Business and marketing

10 - 20

x

Robotics/automation, energy management

10 - 20

Middle manag.(n=3)

SE (n=2)

Team leader (n=7)

x

x

x

Mechanical engineering

> 20

x

Mechanical engineering

10 - 20

x

Aerospace technology, electro-mechanics

10 - 20

x

Mechanical engineering

x

Software development, business and marketing

10 - 20

x

Aerospace technology

10 - 20

x

Mechanical engineering

4-6

Mechanical engineering

> 20

Electrical engineering

> 20

x

Corporate manager (n=12)

x

x

x

x x

x

Further expertise acquired in former employments

Automation

Systems testing and validation

Software service and machinery design

4-6

Consulting in project management

x

Mechanical engineering

10 - 20

Project management

x

Engineering and business administration

10 - 20

Consulting in project management

x

Experimental physics

10 - 20

x

N.A.

4-6

x

Mechanical engineering, eng.design research

10 - 20

x

Electrical engineering

10 - 20

Systems engineering

x

x

Electrical engineering

10 - 20

Development and testing

x

x

Electrical engineering

10 - 20

Systems testing and validation

x

Mechanical engineering

7-9

x

Mechanical engineering

10 - 20

184

APPENDIX C:

I.

QUESTIONS FOR EMPIRICAL STUDIES

Interview Study – Question Catalogue

PART I:

CONTEXT 

What is the participant’s typical role, involvement and approach taken during the conceptual design stage (including central design steps and applied models)?



What is the interviewee’s understanding of “function”?

PART II:

FUNCTION MODELLING 

In which models (= documents, descriptions, modelled representations, etc.) are functions/the required system functionality typically represented?



What are the models used for?



If different models of function are used, are these typically developed - in parallel? - sequentially (building up on each other?)?



Which models are or have been used in other projects? Why are those not used in the case study project?



Which experiences have been made (good and bad) with applying function models for modelling information?

Supporting questions:  What is a function model in your view?  Which models do you know that represent functions/system functionality? Which do you personally use? Are these generated by you?  Can you give/show me an example?  How do you reason about function models?  How do you usually use them? Please explain a typical situation!  How do you proceed in modelling this model? PART III:

CROSS-DISCIPLINARY COMMUNICATION 

Which of these models are used for exchanging information on system functionality with - colleagues from the same discipline? - colleagues from other disciplines?



Why have these models been chosen for communication and how suitable are they regarded to support communication? - Why are these models not used for communicating information? - Which problems do occur when using them?

While communicating the product functionality with colleagues from other disciplines,  Is this/are these model(s) understood well across disciplines? 185



Where (in a specific model) do problems occur understanding modelled information? - Why? - What seems to be the deficit with the used models? - What else is needed in a specific model or would be considered useful?

Supporting questions and comments:  Please explain a situation when you were sharing this model with someone else!  Please describe a situation when specific problems occurred! - What led to those problems? - What seemed to be causing the difficulties? - Could you give me an example? - What kind of feedback did you get on the model? - What seemed to be the other person’s view on the problem/model? - Has the other person been asking question about certain aspects? - What kind of information seemed to be important to the other person?  Can you remember a concept had to be changed because of conflicts in used function models? - During related discussion, did you get a lot of queries on specific aspects? - Did another person express problems understanding something? PART IV:

FURTHER MODELS AND EXPERIENCES 

Has the use of (an) alternative function model(s) been attempted?



What experiences were made with these design models? Why are they no longer applied?



Which other models are known but not used? Why are they not used?



Has a new function model been introduced to the design team/the design process? - What was the motivation behind this introduction? Why was the new model considered necessary? - What kinds of experiences were made while introducing the new model? - What was the result? What has changed since the introduction?

PART V:

PREFERENCES AND SUPPORT 

What kind of abstract representation or visualisation of functions and system functionality is preferred by the participant?



What kind of support is needed or considered useful in relation to function modelling?



What is expected of an interdisciplinary function modelling approach?

PART VI: 

END Recording the individual profiles of the participant: - Individual roles within the case study project and in former (similar) development projects - Detailed educational background - Professional career development (in former companies, in the current company)

186

II.

Evaluation study – Questionnaire

QUESTIONNAIRE CONFIDENTIAL Participation in the study is completely voluntary. You may withdraw your consent at any time without reason and without negative consequences to you. Any data given in the questionnaire will be dealt with confidentially and will be used for scientific purposes only. Data storage, processing, and publication will be conducted anonymously. You may request deletion of your data at any time. Please do not hesitate to clarify any further questions you may have. This questionnaire is intended to support the improvement of a function modelling framework. Your answers will help developing the framework further, specifically with regard to its application in an industrial context. 

The processing of the answers given is completely confidential; please do not hesitate to give honest feedback.



Please read each question carefully, and give your opinion with regard to what you require or consider helpful in your daily work.



Please answer all the questions.

Participant’s approval: With your signature you confirm that you have been informed about the nature of the study as well as your rights regarding confidentiality and withdrawal from participation.

_____________________________________________ (Place, Date)

Thank you for your cooperation!

187

1. Do you consider the following elements and aspects useful for your work in a typical development project?

a. Process Flow View 

Technical processes

Yes

No

Don’t know



Human processes

Yes

No

Don’t know



Sequence/parallelism of processes

Yes

No

Don’t know



Alternative flows of processes

Yes

No

Don’t know



Quantities and/or Constraints

Yes

No

Don’t know

 Do you have general comments regarding this view (e.g. any additional information you would have liked/considered useful)?

b. Actor View 

Concerned stakeholders

Yes

No

Don’t know



Concerned technical (sub-) systems

Yes

No

Don’t know



Impacts on/from the environment

Yes

No

Don’t know



Separating internal and external actors

Yes

No

Don’t know



Roles of individual actors (e.g. as supporting.)

Yes

No

Don’t know

 Do you have general comments regarding this view?

c. Use Case View 

Use cases (in general)

Yes

No

Don’t know



Involvement of processes in multiple use cases

Yes

No

Don’t know



Dependencies between alternative use cases

Yes

No

Don’t know

 Do you have general comments regarding this view?

188

d. State View 

Actor states

Yes

No

Don’t know



Operand states

Yes

No

Don’t know



Processes related to state changes

Yes

No

Don’t know

 Do you have general comments regarding this view?

e. Effect View 

Physiochemical effects (in general)

Yes

No

Don’t know



Effects related to different processes

Yes

No

Don’t know

 Do you have general comments regarding this view?

f. Interaction View 

Mutual impacts between actors

Yes

No

Don’t know



General relations/dependencies between actors

Yes

No

Don’t know



Impacts between actors and operands

Yes

No

Don’t know



Mutual impacts between operands

Yes

No

Don’t know



Interfaces between entities (operands, actors)

Yes

No

Don’t know

 Do you have general comments regarding this view?

2. Is any information missing, you would have liked/considered useful? If yes, please indicate:

189

3. Please indicate in the following figure which particular views (boxes) and links

USE CASES

(arrows) you consider useful or not useful.

UPD view PROCESSES

Please use: ‘+’: view/link considered useful ‘– ‘: view/link not considered useful No mark = ‘don’t know’

Process flow view

State view

PROCESSES

ACTORS

OPERANDS

PROCESSES

Effect view

Actor view

OPERANDS

ACTORS

OPERANDS

ACTORS

ACTORS

Interaction view

     

4. Would you consider using the framework in future design work?



Yes

Parts of it

With adaptions

No

Please explain shortly:

190

5. Would you generally prefer an alternative setup (to the concept of associated, modular views) or representation for the framework? Any other comments? 



191

APPENDIX D:

I.

CONCEPTUAL DESIGN IN PRACTICE

Examples of conceptual design approaches from three companies

Figure D-1 and Figure D-2 illustrate examples of typically applied top-down conceptual design approaches, taken from two visited companies: Company B and Company H. The specific approach applied in Company H can be regarded one of the most advanced with respect to the use of function modelling within and across involved disciplines. In addition the conceptual design process from Company G (currently not using function modelling) is presented.

Customer requirements specifications

Requirements specification

Translating initial into detailed requirements

Function model Detailed system requirements specification

(Not shown: personally used models addressing the solution)

Level 3 function modelling shared between selected disciplines

Mechanical engineering Grafcet

Model(s) addressing solution Electrical engineering Model(s) addressing solution

Level 1 personal function modelling

Allocation to concerned sub-systems

Standard system structure

Model addressing solution

Software development Model(s) addressing solution

New/ updated system structure

Legend

“State/position diagram”

Figure D-1: Typical sequence of applied models during conceptual design in Company B

193

key designers from different disciplines

Company B is active in special machinery design. Discipline-specific conceptual design is mainly performed sequentially. Therein, the development process is led by mechanical engineering. In mechanical engineering no separate function model is used (see Figure D-1). The developed mechanical design concept is used by electrical engineering and software development for the generation of a shared function model (level 3) using Grafcet. This is performed by a designer involved in both electrical engineering and software development before going into discipline-specific development. This may involve additional designers also using the generated Grafcet model. In addition, a personally used function model (level 1) was found.

Company G is an exceptional case. It is a small start-up company developing and offering web-based telecommunication services. The applied development process does not involve a distinct sequence of design steps or systematic specification of requirements and function modelling. The company performs on-demand adaptations to their system. This mainly involves small-scale modification of the existing software code, in order to adapt the offered service. That means, to adapt or expand the functionality provided by the software system as requested by customers. At the time of the study, the company was evaluating different modelling options, in order to facilitate systematisation of their design processes as well as service planning and delivery.

Translating initial into detailed requirements Sorting requirements into functional/ non-functional

Legend Requirements specification

Customer requirements specifications

Function model Model addressing solution

Deriving main system functions and sub-functions

Detailed system requirements specification

(Not shown: personally used models addressing the solution)

Allocation to concerned sub-systems

system level function modelling

Standard system structure

“System function requirements document”

Level 4

Sub-system requirements specification

Finite state machine, function flow charts

System-level design Disciplinary design Level 2

Electrical engineering

Software development

Model(s) addressing solution

Model(s) addressing solution

function modelling within disciplines

Mechanical engineering

Use Case analysis Model(s) addressing solution

Supervision by systems engineer

function modelling shared between selected disciplines

New/ updated system structure

Level 3

Guided by systems engineer (may be supported by key designer from different disciplines, if required)

Company H develops mechatronic systems that provide users with specific data. Offered services include sales and online-distribution of this data to customers. Conceptual design starts with generation of a system-level function model from the requirements specification. This is mainly performed by the systems engineer, typically using input from service design. Depending on the specific design project, further key designers from involved disciplines may be contributing to the generation of the model. The model mainly consists of (hierarchical) lists describing the required main system functions. It is used to facilitate decomposition of the system functionality and support determining and allocating the sub-systems foreseen for implementing the main functions. The model is sometimes complemented with a deployment specification (as a partial model), which describes the different states that the system can be in during operationalization and usage.

Figure D-2: Typical sequence of applied models during conceptual design in Company H The systems engineer further explained to have used use case schematics in one project, in order to deepen the understanding of required functions and system context. Based on the developed models, functions and requirements are allocated to specific sub-systems, which are eventually designed 194

within different disciplines. Sub-system decomposition is based on a generic system structure, which is used as a starting point in most design projects. Software development is typically closely collaborating with the service designers in the company, because service delivery is mainly tackled by software systems processing and distributing the collected data to the customers. In order to facilitate sub-system development, a key designer involved in electrical engineering and software development generates specific function models, which may be shared with service design, electrical engineering, and/or software development (level 3). Within software development use case modelling is applied by different designers (level 2).

195

II.

Integration of service and products development in visited PSS design companies

Company G employs a particularly service-oriented business model. Design efforts focus on the software system providing for the web-based service delivery. A highly adaptive design process is applied. Integration of service design and software development is facilitated by continuous discussions between the key designers regarding which functions to be included in the offered service, i.e. to be implemented in the software system. Company H, I, and J used to employ a business model focusing on development, manufacture, and sales of mechatronic systems. In all three cases, integration of services into the business model and the development process has been advanced in the past, most notably in Company H and Company J. Company H is a developer and manufacturer of mechatronic systems that automatically gather and distribute specific data. The core business model traditionally has been on-demand development, manufacture, operationalization, and sales of the systems to customers. In the recent past, a second type of business model has been introduced in addition. It focuses on delivery of the collected data to customers as a service. As a consequence, Company H started developing systems on their own account, which remain in the possession of the company. For the development of respective systems, the systems engineer generates a system function model in collaboration with service design as well as incorporating inputs from key designers from other involved disciplines. In addition, the service designer closely collaborates with the person from software development who is responsible for implementing data distribution to customers. Exchange between designers is facilitated by regular meetings and personal discussions as well as through the systems engineer. Company I is an established developer and manufacturer of consumer products. The core business model focuses on sales of the product to individual customers. Offered services mainly comprise of maintenance or replacement of malfunctioning equipment, which can be mailed to the company by customers. The company uses a Stage-Gate process after Cooper (2010). Integration of all involved disciplines (including service design) is facilitated by joint formulation of the requirements specification. Thus, any service-related aspects relevant for the development of the mechatronic system can be included therein. Furthermore, all involved disciplines have to approve the current design after each development stage. A similar approach is used in Company J. Like in Company I, a Stage-Gate process is applied and integration of disciplines is facilitated in the same manner. Company J is an established developer and manufacturer of manufacturing machinery. The company recently changed its business model from focusing on sales of the developed technical product to more service-oriented business. The change was introduced, in order to provide the customers with additional value and establish a more continuous business connection. Before the introduction of the new business model, offered services mainly focused on maintenance of malfunctioning equipment. Nowadays, the company offers more “proactive” services along with the sold system. Proactive services include regular maintenance cycles, on-line surveillance, as well as regular updating of the equipment to newly developed technologies. This change in the business model triggered an increased integration of service design into the design team of the technical product. Further integration is expected for the next product generations.

196

III.

Examples of function modelling approaches proposed in companies

In both examples, a specific sequence of distinct modelling steps in relation to associated models is proposed for individual designers to employ. In both companies, the practical application of the modelling approaches, however, has been described to progress highly iteratively, while the related information is gradually entered into the models. Function models are highlighted in bolt in the tables. Company A Step

Description

Related model

1

Determining central functions and sub-functions

Requirements list, initial drawings, textual descriptions

2

Establishing and modelling flow of functions

Initial list of functions

3

Determining initial set of electrical components associated to the functions

Grafcet

4

Determining required states before and after each function (pre- and postconditions) and design electrical ports accordingly to enable detecting the states of allocated electrical components in the system.

Circuit diagrams

5

Detailing of models and transfer of function flow into PLC programming environment.

6

Determining central functions and sub-functions

Grafcet, circuit diagrams

Company D Step 1 2 3 4 5

Description Analysis of requirements list and differentiation between functional requirements and non-functional requirements Provide attributes to each requirement (e.g. understood, open questions remaining) as well as initial allocation to concerned disciplines Determine the main use cases from the given set of functional requirements and provide labels (names) for each use case Establish primary, secondary, and tertiary actors (humans, technical systems) for each use case as well as their interactions within use case fulfilment Determining primary actors' goals and associated pre- and expected postconditions for each use case

6

Sorting functional requirements into different use cases

7

Differentiating primary, secondary, and tertiary use cases

8

Expanding, detailing and complementing the use cases with additional required functions (activities or technical processes), in order to establish a consistent function flow within each use case

9

Sorting and specifying constraints, target values etc. for different use cases in a separately generated, complementary document

10

Establishing and detail function flow for each use case

197

Related models Attributed requirements list

no specific model proposed

Use case descriptions

Supplementary requirements specification Use case activity flow diagrams

APPENDIX E: PRACTICE

I.

FUNCTION MODELS FOUND IN

Referenced function models

Function model

Origin

Finite state machine

Belzer et al. (1975)

Currently applied in

Utilised in the analysis (1/0)

C, D, F

1

"Function cycle breakdown"

in-house developed

J

1

"Function database"

in-house developed

E

1

N.A.

0

Function Flow Block Diagram (FFBD)

e.g. US DoD (2001)

Function flow diagram

adapted from Matlap/Simulink

E

1

Function flow model

adapted from activity diagram

D

1

Function flow chart

Use case activity diagram

H

1

"Function Parameter Model"

adapted from classical mechanical engineering literature

F

1

not provided

C

1

under development in-house

Function runtime model Allocation matrix

N.A.

0

Grafcet

VDE (2004)

A, B

1

IDEF-0

Ross (1977)

C

1

Morphological chart

similar to Pahl et al. (2007)

C, F, I

1

MERISE

Avison (1991)

N.A.

0

N2 matrix

e.g. US DoD (2001)

N.A.

0

Sequence diagrams

UML

C

1

I

1

"Service flow model"

not provided

"Service process model"

in-house developed

J

1

"State/position diagram"

in-house developed

B

1

"State/time diagram"

in-house developed

J

1

"System Function Requirements Document"

Deployment specification

“System Function Specification”

Function Flow Structure

Functional system specification

similar to US DoD (2001)

in-house developed

Function Allocation Chart

H

F

1 1 1 1

Use case description

adapted from UML

D

1

Use case activity flow model

Rational Rhapsody

D

1

Use case schematics

UML

C, H

1

199

II.

Expressed strengths and weaknesses

Function model Finite state machine "Function cycle breakdown" "Function database" Function flow diagram Function flow model Function flow chart "Function parameter model" Function runtime model

Currently applied in

Expressed strengths (+) and weaknesses (–)

C, D, F

N.A.

J

+ easy-to-understand representation of function flow

E

E D

N.A.

H

+ easy-to-understand representation - also across disciplines - of functions and their flows

F

N.A.

C

N.A.

Grafcet

A, B

IDEF-0

C

Morphological chart Sequence diagrams "Service flow model" "Service process model" "State/position diagram" "State/time diagram"

+ (once accustomed to it) easy-to-use approach for discussion about suitable solution concepts

C

N.A.

I

N.A.

J

+ easy-to-understand representation of service activities

B

N.A.

J

N.A.

H

"System Function Specification"

F

Use case description

Use case schematics

+ supports analysis of logical consistency and completeness of proposed sequence in function flow + supports comprehensive analysis of required functionality, if performed exhaustively - model becomes very complex and large very quickly

C, F, I

"System function requirements document"

Use case flow model

+ allows for comprehensive description of system functions and sub-functions + support determination and specification of required electrical sub-systems and software + supports exchange of information about sub-systems and their functions - does not include functions typically implemented by mechanical engineering - now and then difficulties arise from specific formulations + supports implementation of functions in control systems + supports discussions within and between electrical design and software development

D

H C

+ supports comprehension of required system functionality + support determination and specification of required sub-systems - specific formulations in the document can be difficult to understand and require further explanation, particularly across disciplines - dependencies between sub-systems in function and requirements fulfilment not made explicit + consistency in linking requirements to functions to associated sub-systems + supports failure analysis in a system by making interactions between sub-systems explicit + supports communication in general as "one knows who to talk to" + matrix for links between functions and sub-systems clear and easy-to-read + can be easily reused in subsequent design projects + supports novice designers in establishing an overall understanding of the system under development - extremely large document, which is considered difficult to read - not considered to provide benefit for solution finding process in mechanical engineering + supports obtaining an overview of the system, its borders, the involved actors and their goals + supports traceability of how requirements have been allocated into a concrete solution + supports planning of project and required resources + supports communication with other software developers in different sites - specific formulations in the document can be difficult to understand + well suited for obtaining an understanding and make explicit the context of the system to be developed, including system border, different actors, their interactions and the central functions expected in a system + well suited to understand the different actors, their interactions and the central functions expected in a system to be developed

200

201

202