Systems engineering, systems thinking, and learning  a case study in space industry

Understanding Complex SystemsSystems Engineering, Systems Thinking, and Learning Hubert Anton Moser A Case Study in Space Industry Tai ngay!!!. Short and long term mechanisms essential

Understanding Complex Systems

Systems Engineering, Systems Thinking,

and Learning

Hubert Anton Moser

A Case Study in Space Industry

Tai ngay!!! Ban co the xoa dong chu nay!!!

Founding Editor

Prof Dr J.A Scott Kelso

Center for Complex Systems & Brain Sciences

Florida Atlantic University

Boca Raton FL, USA

Entrepreneurial Risk, ETH Zürich, Zürich, Switzerland

For further volumes:

http://www.springer.com/series/5394

Understanding Complex Systems

Future scientific and technological developments in many fields will necessarily depend upon coming

to grips with complex systems Such systems are complex in both their composition - typically many different kinds of components interacting simultaneously and nonlinearly with each other and their envi- ronments on multiple levels - and in the rich diversity of behavior of which they are capable.

The Springer Series in Understanding Complex Systems series (UCS) promotes new strategies and paradigms for understanding and realizing applications of complex systems research in a wide variety of fields and endeavors UCS is explicitly transdisciplinary It has three main goals: First, to elaborate the concepts, methods and tools of complex systems at all levels of description and in all scientific fields, especially newly emerging areas within the life, social, behavioral, economic, neuro and cognitive sci- ences (and derivatives thereof); second, to encourage novel applications of these ideas in various fields

of engineering and computation such as robotics, nano-technology and informatics; third, to provide a single forum within which commonalities and differences in the workings of complex systems may be discerned, hence leading to deeper insight and understanding.

UCS will publish monographs, lecture notes and selected edited contributions aimed at ing new findings to a large multidisciplinary audience.

communicat-Springer Complexity

Springer Complexity is an interdisciplinary program publishing the best research and academic-level teaching on both fundamental and applied aspects of complex systems - cutting across all traditional dis- ciplines of the natural and life sciences, engineering, economics, medicine, neuroscience, social and com- puter science.

Complex Systems are systems that comprise many interacting parts with the ability to generate a new quality of macroscopic collective behavior the manifestations of which are the spontaneous formation of distinctive temporal, spatial or functional structures Models of such systems can be successfully mapped onto quite diverse “real-life” situations like the climate, the coherent emission of light from lasers, chem- ical reaction-diffusion systems, biological cellular networks, the dynamics of stock markets and of the internet, earthquake statistics and prediction, freeway traffic, the human brain, or the formation of opin- ions in social systems, to name just some of the popular applications.

Although their scope and methodologies overlap somewhat, one can distinguish the following main concepts and tools: self-organization, nonlinear dynamics, synergetics, turbulence, dynamical systems, catastrophes, instabilities, stochastic processes, chaos, graphs and networks, cellular automata, adaptive systems, genetic algorithms and computational intelligence.

The two major book publication platforms of the Springer Complexity program are the monograph series “Understanding Complex Systems” focusing on the various applications of complexity, and the

“Springer Series in Synergetics”, which is devoted to the quantitative theoretical and methodological dations In addition to the books in these two core series, the program also incorporates individual titles ranging from textbooks to major reference works.

foun-Systems Engineering, Systems Thinking,

and Learning

A Case Study in Space Industry

ABC

Hubert Anton Moser

LuxSpace Sàrl

Betzdorf

Luxembourg

ISBN 978-3-319-03894-0 ISBN 978-3-319-03895-7 (eBook)

DOI 10.1007/978-3-319-03895-7

Springer Cham Heidelberg New York Dordrecht London

Library of Congress Control Number: 2013955727

c

Springer International Publishing Switzerland 2014

This work is subject to copyright All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer Permissions for use may be obtained through RightsLink at the Copyright Clearance Center Violations are liable to prosecution under the respective Copyright Law.

The use of general descriptive names, registered names, trademarks, service marks, etc in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

While the advice and information in this book are believed to be true and accurate at the date of lication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made The publisher makes no warranty, express or implied, with respect

pub-to the material contained herein.

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)

Nowadays system development is multi-disciplinary Disciplinary knowledge, perspectives and thinking no longer suffice to develop systems in an efficient and effective way Development team members need to consider the system as a whole and work together closely across disciplinary boundaries, and systems engineers are required that know enough of the disciplines involved to ensure the total quality of the system

Although the concepts of systems engineering and systems thinking have been around for several decades, an understanding of how developers actually work together across disciplinary boundaries and how they learn from each other, is still lacking What does it mean to think in terms of systems in the context of a highly integrated system in which partial, disciplinary solutions affect each other? How

do developers learn from each other in such a multi-disciplinary environment, i.e.,

how does systems thinking evolve? And most importantly, how can we improve this process: How can systems thinking be learned more effectively and efficiently given the fact that our education is essentially disciplinary?

These questions are addressed in this book in a unique way as part of a PhD project executed within space systems industry To understand systems thinking, methods from educational and social sciences were used in an engineering context, multiple real development projects in industry were analyzed, and the analysis covered an extended period of time A multi-level analytical framework was developed, based on activity theory, allowing a detailed analysis of multidisciplinary interaction over time Short and long term mechanisms essential for learning to think in systems were identified, and finally, a strategy called WAVES (Work Activity for a Versatile Evolution of Systems engineering and thinking) was developed to improve the evolution of systems thinking

This book is an excellent resource for researchers and practitioners interested in systems thinking and in solutions to support its evolution It not only provides an extensive overview of the developments in this field, but provides a unique and rich account of the practice of interaction between disciplines and learning across disciplinary boundaries Of particular interest for researchers is the developed analytical framework, which is applicable for the analysis of a wide variety of work activities in the context of engineering design and beyond Of particular interest for industry is the proposed human resource development strategy, WAVES, to improve the development process by improving the effectiveness of interaction between disciplines, the speed of systems thinking development, and the quality of boundary management

When Hubert contacted me with his idea for a research project, we could not have anticipated the richness of the project and the results Not only did the

VI Foreword

research deal with multidisciplinarity in an engineering context, it was multidisciplinary in its own right, involving concepts, methods and strategies from yet other, non-engineering disciplines The dedicated involvement of LuxSpace and my colleague Gudrun Ziegler have been essential in achieving the depth and quality the topic requires Most of all, however, Hubert has to be credited with actually crossing boundaries, venturing into unfamiliar disciplines, bringing everything together, and providing the reader with a unique account of systems thinking and a solution for its improvement

Luxembourg

There are numerous people I would like to thank for their support during the endeavour of my doctoral dissertation, which is presented in this book I am not able to express my thanks to all of them

I want to thank the members of my supervisory committee who facilitated this research project by their guidance and support From University of Luxembourg: Prof Dr.-Ing Lucienne Blessing (chair), Prof Dr Gudrun Ziegler, Prof Dr Charles Max, and Prof Dr Michel Marso From LuxSpace Dr Jeroen Buursink who supported me already before the start of this project when I started at LuxSpace and Florio Dalla Vedova who played a major role in the definition and initiation of this research project Furthermore, I would like to thank Prof Dr Alex Duffy from University of Strathclyde for his support and for being a member

of my dissertation defence committee

This work would not exist without the willingness of the study participants, in particular from LuxSpace and the DLR Institute of Space Systems It was a privilege to work with you Thanks for enabling the access to all the studies go to Jochen Harms (Managing Director of LuxSpace), Dr Oliver Romberg (Head of the Department System Analysis Space Segment in the DLR Institute of Space Systems), and Prof Dr André Balogh (International Space Science Institute, Headtutor of the Alpbach Summer School 2009)

Special thanks go to the members of the research group DICA (Dynamics in Interaction, Communication, and Activity) who played an eminent role in my personal development and in this research project I would like to thank the members of the Engineering Design and Methodology research group of University of Luxembourg for their support and help I am also indebted to all the others who provided inspiration, help, support, and encouragement in various ways

I am grateful to the National Research Fund of Luxembourg for funding this research project in a Public-Private Partnership of LuxSpace and University of Luxembourg under the AFR (Aides à la Formation-Recherche) scheme I wish to thank Springer, in particular Dr Leontina Di Cecco, for providing me the opportunity and support to reach a broad audience

My warmest thanks go to my family and friends who supported me during the challenging episodes and celebrated with me the delightful moments

Villmols Merci

Contents

List of Acronyms XVII

Part I: Introduction of the Research Project 1

1 Introduction 3

1.1 Motivation 3

1.2 Objectives and Research Question 5

1.3 Scope 5

1.4 Structure of the Book 7

References 8

2 Systems Engineering and Learning 11

2.1 Systems Engineering 11

2.1.1 System 11

2.1.2 Characteristics of Systems Engineering 13

2.1.3 Systems Engineering within Multi-disciplinary Teams 21

2.1.4 Conclusion 22

2.2 Systems Thinking, Knowledge, and Interaction in Engineering 22

2.2.1 Systems Thinking 23

2.2.2 Knowledge 28

2.2.3 Interaction 30

2.2.4 Conclusion 33

2.3 Learning in Engineering 33

2.3.1 Definitions and Theories of Learning 33

2.3.2 Models of Learning 36

2.3.2.1 Circular Models of Learning 36

2.3.2.2 Non-circular Models of Learning 40

2.3.3 Conclusion 42

2.4 Space 42

2.4.1 Space Missions and Systems Engineering 42

2.4.2 Multi-disciplinary Interaction in Space Systems

Engineering 45

2.4.3 Microspace 47

2.4.4 Conclusion 48

2.5 Conclusion 48

References 49

3 Research Approach 59

3.1 Research Questions 59

3.2 Research Methodology, Strategy, Methods, and Plan 60

3.2.1 Research Methodology 60

3.2.2 Research Strategy and Methods 61

3.2.3 Research Plan 62

3.3 Data Collection and Processing Approach 63

3.3.1 Overview of Considered Data Collection Methods 64

3.3.2 Prioritisation of Data Collection Methods 65

3.3.3 Processing of Multiple Data Sources 67

3.4 Analysis Framework 68

3.4.1 Frameworks for Analysing Human Activity 68

3.4.1.1 Levels and Units of Analysis 68

3.4.1.2 Actor Network Theory 68

3.4.1.3 Distributed Cognition 69

3.4.1.4 Activity Theory 70

3.4.1.5 Comparison 70

3.4.2 Analysing Work with Activity Theory 71

3.4.2.1 Activity-Action-Operation 71

3.4.2.2 Models of Activity Systems 72

3.4.2.3 Five Principles of Activity Theory 74

3.4.2.4 Matrix of Situatedness 75

3.4.2.5 Conclusion 77

3.4.3 Systems Thinking Taxonomy for Analysing Change of Knowledge 77

3.4.3.1 Modification of the Taxonomy of Anderson et al (2001) 78

3.4.3.2 Combination with Different Fields of Knowledge 80

3.4.3.3 Conclusion 81

3.4.4 Analysis Framework 81

3.5 Analysis Approach 82

3.5.1 Activity-Theoretical Analysis 83

3.5.1.1 Description of the ASN 83

3.5.1.2 Identification of Contradictions 84

3.5.2 Theme-and-Key-Event Analysis 86

3.5.2.1 Key Event Identification and Link to Themes 86

Contents XI

3.5.2.2 Analysis Zoom with Three Levels of Analysis 87

3.5.2.3 Ethnographic Statistics 92

3.6 Credibility of Research 92

3.7 Conclusion 93

References 94

Part II: Analysis and Findings of the Empirical Studies 91

4 Description of Empirical Studies 101

4.1 Empirical Studies Overview 101

4.2 Preparatory Study 1 (PS1) 103

4.2.1 Purpose and Design of PS1 103

4.2.2 Setup of PS1 103

4.2.3 Data Collection and Processing 104

4.3 Preparatory Study 2 (PS2) 104

4.3.1 Purpose and Design of PS2 104

4.3.2 Setup of PS2 105

4.3.3 Data Collection and Processing 106

4.4 Study 1 (S1) 106

4.4.1 Purpose and Design of S1 106

4.4.2 Setup of S1 107

4.4.3 Data Collection and Processing 116

4.5 Study 2 (S2) 118

4.5.1 Purpose and Design of S2 118

4.5.2 Setup of S2 118

4.5.3 Data Collection and Processing 119

4.6 Reflection on Data Collection and Research Ethics 121

4.7 Conclusion 122

References 122

5 Activity-Theoretical Analysis and Findings 125

5.1 Activity Systems Network of Preparatory Study 1 (ASN-PS1) 125

5.1.1 ASN-PS1 Activity of Interest 126

5.1.2 ASN-PS1 Objective 128

5.1.3 ASN-PS1 Subjects 128

5.1.4 ASN-PS1 Tools 128

5.1.5 ASN-PS1 Rules and Regulations 128

5.1.6 ASN-PS1 Division of Labour 129

5.1.7 ASN-PS1 Community 129

5.1.8 ASN-PS1 Contradictions 129

5.1.9 Conclusion 132

5.2 Activity Systems Network of Preparatory Study 2

(ASN-PS2) 132

5.2.1 ASN-PS2 Activity of Interest 134

5.2.2 ASN-PS2 Objective 134

5.2.3 ASN-PS2 Subjects 135

5.2.4 ASN-PS2 Tools 135

5.2.5 ASN-PS2 Rules and Regulations 136

5.2.6 ASN-PS2 Division of Labour 136

5.2.7 ASN-PS2 Community 137

5.2.8 ASN-PS2 Contradictions 137

5.2.9 Conclusion 140

5.3 Activity Systems Network of Study 1 (ASN-S1) 140

5.3.1 ASN-S1 Activity of Interest 141

5.3.2 ASN-S1 Objective 143

5.3.3 ASN-S1 Subjects 143

5.3.4 ASN-S1 Tools 146

5.3.5 ASN-S1 Rules and Regulations 148

5.3.6 ASN-S1 Division of Labour 150

5.3.7 ASN-S1 Community 150

5.3.8 ASN-S1 Contradictions 151

5.3.9 Conclusion 154

5.4 Activity Systems Network of Study 2 (ASN-S2) 155

5.4.1 ASN-S2 Activity of Interest 155

5.4.2 ASN-S2 Objective 156

5.4.3 ASN-S2 Subjects 157

5.4.4 ASN-S2 Tools 158

5.4.5 ASN-S2 Rules and Regulations 159

5.4.6 ASN-S2 Division of Labour 159

5.4.7 ASN-S2 Community 159

5.4.8 ASN-S2 Contradictions 160

5.4.9 Conclusion 162

5.5 Summary of Findings from the Activity-Theoretical Analysis 162

5.6 Conclusion 164

References 164

6 Contradiction-Driven Theme-and-Key-Event Analysis 165

6.1 Overview of Contradictions and Selected Themes 165

6.2 Description of Themes 165

6.2.1 Interproject 166

6.2.1.1 Macrolevel Analysis of Theme Interproject 168

6.2.2 Harness 174

6.2.2.1 Macrolevel Analysis of Theme Harness 174

6.2.2.2 Mesolevel Analysis Key Event Harness d901 175

Contents XIII

6.2.2.3 Mesolevel Analysis Key Event Harness d920 176

6.2.3 Li-Ion Cells 179

6.2.3.1 Macrolevel Analysis of Theme Li-Ion Cells 179

6.2.4 EMC & Mechanics 180

6.2.4.1 Macrolevel Analysis of Theme EMC & Mechanics 180

6.2.5 EMC & Power 181

6.2.5.1 Macrolevel Analysis of Theme EMC & Power 181

6.2.6 Sun Sensor 182

6.2.6.1 Macrolevel Analysis of Theme Sun Sensor 183

6.2.7 Accommodation 183

6.2.7.1 Macrolevel Analysis of Theme Accommodation 184

6.2.8 Stiffness 184

6.2.8.1 Macrolevel Analysis of Theme Stiffness 185

6.2.8.2 Mesolevel Analysis of Key Event Stiffness d892 186

6.2.8.3 Mesolevel Analysis of Key Event Stiffness d899 189

6.2.9 Radio 191

6.2.9.1 Macrolevel Analysis of Theme Radio 192

6.2.9.2 Mesolevel Analysis of Key Event Radio d794 194

6.2.10 AOCS-Fuel 198

6.2.10.1 Macrolevel Analysis of Theme AOCS-Fuel 198

6.2.10.2 Microlevel Analysis of an Instance in Key Event AOCS-Fuel d2_1149 201

6.2.10.3 Mesolevel Analysis of Key Event AOCS-Fuel d2_1154 203

6.2.11 Occulter 208

6.2.11.1 Macrolevel Analysis of Theme Occulter 209

6.2.11.2 Mesolevel Analysis of Key Event Occulter d2_1717 210

6.2.11.3 Microlevel Analysis of Key Event Occulter d2_1717 213

6.3 Detailed Description of Contradictions 214

6.3.1 Multiple Roles 214

6.3.2 Parameter Definition and Impact 216

6.3.3 Differences in Work Approaches and Ways of Interacting 218

6.3.4 Clash of Standards 220

6.3.5 Trust and Doubts in Extra-Disciplinary Decisions 221

6.3.6 Awareness of Diversity and Orientation towards Extra-Disciplinary Interactors 223

6.3.7 Velocity and Availability of Information 226

6.4 Summary and Discussion of Findings 227

6.4.1 Expert-Novice Practices 228

6.4.2 Multi-disciplinary Interaction 230

6.4.2.1 Multi-disciplinarity 231

6.4.2.2 Types of Multi-disciplinary Interaction 231

6.4.2.3 Techniques of Multi-disciplinary Interaction 232

6.4.2.4 The Quality of Multi-disciplinary Interaction 234

6.4.2.5 Conclusion 237

6.5 Statistics on the Frequency of Multi-disciplinary Discussion 238

6.5.1 Frequency of Multi-disciplinary Discussion Occur within Project Meetings of S1 238

6.5.2 Frequency of Multi-disciplinary Discussion within S2 246

6.6 Conclusion 248

References 248

Part III: Results, Intervention, and Contributions 251

7 Results and Discussion 253

7.1 How Does Systems Thinking Evolve in Multi-disciplinary Discussion? (RQ1') 254

7.1.1 Multi-disciplinary Quality of Interaction 254

7.1.1.1 Initiation of Multi-disciplinary Discussion 254

7.1.1.2 Two of Four Constituents of Multi-disciplinary Quality of Interaction 255

7.1.1.3 Multi-disciplinary Quality of Interaction and Its Influence on the Evolution of Systems Thinking 256

7.1.2 Discussion of the Influence of Multi-disciplinary Quality of Interaction on the Evolution of Systems Thinking 257

7.1.3 Conclusion 259

7.2 How Does Systems Thinking Evolve in Multi-disciplinary Interaction? (RQ2') 260

7.2.1 Extending the Definition of the Multi-disciplinary Quality of Interaction 260

7.2.2 Change of Reference Repertoire As Indicator of Past Learning 260

7.2.3 Percentage Duration of Multi-disciplinary Discussion in Interaction 261

7.2.4 Two Mechanisms of Knowledge Evolution in Multi-disciplinary Interaction 262

7.2.4.1 Legitimate Peripheral Participation in Other Fields of Practice 263

Contents XV

7.2.4.2 Change of Procedural Knowledge in Expansive

Learning 263

7.2.5 Discussion 264

7.2.5.1 Extended Definition of the Multi-disciplinary Quality of Interaction 264

7.2.5.2 Change of Reference Repertoire 265

7.2.5.3 Quantitative Results on Multi-disciplinary Discussion 265

7.2.5.4 Mechanisms of Knowledge Evolution 265

7.2.6 Conclusion 266

7.3 How and What Is Learned by Whom in Multi-disciplinary Engineering Teams?(RQ3) 268

7.3.1 Knowledge of Different Types Evolves in Different Time Scales of Multi-disciplinary Interaction 268

7.3.2 Modes of Working in Multi-disciplinary Engineering Teams 270

7.3.3 Learning Individuals, Teams, and Organisations 271

7.3.4 Discussion 271

7.3.5 Conclusion 271

7.4 Concluding Remarks on the Answers to the Research Questions 272

7.4.1 Summary 272

7.4.2 Limitations 275

References 276

8 Support: The WAVES Strategy 279

8.1 Development Approach of WAVES 280

8.2 Objectives of WAVES 280

8.3 Existing Support Available for WAVES 283

8.3.1 Knowledge Management 283

8.3.2 Knowledge Management in Space Industry 284

8.3.3 Social Knowledge Management in Space Industry 285

8.3.4 Developmental Work Research 287

8.3.5 Additional Techniques for Knowledge Management 287

8.3.6 Conclusion 289

8.4 Concept and Design of WAVES 289

8.4.1 Form and Structure of WAVES 290

8.4.2 Instruments of WAVES 291

8.4.3 WAVES – Intro 293

8.4.3.1 Introduction into Professional Life 294

8.4.3.2 Introduction into Space Industry 295

8.4.3.3 Introduction into an Organisation 296

8.4.3.4 Intro into a New Team and Intro of a New Team 297

8.4.3.5 Intro into a New Task 298

8.4.4 WAVES – Conti 298

8.4.5 Conclusion 300

8.5 Implementation of WAVES 301

8.5.1 Combined Implementation and Evaluation Approach 301

8.5.2 Team-Wide Implementation with S1 Participants 302

8.5.2.1 Implementation during S1 302

8.5.2.2 Implementation after S1 302

8.5.3 Company L-Wide Implementation and Initial Evaluation of Support 303

8.5.4 Implementation within Company D's Concurrent Design Facility 304

8.5.5 Ongoing Assistance 304

8.5.6 Conclusion 304

8.6 Evaluation of WAVES 305

8.6.1 Initial Evaluation through Discussions 305

8.6.2 Concept of Comprehensive Evaluation 306

8.7 Conclusion 307

References 307

9 Summary of Main Results, Contributions, and Outlook 311

9.1 Main Results 311

9.2 Contributions 313

9.2.1 Contributions to Research 313

9.2.2 Contributions to Engineering Education 313

9.2.3 Contributions to Industry 314

9.3 Outlook 314

Appendix A Overview of Data Collection Methods 315

Appendix B Complementary Information on S1 319

Appendix C Complementary Information on S2 323

Appendix D Basic information on themes 325

List of Acronyms

AAR After Action Review

AdminS Activity system on team level representing members of the

administrative staff of company L of Study 1 (S1) AffectRe Affective Response / Question

AOCS Attitude and Orbit Control System

AODM Activity-Oriented Design Method

AS Activity System

ASN Activity Systems Network

ASN-PS1 Activity Systems Network of Preparatory Study 1

ASN-PS2 Activity Systems Network of Preparatory Study 2

ASN-S1 Activity Systems Network of Study 1

ASN-S2 Activity Systems Network of Study 2

AutQue Authentic Question

CAD Computer Aided Design

CDF Concurrent Design Facility

CEF Concurrent Engineering Facility

CengS Activity system on team level representing engineers of

Study 2 (S2) CengS1 Activity system on team level representing engineers of

Preparatory Study 2 (PS2) CNES Centre Nationale d'Ètudes Spatiales

CustS Activity system on team level representing customers

of Study 1 (S1)

d Day

DC Direct Current

DICA Dynamics in Interaction, Communication, and Activity DLR Deutsches Zentrum für Luft- und Raumfahrt e.V

DoD Department of Defence

DoE Department of Energy

DWRM Developmental Work Research Methodology

ECSS European Cooperation for Space Standardization

ElabExpla Elaborate Explanation

EngS Activity system on team level representing engineers of

Study 1 (S1)

ES Empirical Study

ESA European Space Agency

ESTEC European Space Research and Technology Centre

ExplTalk Exploratory Talk

GPS Global Positioning System

GSFC Goddard Space Flight Center

HCI Human Computer Interface

HF High Frequency

HR Human Resource

IES Intervention and Evaluation Study

INCOSE International Council on Systems Engineering

ISO International Organisation for Standardisation

ISS International Space Station

KISS Keep It Simple, Stupid

KNOTS KNOwledge development in complex Technological

contextS

List of Acronyms XIX

LF Low Frequency

MBSE Model-Based Systems Engineering

NASA National Aeronautics and Space Administration

OMG Object Management Group

PaL Pause and Learn

Preparatory Study 2 (PS2)

SE Systems Engineering

ShrdKnRe Shared Knowledge Response / Question

SMA SubMiniature version A

SoW Statement of Work

SponS Activity system on team level representing members of the

sponsoring organisation of Preparatory Study 1 (PS1), Preparatory Study 2 (PS2), and Study 2 (S2)

STK Satellite Tool Kit

SubcoS Activity system on team level representing subcontractors

of Study 1 (S1) SysML Systems Modelling Language

TutS Activity system on team level representing tutors in

Preparatory Study 1 (PS1)

UHF Ultra High Frequency

UML Unified Modelling Language

UV Ultra Violet

VC Video Conference

VHF Very High Frequency

Part I

Introduction of the Research Project

Chapter 1 introduces the overall research project in presenting the motivation, objectives, research questions, and scope of the research project An overview of the book structure concludes the chapter

Chapter 2 introduces the theoretical background of the research project from the relevant research areas The conclusion of this chapter on systems engineering and learning is the basis for the refinement of the main research question

Chapter 3 introduces the research approach of the research project including research methodology, methods, and analysis framework It starts with the refinement of the research question

H.A Moser, Systems Engineering, Systems Thinking, and Learning,

Understanding Complex Systems,

a system design The necessary broad overview of the involved domains as well as

a certain level of detail requires experience Since novice engineers usually do not have this experience, they have to develop it during their professional life

In small companies, multiple multi-disciplinary and cross-functional teams often involve a single team member covering multiple disciplines A one-man 'team' might even run projects The companies need employees with domain-spanning or multi-disciplinary knowledge in combination with one or two specialisations Such employees are often described as 'T-shaped' people (Elliott & Deasley, 2007) Novice engineers may have a satisfactory depth of knowledge in one discipline, but are likely to lack the knowledge of the other disciplines Hence, when confronted with working on problems involving these other disciplines, this lack must be compensated by more experienced persons These are often senior systems engineers The following situation in a small company provides a fictive example of this dilemma

Joe has graduated his engineering studies with a focus on mechanics and has applied for a job in a small company, building small satellites, even though he only has a basic knowledge about satellites and space He gets the job, in particular because of his enthusiasm for space systems engineering and starts his professional career as structural specialist During his first day, he is introduced to his 20 colleagues who give short descriptions of their work and background His first project manager explains him his tasks in the first project on which he will work with six colleagues: the design and development of

a small satellite Joe's task is the structural and mechanical design of this small satellite, i.e he is responsible for the structure subsystem With the knowledge obtained during his study, he is capable of doing structural analyses, handling a Computer Aided Design (CAD) tool,

and taking decisions about the design of the structural parts resulting

in a mechanically highly sophisticated design However, he lacks the knowledge to know whether the parts designed are capable of functioning with the small electronic components within the satellite,

or with the hot component next to the solar cells He may realise and consider those issues, which he might have picked up in discussions with other team members If not, his design may have to be modified, leading to additional costs and effort In the worst case, Joe's structure will fail during launch and destroy adjacent satellites or even the launcher No human being is free of mistakes, but with a broader view on the entire system and an idea of the impact of his design on its environment and vice versa, the overall system will be more reliable and consistent

Based on discussions in a small space systems integrator company, a preliminary model of a knowledge profile of such a subsystems engineer has been formulated which is shown in Figure 1 The white columns show the depth of knowledge after graduation The grey columns display the envisaged increase in knowledge required to become a systems engineer

Fig 1 Triangular knowledge profile (white: novice engineer, grey: envisaged increase

towards systems engineer)

In order to become a systems engineer, the company expected a newcomer to

go through such an intermediate 'subsystems engineer' stage in order to gradually acquire knowledge in adjacent disciplines in addition to the 'original' discipline The motivating question is how this is done and how it can be improved, that is how can novice engineers be more effective and effectively trained to become systems engineers? If the process of becoming a systems engineer can be made more effective and efficient, a company will fully benefit from a novice engineer earlier, potentially reduce the amount of rework and the risk of failure, and will alleviate senior systems engineers, who support the novices to ensure a system perspective in each project As mentioned earlier, this is of particular importance for small and medium sized companies, but also of interest for large companies, e.g in departments which require a rather broad overview of the system under development

1.2 Objectives and Research Question 5

Terms such as 'broad overview' and 'big picture' are often used for describing a way of thinking and working that is systems thinking (Dym, Agogino, Eris, Frey,

& Leifer, 2005; Elliott & Deasley, 2007) Systems thinking within the context of technical system design and development is related to systems engineering (Davidz, 2006; Lamb, 2009) Therefore, understanding the development (learning)

of systems thinking is essential for understanding and improving the (novice engineer's) process of becoming a systems engineer

1.2 Objectives and Research Question

The research project has the following three objectives:

as a separate industry as it is nowadays Space systems engineering was mainly driven by research and development efforts within the communication industry, e.g Bell, GE, and the automotive industry, e.g GM, Ford, TRW, Chrysler Though military and political issues played a major role in the 'Space Race' during the Cold War, research was the official aim of early space missions such as the first US satellite Explorer 1, which measured the ionosphere of the Earth (Reichl

& Koç, 2006)

In addition to the historical link between systems engineering and space, the space sector itself is regarded as highly challenging for the design and operation of technical systems The space environment with which a space system has to cope

is demanding and multi-faceted Figure 2 gives an overview of the wave or frequency spectrum, which characterises a large portion of the space environment

At the lower end of the spectrum, the electro-magnetic spectrum starts with direct current representing digital and analogue electronics In addition, electrical charging and electro-static discharging represent such infrequent currents (left in Figure 2) With increasing frequency, the spectrum shows radio frequencies such

as very high frequency (VHF) and ultra high frequency (UHF) Thermal radiation between the infrared and ultraviolet band includes the visible spectrum This is an important issue, as thermal radiation is the main source (sun) and sink (deep space) of thermal energy Finally, there is radiation, e.g x-rays, gamma rays, and cosmic rays, against which a spacecraft has to be protected

Fig 2 Wave spectrum of space missions

In addition to the electromagnetic waves, which have to be considered for enabling a space project, a large portion of this spectrum is of interest for commercial and scientific customers, e.g satellite television and radio broadcasting in the radiofrequency band or studying supernovae and black holes with an x-ray telescope

The spectrum of acoustic and mechanic waves is primarily an issue during the short launch period of a spacecraft A broad range of vibrations and shocks represents such a launch Having almost vacuum in space imposes additional mechanical requirements on the space system such as de-pressurisation during launch and off-gassing of materials

The currently impossible chance of retrieving or repairing operating systems in space imposes extra requirements on risk, reliability, availability, and safety While human spaceflight allows repair and maintenance of space systems

10 24 Hz (1 YHz)

10 21 Hz (1 ZHz)

10 12 Hz (1 THz)

10 15 Hz (1 PHz)

10 18 Hz (1 EHz)

10 3 Hz

(1 kHz)

10 6 Hz (1 MHz)

10 9 Hz (1 GHz)

1.4 Structure of the Book 7

(e.g servicing missions of the Hubble Space Telescope), it imposes the highest requirements on safety With the end of the Cold War, the impact of cost factors increased even for scientific and military missions These various influencing factors, which have to be managed, gave rise to the need for an engineering and management methodology more than six decades ago and have influenced the development of this methodology -systems engineering- until today Space industry, which gave rise to the initial issue, is also a good context to study the process of becoming a systems engineer

1.4 Structure of the Book

An outline of the book structure is shown in Figure 3

As second chapter of Part I, Chapter 2 introduces the principles of systems

engineering, systems thinking, and learning This chapter is motivated by the introductory case of Joe to find out if it is just a matter of the individual Joe thrown in at the deep end into an established company structure, or if a more comprehensive effort is required, which concerns individuals, teams and the entire companies In addition, the specifics of systems engineering in the space sector are described in more detail This chapter concludes with a refinement of the main research question into more detailed questions

Chapter 3 describes the research approach to answer the research questions The research methodology, methods, and the analytical framework are discussed and the corresponding research strategy presented

In the first chapter of Part II, Chapter 4, the purpose, design, setup, and data

collection of each of the four empirical studies required to answer the first part of the main research question are described Furthermore, a reflection of the data collection and research ethics is presented

Chapter 5 presents the first analysis of the empirical studies This analysis is based on activity theory After the activity-theoretical analysis of the four studies, the chapter is summarised This conclusion provides the entrance to the next analysis as the findings of the activity-theoretical analysis indicate the direction of in-depth analyses

Chapter 6 presents the second analysis of the empirical studies Themes and key events are selected, motivated by the contradictions identified in the activity-theoretical analysis These themes and key events are analysed on different levels

of analysis and provide a refinement of the contradictions

The first chapter of Part III, Chapter 7, provides the synthesis of the two

previous analyses Answers to the refined research questions of the first part of the main research question are provided and discussed The chapter concludes with a summary of the answers including factors for intervention, which are relevant for answering the second part of the main research question, and the limitations of the empirical studies

Chapter 8 describes the concept, development, implementation, and initial evaluation of the support, which is based on the factors for intervention It provides an additional literature review on existing support from different areas such as knowledge management and expert systems

Finally, Chapter 9 concludes the book in a short summary of the main results The research project's main contributions to research, engineering education, and industry are presented An outlook for future research complements this final chapter

Fig 3 Outline of book structure

References

Davidz, H.L.: Enabling systems thinking to accelerate the development of senior systems engineers (Doctoral dissertation) Massachusetts Institute of Technology, Cambridge (2006)

(5) Activity-theoretical analysis and findings

(4) Description of empirical studies

(7) Results and discussion

(8) Support: the WAVES strategy

(1) Introduction

(9) Summary of main results, contribution and outlook

WHY is theresearch performed?

HOW is theresearchperformed?

WHAT

is analysedand found?

results?

HOW are theresults used?

References 9

Dym, C.L., Agogino, A.M., Eris, Ö., Frey, D.D., Leifer, L.J.: Engineering Design Thinking, Teaching, and Learning Journal of Engineering Education 94(1), 103–120 (2005)

Elliott, C., Deasley, P.: Creating systems that work: Principles of engineering systems for the 21st century Royal Academy of Engineering, London (2007)

Hall, A.D.: A methodology for systems engineering D Van Nostrand Company, Inc., Princeton (1962)

Lamb, C.M.T.: Collaborative Systems Thinking An exploration of the mechanisms enabling systems thinking (Doctoral dissertation) Massachusetts Institute of Technology, Cambridge (2009)

Reichl, E., Koç, A.: Raumfahrt-Wissen, 1st edn Motorbuch, Stuttgart (2006)

H.A Moser, Systems Engineering, Systems Thinking, and Learning,

Understanding Complex Systems,

11

DOI: 10.1007/978-3-319-03895-7_2, © Springer International Publishing Switzerland 2014

Chapter 2

Systems Engineering and Learning

In Chapter 1, the need for improving the evolution of systems thinking has been identified using Joe's case as one of various examples where an individual needs

to act and develop within a professional environment A central concept in the context of this research project is the system This concept directs the structure of this chapter First, systems engineering and related concepts are described (Section 2.1) The definitions of systems engineering involve the application of systems thinking, which is the focus of Section 2.2 Section 2.2 starts with an introduction

to knowledge and thinking in engineering How is systems thinking performed? Who is involved and what are the ingredients? Section 2.3 provides a discussion

on the evolution of knowledge The evolution of knowledge is regarded as learning Learning in the workplace is discussed, in particular in the area of engineering Section 2.4 introduces the characteristics of space industry as the area

in which the empirical studies described in this book have been executed Finally, Section 2.5 concludes the chapter and proposes three detailed research questions based on a refinement of the first part of the main research question introduced in Chapter 1.2

2.1 Systems Engineering

This section starts with a definition of this research project's central concept, the system (Section 2.1.1) Section 2.1.2 introduces basic characteristics of systems engineering Section 2.1.3 presents systems engineering as an activity performed

in multi-disciplinary teams Finally, Section 2.1.4 concludes the section

12 2 Systems Engineering and Learning

neurons, genes, gases, mathematical variables, equations, laws, and processes Attributes are properties of objects For example, in the preceding cases objects listed have (among others) the following attributes: stars – temperature, distance from other stars; switches – speed of operation, state; springs – spring tension, displacement; wires – tensile strength, electrical resistance Relationships tie the system together In fact, the many kinds of relationships (causal, logical, random, etc.) make the notion of 'system' useful" (Hall,

1962, p 60)

Haskins et al (2010, p 5) from the International Council on Systems Engineering (INCOSE) define system as a "combination of interacting elements organised to achieve one more stated purposes." Similarly, Blanchard (2004, p 8) defines system as "a set of interrelated components working together with the common objective of fulfilling some designated need." These definitions underline the viewpoint that a system is defined by its elements and their relationships Haskins

et al (2010) and Blanchard (2004) highlight another system feature in their definitions, namely that it has a purpose: it has to achieve a stated purpose or fulfil

a designated need Not all systems have this second feature: it differentiates human-made systems from natural systems such as the solar system Hence, the two main aspects of human-made systems (Daenzer, 1977; ECSS-E-ST-10C; Rechtin, 2000) are: a) the relationship of a number of elements that constitutes the system and b) the motivation by a purpose or objective that needs to be fulfilled The observer determines which objects are to be parts of the system (Hall, 1962) Haskins et al (2010, p.9) introduce the notion of "system-of-interest" which highlights the selection and definition of a particular system depending on

an observer's interest and purpose "One person's system-of-interest can be viewed

as a system element in another person's of-interest Furthermore, a of-interest can be viewed as being part of the environment of operation for another person's system-of-interest." This hierarchy of subsystem, system (of interest), and hypersystem ('System-of-systems') has been already described by Daenzer (1977) Objects that are determined to be outside of the system are considered as environment, outside of the system boundary; hence, the system-of-interest determines the system boundary

system-There are various definitions of complexity (Young, Farr, & Valerdi, 2010) Within this research project, the complexity of a system is defined by two factors, namely the number of disciplines and organisations involved in the creation and use of the system (Elliott & Deasley, 2007) The lowest level of system complexity is a system on which mainly one engineering discipline in one organisation is working Examples are a PC motherboard, a car gearbox, and an antenna for an aircraft The second level of system complexity concerns a system that involves two or more engineering disciplines or requires two or more organisations to design, build, operate, and maintain it Examples are an electricity

power station, railway signalling, and a car The third level of system complexity

is a system or system-of-systems (Office of the Deputy Under Secretary of Defense Acquisition and Technology, 2008; Lock, 2012) that affects, or is affected by, many disciplines and economic, social, or environmental factors Examples are rail and road networks, health care systems, and telephone networks

If the system-of-interest is an engine, the car is a hypersystem, and the combustion chamber a subsystem

The three levels reflect the aforementioned system hierarchy of subsystem, system, and hypersystem Taking a space system as system-of-interest, the on-board data handling, structures, mechanisms, and propulsion are subsystems The hypersystem would be e.g a worldwide maritime security and tracking system comprised of different space systems and different involved organisations

Systems engineering is an approach to product development applied during the product creation phase of the lifecycle The product creation phase is finished when the use of the product starts The product whose creation is the central objective of the product development activity defines the product lifecycle In line with definitions from the field of engineering design which require a product to

be, or to be related to a physical entity (Tan, 2010), the general definition of product as "something that is marketed or sold as a commodity" (Merriam-Webster, 2003) is preferred This definition includes physical products and services such as maintenance, consultancy, and operations A product can be classified by various categories, e.g according to production volume (one-off to series production) (Gopsill, McAlpine, & Hicks, 2011), according to degree of novelty (Pahl et al., 2007), according to its value (Gopsill et al., 2011), and combinations of the classes

Figure 4 shows an overview of different lifecycle models, which all have a stage-gate structure The lifecycle models of the large organisations US Department of Defense, NASA, and ESA show an acquisition perspective on the lifecycle, i.e a customer perspective Stages can be combined and split ESA often combines phase A and the first half of phase B (B1) to a pre-development phase and then the second half of phase B (B2) together with phase C and D to an implementation phase This combination allows having the pre-development phase in competition and the implementation phase performed by one contractor Another option would be a separated phase A in competition and a single contractor for a combined development, manufacturing, integration and initial utilisation phase (B/C/D/E1) The space mission lifecycle of Wertz and Larson (1999) (shaded at the bottom of Figure 4) is the reference lifecycle model within this book

14 2 Systems Engineering and Learning

Fig 4 Overview of lifecycles (baseline lifecycle is grey highlighted)

Engineering Approaches

Simultaneous engineering (Ehrlenspiel, 2007), concurrent engineering (Eppinger, 1991), and design for X (Meerkamm & Koch, 2005) are approaches to systems engineering While the latter provides guidelines and rules to consider the lifecycle, simultaneous and concurrent engineering aim at partial parallelisation of lifecycle stages (Meerkamm & Koch, 2005; Vajna, 2005; Haskins et al., 2010) A sequence of lifecycle stages without overlap is seen as traditional engineering Figure 5 shows the distinction between traditional (sequential) engineering, and concurrent (simultaneous) engineering A potential threat of the partial parallelisation of lifecycle stages is an increase in rework if co-operation, trust, and sharing, which are required for teamwork, are not sufficient (Terwiesch, Loch,

& de Meyer, 2002; Coates, Duffy, Whitfield, & Hills, 2004)

Concept

definition

phas e

System specification phase

Acquisition preparation phase

Source selection phase

ment phase

Develop-Verification phase

ment phase

Deploy-Operations and maintenance phase

Deactivation phase

Product

definition

phas e

Engineering model phas e

External test phase

Full-scale production phase

Manufacturing, sales, and support phase

Deactivation phase

M ission Definition Review

Preliminary Requirements Review

Preliminary Design Review Utilization

Critical Design Review Disposal

Flight Readiness Review Commissioning Result Review End-Of-Life Review

Generic Lifecycle (ISO 15288:2002)

ESA (ECSS-M-30; ECSS-M-ST-10C)

Phase E

Operations & sustainment

Typical High-Tech Commercial Manufacturer (INCOSE; Haskins et al 2010)

US Department of Defense (DoD) (US-DoDI 5000.02)

Support stage Production

Product development phase

Study period

Study period

Phase B Phase A

Mission analysis / needs

M ission / function

Verification Production

Development stage

Space mission lifecycle (Wertz and Larson, 1999)

Concept exploration Detailed development Production and

deployment Operations and support

Requirements

Internal test phase

Engineering and manufacturing development

Final design &

fabrication

Detailed definition

Phase C Phase C

Definition

Fig 5 Traditional (sequential) engineering and concurrent (simultaneous) engineering

according to Haskins et al (2010, p 293)

ECSS (ECSS-E-TM-E-10-25A, p 10) defines concurrent engineering as

"systematic approach to integrated multi-disciplinary system development that emphasises the response to customer expectations and embodies team values of co-operation, trust, and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel from the beginning of the system lifecycle." This definition emphasises teamwork and multiple perspectives from the whole lifecycle The last part of this definition "involving all perspectives in parallel from the beginning of the system lifecycle" (ECSS-E-TM-E-10-25A, p 10) emphasises to consider issues relevant later in the lifecycle already in the early design phase This is not the parallelisation of lifecycle stages typical for concurrent engineering; it is rather a definition of concurrent design

Design Approaches

Concurrent design is an approach that is applied in distinct lifecycle stages, in particular in early stages (Tatnall, Farrow, Bandecchi, & Francis, 2011) Concurrent design is one category of three approaches to systems design, which are shown in Figure 6 (Tatnall, Farrow, Bandecchi, & Francis, 2011) The other two categories are sequential design and centralised design Sequential design approach

is a subsystem specialist who receives input from another specialist, works on it, and passes his output over the fence to the next specialist (Sage & Rouse, 2009) Centralised design approach is an approach where one central engineer manages a complete system and asks specialists (who do not directly interact with each other),

if necessary, for analyses that are more detailed (Sage & Rouse, 2009) Concurrent design is based on peer interactions between team members who decide collaboratively and inform or bypass the central engineer Concurrent design is often mentioned as a synonym for collaborative design although it includes phases

of parallel design without required collaboration

These approaches are never exclusively applied (Pahl et al., 2007) Although there are efforts to extend the application of concurrent design to later stages, it is mainly applied in concept exploration (Simioni, Arbusti, Roser, & Paccagnini, 2010; Weiß, 2010)

16 2 Systems Engineering and Learning

Fig 6 Three approaches to systems design according to Tatnall et al (2011, p 655)

Large space organisations (such as ESA, NASA, and DLR) have introduced dedicated facilities for concurrent design to foster collaboration of multi-disciplinary teams Even in these facilities, certain steps within the design process are prescribed in a sequential manner, i.e the design in such facilities is not entirely concurrent (Avnet, 2009) The major aim of these facilities is to reduce the time until conceptual designs are generated from a defined need Customer involvement is a central pre-requisite of such facilities

Definition of Systems Engineering

Systems engineering is considered as a general working approach, as an engineering approach (similar to concurrent engineering), as a discipline (ECSS-E-ST-10C; Williams, 2006), or as a process, methodology, and even as a work philosophy (Daenzer, 1977) These different perspectives are partially reflected in definitions of systems engineering Table 1 provides a list of definitions of systems engineering Major characteristics are highlighted in bold font

Concurrent design

Centralized design

Sequential design

Table 1 Overview of systems engineering definitions

"System Engineering Management This activity is concerned with monitoring

and controlling the process of deriving and producing a coherent system design

to achieve stated operational requirements It involves exercising an overview of

the engineering design and development process to ensure that the

inter-related roles of all necessary design disciplines and engineering functional areas

are effectively utilised for satisfying total design requirements."

(Chase, 1974,

p 125)

"Auf eine knappe Formel gebracht, soll Systems Engineering (SE) als eine, auf

bestimmten Denkmodellen und Grundprinzipien beruhende Wegleitung zur

zweckmäßigen und zielgerichteten Gestaltung komplexer System betrachtet

werden."

(Daenzer, 1977,

p 4)

"[ ] we define systems engineering from all three perspectives here:

Structure: Systems engineering is a management technology to assist clients

through the formulation, analysis, and interpretation of the impacts of proposed

policies, controls, or complete systems upon the need perspectives, institutional

perspectives, and value perspectives of stakeholders to the issue under

consideration

Function: Systems engineering is an appropriate combination of the

mathematical theory of systems and the behavioural theory, in a useful setting

appropriate for the resolution of real-world problems, which are often of

large-scale and scope

Purpose: The purpose of systems engineering is to develop policies for

management direction, control, and regulation of activities relative to

forecasting, planning, development, production, and operations of total systems

to maintain overall integrity and integration as related to performance and

reliability."

(Sage, 1980,

pp 693–694)

"Systems engineering is an interdisciplinary engineering management

process that evolves and verifies an integrated, life-cycle balanced set of system

solutions that satisfy customer needs."

(US DoD Systems Management College, 2001,

p 3)

"Systems engineering is an iterative process of top-down synthesis,

development, and operation of a real-world system that satisfies, in a near

optimal manner, the full range of requirements for the system."

(Eisner, 2002,

p 5)

"System engineering is the function that systematically considers all aspects of a

project in making design choices and is a continuous, iterative process with a

built-in feedback mechanism that is used throughout a project's life cycle to

arrive at the best system architecture and design possible The success of

complex space vehicles and space vehicle projects is highly dependent upon the

system engineering process being properly exercised at all levels of design and

management."

3173_A, p 19)

(MSFC-HDBK-System Engineering "is a discipline that concentrates on the design and

application of the whole (system) as distinct from the parts It involves looking

at a problem in its entirety, taking into account all the facets and all the

variables and relating the social to the technical aspects."

(Williams, 2006,

pp 4.1.6)

18 2 Systems Engineering and Learning

Table 1 (continued)

"Systems engineering is a methodical, disciplined approach for the design,

realisation, technical management, operations, and retirement of a system [ ]

It's a way of looking at the "big picture" when making technical decisions It's

a way of achieving stakeholder functional, physical, and operational

performance requirements in the intended use environment over the planned life

of the systems In other words, systems engineering is a logical way of thinking."

(Kapurch et al.,

2007, p 3)

"Systems engineering is the art and science of developing an operable system

capable of meeting requirements within often opposed constraints [ ] Systems

engineering is a holistic, integrative discipline, wherein the contributions of

structural engineers, electrical engineers, human factors engineers, and many

more disciplines are evaluated and balanced, one against another, to produce a

coherent whole that is not dominated by the perspective of a single discipline."

(Griffin, 2007,

pp 6–7)

"The essence of systems engineering is in: selecting the right parts, bringing

them together, orchestrating them to interact in the right way and so creating

requisite emergent properties, capabilities and behaviours of the whole Essential

systems engineering is executed such that the parts and the whole are operating

dynamically in their environment, to which they are open and adaptive, while

interacting with other systems in that environment."

(Hitchins, 2007,

p 120)

"System Engineering is an interdisciplinary approach governing the total

technical effort required to transform a requirement into a system solution."

"The system engineering process is intrinsically iterative across the whole life

of a project, in particular in the initial phases [ ] of the development of a

complex system (e.g a spacecraft), procured through a multilayered set of

suppliers."

10C, pp 16,20)

(ECSS-E-ST-"Systems engineering is a socio-technical practice characterised by the creation

and execution of an iterative process in which the individual knowledge,

thoughts, and viewpoints of a diverse set of professionals combine and

converge towards a design solution that delivers value to all stakeholders,

including the customers, the users, and the designers."

(Avnet, 2009,

p 200)

"Systems Engineering (SE) is an interdisciplinary approach and means to

enable the realisation of successful systems It focuses on defining customer

needs and required functionality early in the development cycle, documenting

requirements, and then proceeding with design synthesis and system validation

while considering the complete problem: operations, cost and schedule,

performance, training and support, test, manufacturing, and disposal SE

considers both the business and the technical needs of all customers with the

goal of providing a quality product that meets the user needs."

(Haskins et al.,

2010, p 7)

From this list, five systems engineering characteristics have been derived These characteristics, illustrated in Figure 7, define systems engineering as follows Systems engineering is: the management and engineering of a system, which is more than the sum of elements, applied throughout the lifecycle, involving multiple disciplines, in a continuous iterative process The five characteristics are described in the following

Fig 7 Basic five characteristics of systems engineering

Management and Engineering

Daenzer (1977) characterised systems engineering as a problem solving process comprised of system design and project management This duality of management and engineering is reflected in definitions of systems engineering which include management (see Chase (1974), Sage (1980), Haskins et al. (2010), and Kapurch

et al (2007)) Furthermore, combined notions, such as systems engineering management (see Shenhar and Sauser (2009), Sharon, de Weck, and Dori (2011)) and engineering management (MIL-STD-499 (USAF)), underline this duality Chase (1974, pp 125–126) describes management as being comprised of

"planning, organising, selecting, directing, motivating, controlling, supporting, and evaluating the performance of people acting both as individuals and in concert

as a team." This definition details the definition "conducting or supervising something" (Merriam-Webster, 2003) Engineering as "professional art of applying science to the optimum conversion of the resources of nature to the uses

of humankind" (Merriam-Webster, 2003) is also a broad definition The higher the complexity of the system, which allows this "optimum conversion" the more important becomes the "planning, organising, selecting, directing, […] of people" (Chase, 1974, pp 125–126)

Systems Engineering

management and engineering

more than the sum of elements

throughout the lifecycle multiple

20 2 Systems Engineering and Learning

More Than the Sum of Elements

This characteristic is included in key terms such as overview (Chase, 1974), total systems (Sage, 1980), full range (Eisner, 2002), complete problem (Haskins et al., 2010), problem in its entirety (Williams, 2006), and coherent whole (Griffin, 2007) It highlights a perspective beyond elements, where elements can be parts, components, subsystems, even systems depending on the system-of-interest The total of connected elements is more than their sum

Throughout the Lifecycle

The consideration of the whole lifecycle as well as the application of systems engineering in all stages of the product creation (until the start of product use by customer) is highlighted Examples are overview of development process (Chase, 1974), development cycle (Haskins et al., 2010), design, realisation, technical management, operations, and retirement (Kapurch et al., 2007), throughout a project's life cycle (MSFC-HDBK-3173_A), life cycle balanced (US DoD Systems Management College, 2001), and across the whole life of a project (ECSS-E-ST-10C)

Multiple Disciplines: Key terms such as interrelated (Chase, 1974), perspectives

(Sage, 1980), diverse set of professionals (Avnet, 2009), and interdisciplinary (Haskins et al., 2010; ECSS-E-ST-10C; US DoD Systems Management

different disciplines, domains, professions, etc Several distinctions between the notions discipline, field, domain, speciality, branch, and area exist Scholes and Vaughan (2002) distinguish between multi-disciplinary, multi-professional, and inter-professional working They highlight that the prefix multi does not necessitate interaction as does the prefix inter Furthermore, they stress the flexible interpretation of multi-disciplinary as this includes participants who might share the same professional background but practice within different specialities Adams, Mann, Forin, and Jordan (2009, p 343) encompass "a collection of practices associated with thinking and working across disciplinary boundaries; multi-disciplinary, interdisciplinary, and transdisciplinary" with the term cross-disciplinary For this research project, the term multi-disciplinary is used without further distinction The term inter-disciplinary is used as a synonym for multi-disciplinary The term intra-disciplinary describes an entity within one single discipline, i.e discipline internal The term extra-disciplinary describes and entity outside of a single discipline, i.e discipline external

Multi-disciplinary entities such as efforts (Chase, 1974), tasks (Lamb, 2009), projects (Andreasen & Hein, 2000), and teams (Scholes & Vaughan, 2002) can be regarded as incorporating a heterogeneous set of perspectives (Elliott & Deasley, 2007), viewpoints, assumptions (Haskins et al., 2010, p 292), rules governing activity (Merriam-Webster, 2003), and paradigmatic cores (Bucciarelli, 2003) Adams et al (2009) list different types of research on multi-disciplinary entities

and criticise the lack of empirical substance behind lots of these theoretical concepts They intend to reduce this lack in performing a phenomenographic study Such a study provides an insight into what interviewees think about concepts such as multi-disciplinarity

Continuous Iterative Process: The fifth characteristic of systems engineering

describes it as a continuous process comprising several iterations (Avnet, 2009; ECSS-E-ST-10C) Such a successive refinement in a convergent process is often modelled as a spiral (Kapurch et al., 2007) In the broadest sense, this process is regarded as an iterative transformation "of needs and requirements into solutions" (ECSS-E-ST-10C)

2.1.3 Systems Engineering within Multi-disciplinary Teams

Chase (1974) recommends multi-disciplinary teams as these provide the opportunity for the team members to acquire a systems overview and an understanding of their own specialist role for the system design He called these teams system-oriented task groups, which share the common objective of designing a system (Chase, 1974) Multiple perspectives complement each other

in such multi-disciplinary teams (Andreasen & Hein, 2000)

A team is defined as "a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable" (Katzenbach & Smith, 2003, p 45) Katzenbach and Smith (2003) regard less than twelve team members as small number, but they do not regard size as mandatory requirement, rather as a suggestion Larger teams are expected to separate more likely into sub teams (Katzenbach & Smith, 2003)

Complementary Skills: Two types of heterogeneity can define the way skills in a

team shall be complementary The first type is a heterogeneity of expertise which Katzenbach and Smith (2003) call technical or functional skills The required heterogeneity depends on the activity of the team, e.g a rowing team requires a more homogeneous distribution of skills than a football team (Hakkarainen, Palonen, Paavola, & Lehtinen, 2004) Systems engineering activities require a heterogeneous set of expertise The second type is heterogeneity of experience, i.e team members have different levels of professional experience (Stempfle & Badke-Schaub, 2002) The composition of multi-disciplinary engineering teams is driven by the (technical) system to be developed

Meaningful Purpose: Commitment to a meaningful purpose and commitment to

performance goals are linked The meaningful purpose describes the overall purpose or broad directions of the team The performance goals describe