103,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Clear and concise guide to MBPLE, with industrial case studies
Written in a to-the-point style, Model-Based Product Line Engineering (MBPLE) is the only theoretical and practical foundational book on MBPLE that brings together the topics of model-based systems engineering (MBSE) and feature-based product line engineering (PLE). It examines how PLE can benefit from a model-based and model-centric approach and, in turn, how MBSE combined with holistic PLE can boost model reuse and improve the MBSE business case.
The book combines both management and engineering aspects to deliver comprehensive coverage of the subject. The book covers real-life challenges and implementations of MBPLE, discussing adoption obstacles faced by engineering organizations and how to overcome them to ensure a successful MBPLE deployment.
Dozens of SysML v2 views, SysML v1 diagrams, SysML v2 code snippets and illustrations are included throughout to elucidate key concepts. Additional supplementary learning materials are available on a companion website.
Written by a team of expert authors and contributors with significant experience in the field of applied MBPLE, Model-Based Product Line Engineering (MBPLE) discusses sample topics including:
- Motivation for MBPLE, covering document-based to model-based engineering, project-oriented to product-line-oriented engineering, and digital continuity and system lifecycle management
- Foundations of MBPLE, covering basic definitions, the history of MBPLE, recent MBPLE works and standards, and the impact of MBPLE on engineering processes
- Implementation of MBPLE using the next generation modeling language SysML v2
- Adoption of MBPLE, covering investment interests, company processes, change management and digital transformation, and methods, guidelines, coaching
Model-Based Product Line Engineering (MBPLE) delivers vision, benefits, and strategic guidance for managers, executives, and business leaders while serving as a practical guide for system engineers who are new to the MBPLE discipline or already familiar with it.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 571
Veröffentlichungsjahr: 2025
Ähnliche
Table of Contents
Cover
Table of Contents
Title Page
Copyright
MBPLE book Dedications
Foreword
Preface
About the companion Website
Chapter 1: Introduction
Acknowledgments
References
Part I: Motivation
Chapter 2: Complexity and Variability
2.1 Introduction
2.2 Complexity
2.3 Variability
2.4 The Trade-off Between Complexity and Variability
References
Chapter 3: Reuse Strategies
3.1 Introduction
3.2 Different Reuse Approaches
3.3 Quick Benefits Versus Risk Analysis of Reuse Patterns
References
Chapter 4: From Document-based to Model-based Engineering
4.1 Introduction
4.2 Document-based Engineering
4.3 Model-based Engineering
References
Chapter 5: From Single Product to Product-line-based Delivery Approach
5.1 Introduction
5.2 Project-oriented Approaches
5.3 Shifting Toward a More Efficient Paradigm
5.4 Product Platform, Product Family, and Their Derived Products
5.5 Product-line-based Delivery
References
Chapter 6: Digital Continuity and System Life Cycle Management
6.1 Introduction
6.2 The “Eternal Return” of Complexity
6.3 System Life Cycle and Multiple Domains
6.4 Digital Continuity and Its Challenges
6.5 Digital Continuity for System Variability
References
Part II: Foundations of MBPLE
Chapter 7: Past, Present, and Future of MBPLE
7.1 Introduction
7.2 Everything Started with Software Engineering
7.3 The First Generation of Software Product Line Development: The “Dolly” Era
7.4 The Second Generation of Software Product Line Development
7.5 From Software Product Lines to System Product Lines
7.6 The Liaison Between PLE and MBSE
References
Chapter 8: Shifting to a Model-based Approach
8.1 Introduction
8.2 Systems Engineering
8.3 Model-based Systems Engineering
8.4 From PLE to MBPLE
References
Chapter 9: MBPLE Concepts and Definitions
9.1 Introduction
9.2 Variability Model
9.3 Feature Model
9.4 Shared Assets Supersets
9.5 Product Models
9.6 Member Products
References
Chapter 10: MBPLE Modeling Languages
10.1 Introduction
10.2 Models and Modeling Languages
10.3 Variability Modeling Languages
10.4 Feature Modeling Languages
10.5 Shared Asset Modeling Languages
10.6 SysML v2
10.7 Model Interoperability
References
Chapter 11: The MBPLE Foundation in the Standards
11.1 Introduction
11.2 PLE Standards
11.3 Systems Engineering Foundation, Model-based and Interoperability Standards
References
Part III: Implementation of MBPLE
Chapter 12: The MBPLE Paradigm
12.1 Introduction
12.2 Step 1: Define Feature Models
12.3 Step 2: Define Feature Configurations
12.4 Step 3: Define Shared Assets
12.5 Step 4: Derive Product Models
12.6 Extending the Four Steps for a Real-world Execution of MBPLE
References
Chapter 13: Define Feature Models
13.1 Introduction
13.2 Basic Concepts
13.3 Feature-Oriented Domain Analysis
13.4 Orthogonal Variability Model
13.5 Feature Modeling Tools
13.6 Drone Product Line Example
References
Chapter 14: Define Feature Configurations
14.1 Introduction
14.2 Basic Concepts
14.3 Feature Modeling Tools
References
Chapter 15: Define Shared Assets
15.1 Introduction
15.2 Basic Principle
15.3 Modeling of Shared Assets with SysML v2
15.4 Clean and Direct Approach with SysML v1
15.5 Non-SysML Shared Assets
References
Chapter 16: Define Product Models
16.1 Introduction
16.2 Basic Principles
16.3 Modeling of Product Models with SysML v2
16.4 Modeling of Product Models with SysML v1
References
Chapter 17: The Four Dimensions of Variability
17.1 Introduction
17.2 From Co-Development to Co-Variability
17.3 Variability Along the Development Life Cycle
17.4 Cascading Variability Along Layers of Abstraction
17.5 Breaking Down the Systems and Their Variability
17.6 The Four Dimensions and the MBPLE Implementation
References
Chapter 18: Digital End-to-end Continuity with MBPLE
18.1 Introduction
18.2 The Digital Repositories of a Product Line
18.3 Transforming Shared Assets Consistently Through the MBSE Model
18.4 Evolving the Product Line
18.5 The Journey of a New Product Line Feature
18.6 Manual Workarounds? Only If Temporary
References
Chapter 19: Configuration and Model Management for MBPLE
19.1 Introduction
19.2 General CM
19.3 CM of Product Lines
19.4 CM for MBPLE
19.5 Maintaining the Digital Continuity
19.6 CM for Models
19.7 Model Organization and Management
19.8 ISO 26581: A New CM Standard for PLE
References
Chapter 20: MBPLE and Artificial Intelligence
20.1 Introduction
20.2 AI Foundation
20.3 Communication with an LLM
20.4 AI4MBPLE
20.5 The “Super” Assistant: Combining Domain Expert and MBPLE Methodology
20.6 AI4MBPLE Opportunities and Threats: Hasta la Vista, Baby!
References
Part IV: Adoption of MBPLE
Chapter 21: A Business Case for MBPLE
21.1 Introduction
21.2 The Problem and Opportunity Space
21.3 MBPLE Value Proposition
References
Chapter 22: The MBPLE Adoption Quadrant
22.1 Introduction
22.2 From Document-based Systems Engineering to Model-based Systems Engineering
22.3 From Document-based Systems Engineering to System Family Engineering (Aka PLE)
22.4 From Model-based Systems Engineering to Model-based Product Line Engineering
22.5 From System Family Engineering (Aka PLE) to Model-based Product Line Engineering
22.6 The MBPLEAQ Applied in the Industrial Cases
References
Chapter 23: The MBPLE Adoption Framework
23.1 Introduction
23.2 MBPLE Process
23.3 MBPLE Methods
23.4 MBPLE Information Model
23.5 MBPLE Tool Chain
23.6 MBPLE Organization
References
Chapter 24: MBPLE Process
24.1 Introduction
24.2 Define the Product Line Scoping
24.3 Define Feature Models
24.4 Define Feature Configurations
24.5 Define Shared Assets
24.6 Define Product Models
24.7 Verify the Product Line
24.8 Customize the Product Models (If Needed)
24.9 Verify the Member Products
24.10 Produce the Member Product
24.11 Validate the Member Products
24.12 Evolve and Decommission the Product Line
24.13 MBPLE Mapping with the Non-Technical Processes
References
Chapter 25: MBPLE Methods
25.1 Introduction
25.2 Methodology, Process, Method, and Tool
25.3 Independent and Specific Methods
25.4 Method Development
References
Chapter 26: MBPLE Information Model
26.1 Introduction
26.2 How to Read an Information Model with SysML
26.3 Product Line
26.4 Variability Model
26.5 Feature Model
26.6 Feature Constraint
26.7 Feature Group
26.8 Feature Configuration
26.9 Shared Assets
26.10 Product Model and Member Product
References
Chapter 27: MBPLE Tool Chain
27.1 Introduction
27.2 PLE Solution
27.3 MBSE Solution
27.4 ALM Solution
27.5 PLM Solution
27.6 Configuration Management Solution
27.7 The Future of the MBPLE Tool Chain
References
Chapter 28: MBPLE Organization
28.1 Introduction
28.2 Guidelines for Setting Up and Operating an MBPLE Enterprise
28.3 Examples of Organizational Patterns
28.4 So, What About Agile?
28.5 MBPLE Adoption Team Setup
28.6 Product Lines-of-product Lines
References
Chapter 29: PLE Pioneers’ Perspectives: Beyond Tools and Tool Vendors
29.1 Introduction
29.2 Presentation of the PLE Pioneers
29.3 The Early Encounter with the PLE Discipline
29.4 The Primary Benefit of PLE
29.5 Differences in PLE Application Between Software, Systems, and Across Industries
29.6 PLE Standards and Their Development
29.7 Synergies and Challenges of the Liaison PLE and MBSE
29.8 The Protagonist Role of the Feature Model in PLE
29.9 Common Misconceptions About PLE and Usage of a PLE Tool
29.10 SysML v2 as Potential “Game-Changer” for MBPLE
29.11 The Key Absent in the PLE Arena: a Variability Modeling Standard
29.12 The Future of MBPLE with the Rise of AI and Large End-to-End Proprietary Solutions
29.13 Conclusion
References
Part V: MBPLE Industrial Cases
Chapter 30: Airbus: MBPLE in Commercial Aviation
30.1 Introduction
30.2 MBPLE at Airbus
30.3 Challenges for MBPLE Implementation
30.4 Variability Cascading
30.5 Conclusion: Ready for Take-Off?
References
Chapter 31: MBDA: Building an End-to-end Model-based Framework for Product Lines
31.1 Introduction
31.2 MBDA Motivation for MBPLE’s Adoption
31.3 The MBSE Framework as MBDA Foundation for MBPLE
31.4 The E2EPLE Methodology
31.5 Not Only MBSE Assets: The ECAD Variability Management Within MBPLE
31.6 E2EPLE Tool Chain
31.7 A Real-Life Example for the E2EPLE
31.8 The Journey of E2EPLE at MBDA Continues
Annex 1: MBPLE Terms at MBDA.
References
Chapter 32: Thales: A Long Road to MBPLE – from Initial Conception to Completion
32.1 Introduction
32.2 Transitioning to PLE: Dealing with Different Reuse Approaches
32.3 The Formalization of the Variability Management Approach
32.4 The Advent of a PLE-driven Organization
32.5 No PLE Exists Without a Solid Governance
32.6 Toward MBPLE: The Improvement of the PLE Approach Continues
32.7 (MB)PLE Benefits and Recommendations Based on SRA’s Experience
References
Chapter 33: Raytheon: System Family Engineering – Innovating at the Speed of Relevance
33.1 Introduction
33.2 Introduction to the Digital Trinity
33.3 A SFE’s Example:The Hypothetical Intelligence Gathering System
33.4 Challenges and Solutions
33.5 Conclusions
References
Chapter 34: Belimo: Innovation in Comfort, Energy Efficiency, and Safety Solutions with Product Lines
34.1 Introduction
34.2 Transitioning to MBPLE: Target and Definitions
34.3 A Glance of the MBPLE Approach: Asset’s Definition Across Different Perspectives
34.4 Variability Management at the Core of MBPLE
34.5 Organizational Shift and Cultural Changes
34.6 Case Study and Practical Insights
References
Chapter 35: MBPLE in Action: What We Can Learn from the Five Industrial Cases?
35.1 Introduction
35.2 Why Do These Five Cases Matter?
35.3 The MBPLE Adoption Quadrant: Understanding Paths and Trajectories Toward MBPLE
35.4 Commonalities and Divergences in the MBPLE Adoption
References
Chapter 36: Conclusion
References
Annex A: MBPLE Glossary
Index
End User License Agreement
List of Illustrations
Chapter 2
Figure 2.1 Representation of the increasing complexity in history.
Figure 2.2 Representation of the technology-driven complexity driver.
Figure 2.3 Representation of the scope-driven complexity driver.
Chapter 3
Figure 3.1 Different reuse patterns.
Chapter 4
Figure 4.1 Documents along the engineering V models.
Figure 4.2 Gap of missed improvements.
Figure 4.3 Models along the engineering V’s.
Chapter 5
Figure 5.1 Differences between single-product development and product-line deve...
Chapter 6
Figure 6.1 System domains, life cycle phases, and variants.
Figure 6.2 Example of digital continuity across multiple variants.
Chapter 7
Figure 7.1 A type of methodologist you would have encountered during the “Metho...
Figure 7.2 Example of a bad result of clone-and-own practices.
Chapter 9
Figure 9.1 MBPLE cornerstones: variability, shared assets, products models, and...
Figure 9.2 Domain and application assets.
Figure 9.3 Definition of feature model.
Figure 9.4 Example feature tree.
Figure 9.5 Life cycle stages.
Figure 9.6 Proxy features.
Figure 9.7 Definition of shared assets supersets.
Figure 9.8 Relationship of feature model and shared assets superset elements.
Chapter 10
Figure 10.1 Cross-model relationship between variation and feature.
Figure 10.2 Proxy element for cross-relationships.
Chapter 11
Figure 11.1 Standards associated with MBPLE.
Figure 11.2 Featured-based PLE.
Chapter 12
Figure 12.1 MBPLE four-step approach.
Chapter 13
Figure 13.1 MBPLE four-step approach “define feature models.”
Figure 13.2 Product “tiny PLE wall.”
Figure 13.3 Products “tiny PLE wall” and “tiny PLESandy wall.”
Figure 13.4 L-brick variations
Figure 13.5 Feature tree “tiny PLE wall.”
Figure 13.6 One feature model for all RFLP layers.
Figure 13.7 Multilevel feature models.
Figure 13.8 Member product sets.
Figure 13.9 Example of OVM.
Figure 13.10 FeatureIDE feature tree.
Figure 13.11 Feature model connections.
Figure 13.12 Drone product line feature tree.
Figure 13.13 Cross-feature model feature constraint.
Chapter 14
Figure 14.1 MBPLE four-step approach “define feature configurations.”
Figure 14.2 Feature configurations map.
Figure 14.3 Feature tree with feature configurations.
Figure 14.4 PLE house feature tree.
Figure 14.5 FeatureIDE configuration matrix.
Chapter 15
Figure 15.1 MBPLE four-step approach “define shared assets.”
Figure 15.2 Direct method shared assets “tiny PLE walls.”
Figure 15.3 Clean method shared assets superset “tiny PLE walls.”
Figure 15.4 Multilevel and multilayer shared assets.
Figure 15.5 Variant membership relationship.
Figure 15.6 Shared assets for drone batteries.
Figure 15.7 Variation of the drone battery.
Figure 15.8 Definition of the drone product line.
Figure 15.9 Drone body and flight control software variations.
Figure 15.10 Feature flight patterns.
Figure 15.11 Flight pattern actions.
Figure 15.12 Invalid SysML model scenario usage of the direct approach.
Figure 15.13 Feature, requirement, and architecture element.
Figure 15.14 Variations and variants with SysML v1.
Figure 15.15 Drone core system architecture breakdown with variations.
Figure 15.16 Drone battery variants.
Figure 15.17 Drone system architecture with direct approach.
Figure 15.18 Drone internal block diagram with direct approach.
Chapter 16
Figure 16.1 MBPLE four-step approach “define product models.”
Figure 16.2 Handover artifacts.
Figure 16.3 Tiny PLE wall product model.
Figure 16.4 Product model.
Figure 16.5 Product model change.
Figure 16.6 Member product “forestFireObservationDrone” defined by the product l...
Figure 16.7 Resolving the variability.
Figure 16.8 Forest fire observation drone variant configuration (product model)....
Chapter 17
Figure 17.1 Simplified example of the four-variability dimensions.
Chapter 18
Figure 18.1 Overview of the feature model and shared assets links across digital...
Figure 18.2 Example of the two types of links, the satisfy link and the feature-...
Figure 18.3 Simplified evolution of a drone product line along the development t...
Figure 18.4 Example of digital continuity between a feature and other shared ass...
Figure 18.5 Example of impact of new feature to the existing digital continuity ...
Figure 18.6 Example of data exchange between the SysML v2 model repository and a...
Chapter 19
Figure 19.1 CM basic concepts.
Figure 19.2 CM extended concepts for the product line.
Figure 19.3 CM extended concepts for the member product.
Figure 19.4 Configuration items of a model.
Figure 19.5 Organization SysML shared assets.
Chapter 20
Figure 20.1 AI terminology.
Figure 20.2 Import of the legacy specification pdf in the IBM watsonx applicatio...
Figure 20.3 Feature model output in the IBM watsonx application.
Figure 20.4 Feature model imported in PTC pure::variants.
Figure 20.5 Revised feature model output in the IBM watsonx application.
Figure 20.6 Feature model updated in PTC pure::variants.
Figure 20.7 Requirements impacted by the new features in the IBM watsonx applica...
Chapter 21
Figure 21.1 Correcting errors in a clone-and-own approach (without MBPLE).
Figure 21.2 Cumulated development costs in a clone-and-own approach (without MBP...
Figure 21.3 Comparison of cumulated development costs with and without MBPLE (th...
Figure 21.4 Effort avoidance to perform a task, thanks to MBPLE.
Figure 21.5 Volume of IVVQ activities and qualification credit as a function of ...
Figure 21.6 Cumulated development costs with and without MBPLE considering a gra...
Figure 21.7 Nonrecurring cost comparison between three different approaches (clon...
Figure 21.8 Comparison of development costs and on-time delivery obtained with S...
Chapter 22
Figure 22.1 MBPLE adoption quadrant (MBPLEAQ).
Chapter 23
Figure 23.1 Overview of the MBPLE adoption framework and the three adoption phas...
Figure 23.2 Simplified basic MBPLE tool chain.
Figure 23.3 More comprehensive MBPLE tool chain.
Chapter 25
Figure 25.1 Concept model methodology, process, method, and tool.
Figure 25.2 Independent and specific methods.
Figure 25.3 Continuous methods improvement.
Figure 25.4 MBPLE OSMs/TSMs context.
Figure 25.5 MBPLE use case “show impact of a feature change.”
Chapter 26
Figure 26.1 Example information model.
Figure 26.2 Information model: product line.
Figure 26.3 Information model: variability model.
Figure 26.4 Information model: feature model.
Figure 26.5 Information model: subfeatures.
Figure 26.6 Information model: feature constraint.
Figure 26.7 Information model: alternative feature group.
Figure 26.8 Information model: feature configuration.
Figure 26.9 Information model: shared assets superset.
Figure 26.10 Information model: shared assets/features relationships.
Figure 26.11 Information model: member product.
Chapter 27
Figure 27.1 MBPLE tool chain categories.
Figure 27.2 Example of feature model in PTC pure::variants.
Figure 27.3 Example of feature model in Gears BigLever Software.
Figure 27.4 SysFM example with SysML.
Chapter 28
Figure 28.1 A different look at an MBPLE-oriented enterprise.
Figure 28.2 Organizational pattern at product line level.
Figure 28.3 Organizational pattern at the subsystem level.
Figure 28.4 Interdependencies among MBPLE team, personnel and environment.
Chapter 30
Figure 30.1 Software complexity in Airbus’ commercial aircraft.
Figure 30.2 Airbus R-MOFLT architecture framework.
Figure 30.3 Global airline net profit and EBIT margin.
Figure 30.4 Simplified trade flow using PLE techniques.
Figure 30.5 Airbus MBPLE tool chain.
Figure 30.6 Four dimensions of variability.
Figure 30.7 Variability cascading overview.
Figure 30.8 MBSE model views.
Figure 30.9 e-Taxi simplified feature model.
Figure 30.10 Function “Produce AC Movement on LG from electric power.”
Figure 30.11 Extract of the functional architecture highlighting the studied func...
Figure 30.12 Extract of an activity highlighting the behavior of the studied func...
Figure 30.13 Port left hanging after model transformation which removed a functio...
Figure 30.14 Variation points must be created in a consistent manner. Automation ...
Chapter 31
Figure 31.1 MBDA evolution/revolution.
Figure 31.2 MBDA MBSE framework.
Figure 31.3 MBDA MBSE framework hierarchy.
Figure 31.4 Product line hierarchy.
Figure 31.5 Product line model.
Figure 31.6 MBDA feature catalog.
Figure 31.7 “Atomic,” “starting” and “propagated” variation points.
Figure 31.8 Propagation logic “starting” variation point.
Figure 31.9 Propagation logic “starting” variation point.
Figure 31.10 Propagation logic “atomic” variation point.
Figure 31.11 Preview of PLE factory configured MBSE framework model.
Figure 31.12 Preview of PLE factory configured ECAD imported structural architect...
Chapter 32
Figure 32.1 Partial scope of the variability analysis.
Figure 32.2 Thales SRA level orchestrated development environment.
Figure 32.3 Product domain engineering and project application engineering.
Chapter 33
Figure 33.1 The digital trinity.
Figure 33.2 MOSA OSA key system quality attributes.
Figure 33.3 Hypothetical intelligence gathering network (H-IGN).
Figure 33.4 FO-SCV analysis:Part of digital engineering.
Figure 33.5 H-IGN sensor platform control modes feature model.
Figure 33.6 Subset of H-IGN COMMS capabilities.
Figure 33.7 PLE factory’s product rule base results.
Figure 33.8 Example feature profile.
Figure 33.9 Simple Java SW module.
Figure 33.10 Multivariable tangible and parameterized intangible ROI calculation ...
Chapter 34
Figure 34.1 Increased product’s complexity at Belimo.
Figure 34.2 Portfolio mindset at Belimo.
Figure 34.3 Market and technical perspective.
Figure 34.4 Domain and application assets across market and technical perspectiv...
Figure 34.5 Conceptual model of Belimo’s variability management.
Figure 34.6 Variability management during the concept phase of a development pro...
Figure 34.7 Variability management during the industrialization phase of a devel...
Figure 34.8 Overview of features and feature options belonging to a product fami...
Figure 34.9 Views on feature model in iQUAVIS (simplified content).
Figure 34.10 Feature model DSM in iQUAVIS (simplified content).
Figure 34.11 Feature-based product descriptions in iQUAVIS (simplified and limite...
Figure 34.12 System element-based product descriptions in iQUAVIS (simplified and...
Chapter 35
Figure 35.1 Complexity and variability degrees of aircraft, missile, radar, and ...
Figure 35.2 Path of “complexity-triggered adoption” of MBPLE at Airbus and MBDA....
Figure 35.3 Path of “variability-triggered adoption” of MBPLE at Thales.
Figure 35.4 Path of “differentiated adoption” of MBPLE at Belimo.
List of Tables
Chapter 24
Matrix 24.1 Mapping of MBPLE extended steps with the systems life cycle processe...
Chapter 31
Table 31.1 Cross-reference feature type versus architecture layer.
Chapter 35
Table 35.1 Comparison of key MBPLE terms used in this book and in the five indu...
Guide
Cover
Table of Contents
Title Page
Copyright
Dedication
Preface
Foreword
About the companion Website
Begin Reading
Annex A: MBPLE Glossary
Index
End User License Agreement
Pages
iii
iv
v
x
xi
xii
xiv
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
Model-Based Product Line Engineering (MBPLE)
The Feature-Based Path to Product Lines Success
Marco Forlingieri
Tim Weilkiens
Hugo Guillermo Chalé-Gongora
Copyright 2025 by John Wiley & Sons Inc. All rights reserved, including rights for text and data mining and training of artificial intelligence technologies or similar technologies.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
The manufacturer’s authorized representative according to the EU General Product Safety Regulation is Wiley-VCH GmbH, Boschstr. 12, 69469 Weinheim, Germany, e-mail: [email protected].
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data: 2025902944
Print ISBN: 9781394204663
ePDF ISBN: 9781394204670
ePub ISBN: 9781394204687
oBook ISBN: 9781394204694
Cover Design: Wiley
Cover Image: Maria Izabel Thimote
MBPLE book Dedications
To Prof. Dr. Danilo Beuche and Marco Ferrogalini, whose mentorship and inspiration shaped my career and introduced me to the world of Product Line Engineering.
To my grandparents, Angelo, Annamaria, and Maria, who remind me daily of the strength and wisdom of my Italian roots.
And to my wife, Maria, and my dog, Kyoto, my companions on every adventure around the world. Your support and love make every journey worthwhile.
Marco Forlingieri
To all the fantastic engineers who are committed to making the world a better place and to my family who make the world a great place for me every day.
Tim Weilkiens
To my parents and siblings, whose example, unconditional love, and support have led me to where I am and made me who I am.
To Geneviève and Anne-Nohemi, for the joy of seeing your smile every morning, and for setting me right whenever I’m wrong. Thanks for making each return home into the best moment of my day. You make life exciting.
Hugo Guillermo Chalé-Gongora
Foreword
Once upon a time, a unique trio got together: an Italian tool-vendor, a French-Mexican executive, and German subject matter expert (it sounds like the start of a joke, but this is serious stuff, folks!). We come from different backgrounds, possess diverse skills, and pursue distinct goals, but we share one undeniable passion called Model-Based Product Line Engineering (MBPLE).
Several years ago, while working at Renault, Guillermo, the executive, had an intuition: “What if we bring Model Based Systems Engineering (MBSE) and Product Line Engineering (PLE) together?” It was the origin of MBPLE, a concept Guillermo later applied at Alstom and Thales. Marco, now an executive tool vendor, read the work of Guillermo and decided to make PLE and MBSE his main expertise, applying it at Bombardier Transportation and later at Airbus. Tim, the subject matter expert, wrote VAMOS (Weilkiens 2016), a book about modeling the variability with SysML, which captured the attention of the other two, being the first and only source about the topic. The world of systems engineering is small and thanks to International Council on Systems Engineering (INCOSE) we got to know each other at the point that we, the trio, decided to put in writing all the knowledge and expertise gathered about the topic. We wanted to keep the concepts as simple as possible to reach managers, engineers, and students. This is how the idea of this book came to be.
In fact, only a few books exist about product lines, much less about their development, and nothing, so far, about MBPLE. This is because product lines are akin to mythological creatures – mysterious and elusive. Like the legendary Nessie in Loch Ness, the enigmatic UFO sightings or a politician keeping promises once elected, product lines are talked about by some who claim to have experienced them, but fail to prove their existence! And yet, paradoxically, you encounter them in your everyday life. They manifest when you purchase a car, wield a smartphone, drill the wall, dry your hands, board a plane, or even when you turn on the air conditioning.
What is the secret behind product lines? How are they developed? Can someone unveil the product line that, like Aristotle’s “first motor,” generates countless derived products? Such a revelation proves elusive! Just like a witness to an UFO sighting, the Loch Ness monster or a trustworthy politician, many speak of it, pretending to know the truth, but most, again, are unable to provide concrete evidence.
You might be skeptical, assuming that we, the authors of this book, are merely another group of individuals pretending to have witnessed something incredible without being able to prove it. But what about the five industrial cases on the concrete application of MBPLE from Airbus, Thales, MBDA, Raytheon and Belimo at the end of the book? Or the many references provided throughout this text?
We do not ask you to believe us, we extend an invitation, a summons to join us on this extraordinary expedition, where the mysteries of product lines and their secret recipe await your discovery. Together, let us unravel the enigma, peer behind the veil, and embark on a journey that will forever transform our perception of the way we carry out your business thanks to a deeper understanding of reuse, assets sharing and variability.
Welcome, fellow traveler, to this captivating odyssey and, paraphrasing Ulysses’ words in Dante’s Divine Comedy (Alighieri 1995), keep in mind that “you were not made to live as brutes, but to follow virtue and knowledge of MBPLE.”
Marco Forlingieri
Tim Weilkiens
Hugo Guillermo Chalé-Gongora
References
Alighieri, D. (1995). The Divine Comedy. Originally published in 1320. New York: Knopf, distributed by Random House.
Weilkiens, T. (2016). Variant modeling with SysML. MBSE4U.
Preface
In the field of systems engineering, Product Line Engineering (PLE) has emerged as a transformative approach for managing the complexity of modern product families. First introduced in the 1990s, PLE laid the groundwork for systematically developing families of software and hardware. Over the years, it has evolved to meet the needs of increasingly complex industries, including automotive, aerospace, defense, and beyond.
In today’s era of digital transformation, PLE is essential for maintaining competitiveness. The complexity of product development cycles now demands an integrated, model-based approach that enables organizations to achieve digital continuity and efficient lifecycle management. For decades, International Council on Systems Engineering has played a central role in the evolution of systems engineering, embracing emerging disciplines like PLE and adapting to model-based advancements.
Recognizing the importance of PLE in advancing systems engineering, the International Council on Systems Engineering (INCOSE) established the PLE Working Group in 2012. This group plays a critical role in standardizing PLE practices and fostering global collaboration across sectors. Aligned with INCOSE’s mission to promote systems engineering, the PLE Working Group has contributed significantly to the evolution of PLE and, more recently, Model-Based Product Line Engineering (MBPLE).
The authors of this book are recognized international experts, bringing extensive experience in both the theory and practical application of MBPLE across industries. Their deep involvement in INCOSE and contributions to major organizations and international standards make them uniquely qualified to present this comprehensive guide.
The publication of ISO/IEC 26550:2015 marked a significant milestone for PLE, providing a foundational standard for product line engineering and management. This was further strengthened by ISO/IEC 26580:2021, which introduced feature-based methods for managing PLE across industries. INCOSE’s PLE Working Group has played a vital role in formalizing these standards, ensuring a cohesive framework for PLE across sectors and fostering collaboration within the systems engineering community.
The combination of Model-Based Systems Engineering (MBSE) with PLE – now known as MBPLE – has become a cornerstone of innovation. By leveraging models, MBPLE enables engineers and organizations to manage product family variations and configurations with unprecedented precision and flexibility. This integrated, model-based approach has made it possible to address the complexities of today’s product lifecycles, delivering improved digital continuity and competitive advantages.
While the evolution of MBPLE continues to advance, it is accompanied by diverse interpretations and emerging trends, creating a need for clarity and guidance. This book fills a critical gap by offering a comprehensive guide to MBPLE, combining strategic insights with foundational concepts and practical implementation techniques, particularly in Systems Modeling Language (SysML). Through real-world case studies and insights from PLE pioneers, it explores the transformative power of MBPLE, including the potential impact of Artificial Intelligence and its associated opportunities and risks. This book serves as an essential resource for anyone aiming to learn and leverage MBPLE in today’s increasingly complex and competitive product development environments.
Ralf Hartmann, INCOSE President
About the companion Website
This book is accompanied by a companion website.
www.wiley.com/go/forlingieri/mbple1e
This website includes:
Author Images
Website content and structure
Chapter 1Introduction
Model-based product line engineering (MBPLE) is a broad topic involving many stakeholders. For most companies, MBPLE’s transformational nature concerns almost all engineering activities and operations. Leaders need to understand MBPLE to plan and implement it strategically, as well as to understand and frame its application. But MBPLE principles, concepts, and methods must also be understood by a wider population, including the following:
Process owners who create and adapt MBPLE methods and tools to meet organization-specific requirements.
Engineers who use MBPLE methods directly to create feature models and shared assets supersets.
Engineers and product owners who develop parts of the product line.
Students who learn systems engineering, product line engineering (PLE), and model-based approaches.
This book discusses MBPLE as a central topic, covering all its facets, including the enabling factors for a successful implementation of MBPLE in an organization. For readers who are new to the topic or who would like to acquire a broad understanding of MBPLE, reading the book following the order of the sections might be the best approach. However, readers who are interested in a particular topic or who have previous knowledge of PLE can browse freely through the different sections of the book.
Part I discusses the motivation of MBPLE, which is important for all MBPLE stakeholders. Like all engineering approaches, MBPLE is only a means to an end. Therefore, it is important and helpful to have a good understanding of the purpose of MBPLE.
Part II describes the fundamental concepts of MBPLE, independently of concrete implementations of modeling languages and tools. Like Part I, Part II is also an important reading for all MBPLE stakeholders. The chapters in Part II look at the historical development of model-based approaches and PLE, as well as relevant standards such as ISO/IEC 26550 (ISO/IEC 2015) and ISO/IEC 26580 (ISO/IEC 2021), which provide the framework wherein the MBPLE concepts are presented.
Part III explains the technical implementation of MBPLE and is of particular interest to those who use MBPLE directly. One focus is on the models with SysML, whereby both the widely used SysML v1 and the new SysML v2 are used.
Part IV explains the adoption of MBPLE in organizations, a significant topic for leadership roles. The chapters consider both the investment and return on investment of introducing MBPLE, the processes, the methods, the organization, the information model, and the tool chains. This part is rounded off by a chapter with an interview of two PLE pioneers, Dr. Danilo Beuche from PTC and Dr. Charles Krueger from Big Lever Software.
Part V intends to show that the book presents MBPLE not only in theory but also in real-life practice. Five chapters focus on industrial cases about adopting MBPLE from five different organizations.
In the appendix, a glossary lists the most important MBPLE terms for reference.
Acknowledgments
It takes a lot of people to write this book, many of whom are directly acknowledged in this book. Thanks to Ralf Hartmann, president of INCOSE, for writing the preface and his continued commitment to the systems engineering community. Many people have agreed to report on their MBPLE approaches within their companies and have written industrial cases in Part V. These contributors include Davi Henrique de Sousa Pinto from Airbus, Dieter Wagner from MBDA, Agnès Guiblin from Thales, James Teaff from Raytheon, and the Belimo’s team, consisting of Manuel Pijorr, Alba Pennisi, Markus Hüppi, Daniel Messmer, Mariana Reyes Perez, Mitko Tanevski and Simon Hoffman. Thank you all for your work and the insights you provided in this book. The two PLE pioneers, Dr. Danilo Beuche and Dr. Charles Krueger, took the time to share their views on the world of PLE. Thank you very much for your valuable time and contribution; without your contribution, this book would have not been complete. Many ideas were discussed and matured in the INCOSE PLE Working Group (INCOSE PLE 2024) context. Marco Ferrogalini, who contributed his wealth of experience as Vice President and Head of Modeling and Simulations at Airbus, was involved in the book’s initial ideas and structure.
References
INCOSE PLE (2024). INCOSE PLE Working Group. Webpage viewed on 15 July.
https://www.incose.org/communities/working-groups-initiatives/product-lines
.
ISO/IEC (2015).
ISO/IEC 26550:2015
Software and systems engineering – reference model for product line engineering and management. Geneva ISO/IEC.
ISO/IEC (2021). ISO/IEC 26580:2021 Software and systems engineering – methods and tools for the feature-based approach to software and systems product line engineering. Geneva ISO/IEC.
https://www.iso.org/standard/43139.html
.
Part IMotivation
The first part of the book focuses almost solely on the purpose of Model-Based Product Line Engineering (MBPLE). This emphasis is intentional, based on the authors’ experiences that company members often lose sight of the overall purpose of their initiatives. Frequently, they mistake tools and methods (such as digital transformation, modeling, agile practices, or digital twins, to name just a few) for end goals. Avoiding this confusion is crucial for MBPLE due to its transdisciplinary nature, the required investments, and the need to implement it across the whole company.
Chapter 2 begins by drawing a picture of the context in which today’s products are developed. The chapter briefly explores complexity and variability as well as their implications on the methods needed to develop and deliver products that are adapted to the needs of different customers. This is the object of Chapter 3, which presents different reuse patterns along with their advantages and disadvantages. Special attention is given to the dangers of implementing unplanned reuse strategies and to the prerequisites that should be in place to ensure a successful implementation of a product line approach.
Chapter 4 explains the difference between document-based engineering and model-based engineering. The growth in the adoption of model-based engineering as well as the perspectives of its evolution are also explored. The chapter presents the benefits and challenges associated with model-based engineering. Chapter 5 is a logical complement to Chapter 4 as it proposes a similar approach to explain the differences between the delivery of single products and the delivery of products in a product-line-based approach. This chapter explains the advantages of transitioning to a programmatic approach to manage the products of a product line as a single entity, as opposed to managing a plethora of separate development projects.
Chapter 6 closes Part I with an analysis of digital threads and digital continuity as enablers to allow managing data during all the stages of the product line life cycle and across the different products of a product line in a consistent way. The chapter also underlines the importance of the openness of IT solutions and the need to connect these in integrated networks to support MBPLE in an effective manner.
Chapter 2Complexity and Variability
2.1 Introduction
As the discipline of systems engineering evolves, it must confront the growing complexity inherent in its expansive scope. This chapter first explores in Section 2.2 the dual drivers of complexity identified by the International Council on Systems Engineering (INCOSE) in its Vision 2035 (INCOSE 2022): technology-driven and scope-driven complexity. Technology-driven complexity is fueled by fast technological advancements, while scope-driven complexity emerges from the increasing size and interdependencies within the development scope. We explore deeper each driver, emphasizing their distinctive impacts on the field.
Section 2.3 addresses the concept of variability driven by customization in product development. Customization, while enhancing individuality and flexibility, often results in a diverse range of product variants.
The combination of complexity and variability are discussed in Section 2.4, two trends that are deeply interrelated and form the challenges in modern product and systems engineering, emerging as a key focus of the chapter. Through a few examples, it illustrates the difficulties of balancing high variability demands with the need to manage complexity effectively.
Ultimately, this chapter contextualizes these concepts within the broader framework of systems engineering, emphasizing the criticality of innovative development paradigms to address the combined challenges of increasing complexity and variability demands in the development of complex systems.
2.2 Complexity
In systems engineering, complexity has always been a key aspect to address. The field itself developed to better handle the increasing scale, interconnections, and complexity in systems development. Professor de Weck (Conservation of Complexity 2023) discussed the rising complexity in today’s products and systems, noting that it is much higher than in the past, as highlighted in Figure 2.1. This complexity is intended to lead to enhanced performance and, possibly, increased resilience. It is a common understanding among systems engineers that complexity is escalating each year due to rapidly changing contexts, the growing interdependencies of systems, and more challenging projects taken on by organizations and governments. He also pointed out how monumental achievements like the lunar landing, the International Space Station, 20-hour transoceanic flights, or capturing images of the earliest proto-galaxies post-Big Bang are made possible by the coordinated effort of numerous components, including hardware, software, and human collaboration. However, he also emphasized that many aerospace programs are facing rising costs and challenges in management, partly due to a limited grasp of how system performance, complexity, and the effort needed for design, construction, and validation are interrelated. This can be also explained by what he theorizes as the “First Law of System Science for Conservation of Complexity.” In simpler terms, it suggests that the complexity of a system is directly related to expected improvement in its performance, adjusted by the amount of work and resources put into its development and construction (Conservation of Complexity 2023).
Figure 2.1 Representation of the increasing complexity in history.
Source: Adapted from INCOSE 2022.
In systems engineering, the typical process that aims at managing complexity involves breaking down a “problem” into smaller, more manageable parts, designing solutions for these individual parts, and then reassembling them to form the complete system. This approach is effective for “complicated” systems with fixed interactions among parts, even if they contain many interrelated components and may exhibit unpredictable behavior (INCOSE 2016).
However, this method encounters difficulties when new technologies are integrated into traditional systems and when the scope of these systems expands to ambitious developments. In complex systems, the emergent properties crucial to the system’s functionality cannot be fully understood by examining the individual components separately. These properties only become apparent when considering the system as a whole. According to INCOSE’s Vision 2035 (INCOSE 2022), the complexity in engineering is continuously escalating, primarily due to two key factors: technology-driven complexity and scope-driven complexity. Other factors contribute to an increase of complexity in systems engineering, such as the complexity of the business context or of the organization in which the systems are developed. However, the focus here is on the complexity intrinsic to the system under development. Let’s examine both drivers in detail.
2.2.1 Technology-driven Complexity
Technology-driven complexity arises from the rapid pace of technological advancements and their integration into systems and products. This type of complexity is often characterized by the incorporation of cutting-edge technologies, which, while enhancing capabilities, also add challenges to the system’s design, operation, and maintenance, as exemplified in Figure 2.2.
Figure 2.2 Representation of the technology-driven complexity driver.
Source: Adapted from INCOSE 2022.
For instance, the implementation of software-defined vehicles in the automotive industry describes the complexity of technology-driven vehicles well. A software-defined vehicle is any vehicle that manages its operations, adds functionality, and enables new features primarily or entirely through software. Tesla cars are the most famous example. Software-defined vehicles are the next evolution of the automotive industry. Their architecture usually divides the vehicle’s functions into different server zones, such as infotainment, safety systems, and vehicle control. Each zone integrates advanced technologies like sensor fusion, connectivity modules, and real-time data processing. The challenge lies in harmonizing these technologies to work together, ensuring vehicle performance and safety in diverse driving conditions. This complexity is compounded by the need to constantly update and maintain each server zone over the air to meet evolving technological standards and consumer demands (Burkacky et al. 2023).
2.2.2 Scope-driven Complexity
Scope-driven complexity emerges from the expansion in the scale and interconnectedness of systems. It reflects the transition from developing standalone products to creating systems part of more extensive, often interconnected networks, as illustrated in Figure 2.3.
Figure 2.3 Representation of the scope-driven complexity driver.
Source: Adapted from INCOSE 2022.
Extending the example of software-defined vehicles, scope-driven complexity becomes apparent when these vehicles connect to more extensive networks. Features like over-the-air software updates and vehicle-to-everything communication add layers of complexity. The challenge is ensuring the vehicle’s different server zones work well with these external connections, maintaining reliable and secure performance in an interconnected setting. This shows how expanding the scope of vehicle systems naturally makes them more complex.
In summary, understanding complexity in systems engineering involves recognizing the multifaceted challenges posed by technological advancements and expanding project scopes. As we continue to push the boundaries of what is possible, mastery of complexity becomes a critical skill in the engineer’s toolkit.
2.3 Variability
In product development, customization refers to the process of tailoring products or systems to meet the specific requirements of a customer or market segment. This often involves modifying or configuring the design, features, functionalities, or even the aesthetics of a product to align with distinct preferences, needs, or operational environments. From a portfolio perspective, customized products or systems exhibit variability, as their characteristics may differ among the members of the product portfolio. Unlike mass production, which focuses on uniformity and scale, customization emphasizes individuality and flexibility, often resulting in diverse product variants. Customization is the primary driver of variability within a product portfolio.
With increasing demand for customization, companies face the double challenge of providing market – or customer-specific variety while mastering the consequences of high variability in engineering and production. Especially in an increasingly saturated market, new products must find ways to differentiate themselves from the competition, like distinctively meeting specific customer needs to enhance customer’s satisfaction (Simpson et al. 2005).
However, as observed by Meyer and Lehnerd (1997), focusing on individual customer preferences often leads to overlooking commonality and standardization across product lines. This can result in an overwhelming diversification of products and parts. While offering a comprehensive product variety has merits, it can also incur significant costs and complexity within a company.
Have you ever noticed, while traveling on different flights, even within the exact airline or across various airlines, which the airplane model might be the same, yet many aspects inside differ significantly? For instance, consider the variability in-cabin configuration and layout, the number and style of toilets, infotainment systems, or even the types of movies available during the flight. These differences result from airlines’ deliberate customization and high differentiation to enhance their brand identity and customer service offerings. However, this level of variability often becomes a “nightmare” for airplane manufacturers and their suppliers. They frequently face the challenging task of reworking complex systems to accommodate these customizations, sometimes questioning the necessity of altering even minor details, like the exact millimetric position of power and water outlets within the galley of a commercial aircraft!
If not adequately managed, variability can significantly impact the design and development of systems in several ways:
Increased complexity: high variability introduces complexity into the design process, requiring engineers to consider a broader range of variables and potential configurations.
Design flexibility: More flexible design approaches are needed to accommodate changes and variations without extensive redesigns or cost overruns.
Production and supply chain adjustments: Variables impact production processes and supply chains, which need to be adaptable to produce a variety of customized products efficiently.
Increased costs: while customization can lead to higher customer satisfaction and market differentiation, variability often leads to increased production costs and complexity in inventory management.
In summary, customization in product development reflects the dynamic and varied needs of customers and market trends. However, this leads to increased variability, which, if not properly managed, can hinder project success and overall organizational performance.
2.4 The Trade-off Between Complexity and Variability
The increasing complexity in engineering and the escalating demand for customization leading to higher variability are not isolated trends; instead, they are profoundly interconnected and often feed into each other, creating additional challenges in modern systems engineering.
Have you ever considered that a European, South America, or Southeast Asia metro system might be based on the identical product family? This idea was pursued by Bombardier Transportation in 2014 with their “Entry Segment Metro” concept (Forlingieri 2014). They aimed to create a metro design that could be adapted across different regions. However, the project encountered significant challenges and ultimately did not materialize.
One of the primary reasons for this was that metro systems and light rail vehicles often symbolize a city’s identity, necessitating unique and strongly differentiated designs. Additionally, the need to comply with diverse local norms and regulations significantly increased the complexity and the potential number of variants required. However, other rolling stock products, such as high-speed trains, may require heavier customization, going beyond style and aesthetics into the specific train architecture (Chalé Góngora et al. 2014).
This example showcases the trade-off between the desire for high customization and the goal of limiting complexity, which arises from the variability of the product variants. The effort to customize a metro system or a light rail vehicle across various geographical and cultural contexts shows how challenging it can be to manage both these aspects effectively.
This applies in particular to a category known as complex products and systems (CoPS). They consist of prime products that demonstrate a high degree of customization and complexity (Hobday 1998). These are high-cost, engineering-intensive items, encompassing a broad range of tailored components, specialized knowledge, and involvement from various organizations. The complexity of CoPS arises not just from their technical difficulties but also from the extensive customization required to meet the unique demands of each project (Forlingieri 2014). Naval, Aerospace, and Civil Engineering are just some of the most representative industries where this category of systems is produced.
The CoPS category is just one of the possible areas where the combination of variability and complexity closely interact.
To conclude, addressing diverse business context factors, specific customer needs, and increasing complexity, particularly within a highly regulated environment, requires new engineering practices and methods. These approaches help to balance variability and complexity in today’s systems. You will find some answers later in this book!
References
Burkacky, O., Steiner, F., Deichmann, J. et al. (2023). Getting ready for next-generation E/E architecture with zonal compute.
https://www.mckinsey.com/industries/semiconductors/our-insights/getting-ready-for-next-generation-ee-architecture-with-zonal-compute
(accessed June 2024).
Chalé Góngora, H.G., Ferrogalini, M. and Moreau, C. (2014). How to boost PLE by using MBSE – a case study of a rolling stock product line. In:
Proceedings of the 5th International Conference on Complex Systems Design and Management (CSDM)
Paris, France: Springer.
Conservation of Complexity: The First Law of System Science (2023). MIT AeroAstro.
https://aeroastro.mit.edu/news-impact/conservation-of-complexity-the-first-law-of-system-science/
(accessed January 2024).
Forlingieri, M. (2014).
Platform Planning and Design for Rail Rolling Stock: An Exploratory Study of Platform Development within Bombardier Transportation
. Enschede: University of Twente.
Hobday, M. (1998). Product complexity, innovation and industrial organisation.
Research Policy
26 (6): 689–710. doi: 10.1016/S0048-7333(97)00044–9.
International Council on Systems Engineering (INCOSE) (2016). A complexity primer for systems engineers.
International Council on Systems Engineering (INCOSE) (2022). Systems engineering vision 2035.
https://sevisionweb.incose.org
(accessed July 2024).
Meyer, M.H. and Lehnerd, A.P. (1997).
The Power of Product Platforms: Building Value and Cost Leadership
. New York, NY: Free Press.
Simpson, T.W., Siddique, Z. and Jiao, J. (eds.) (2005).
Product Platform and Product Family Design: Methods and Applications
. New York: Springer. 1–15.
Chapter 3Reuse Strategies
3.1 Introduction
In today’s highly competitive markets, most organizations usually try to leverage previously developed assets for their reuse into a new product. This understanding of reuse, shared by most common folk, is one of the more widespread in the engineering of systems: using again what one has done before to produce a solution that is similar or close to a previous one. The purpose of reuse, however, is often much less formalized or even understood: produce the same thing or something similar, only faster and better. In other words, a reuse strategy should be set to produce clearly stated outcomes, such as improving product characteristics, like quality and performance, or program objectives, like cost-effectiveness, time to delivery, or risk mitigation.
Indeed, in most industrial organizations, practically no system is created from scratch. Engineers are most likely to reuse knowledge from a previous project or product in the form of documents, procedures, diagrams, or models. The problem is that this knowledge, albeit optimal for local usage, is very often partial and sometimes even inadequate when used in a different context. In siloed organizations, this usually results in incompatibilities of engineering artifacts, inconsistent technical data, and duplication of information in different repositories, making the implementation of the principles exposed in Chapters 5 and 6 extremely challenging. In a nutshell, these practices make reuse very problematic at a cross-company level and hamper the creation of well-structured, corporate-wide product lines. Whilst Section 3.2 introduces some of the industrial reuse approaches, Section 3.3 provides a brief analysis of the benefits and risks of those reuse patterns.
3.2 Different Reuse Approaches
As an engineering practice, reuse is well-documented in software and manufacturing, where examples of successful reuse approaches are well known, such as configurable software modules, standard software architectures, flexible manufacturing systems, or automobile platform sharing (Holweg 2008). Reuse is also associated with concepts like modular architectures, system families, and standardization of parts.
The origins of product line engineering (PLE), as the main reuse practice of this book, are often traced back to McIlroy’s work on “Mass Produced Software Components” (McIlroy 1968) (see Chapter 10 for a more detailed history of PLE).
However, the formalization of PLE and other reuse practices for their application to the engineering of large-scale systems is still scarce and relatively new (International Council on Systems Engineering [INCOSE] 2019) despite historical, de facto, or casual reuse in industry, like the reutilization of existing specification documents, technical drawings, or test procedures, and the existence of some reports on successful industrial applications (Chalé Góngora et al. 2014; Flores et al. 2013; Gregg et al. 2016). Figure 3.1 represents a spectrum of different reuse patterns explained in the sections below.
Figure 3.1 Different reuse patterns.
Source: Adapted from Czarnecki, K.
3.2.1 Clone and Own
Usually associated with the search for short-term benefits, clone-and-own (or branch-and-merge) approaches are the easiest to implement since engineering teams are usually independent and able to manage engineering assets as they like. There is practically no sharing among the different branches, and separate efforts to maintain each individual branch are required. This approach might be a suitable scheme for businesses in which single product instances are delivered over very large periods of time. It might also be appropriate for companies that want to reuse existing products to enter a new market or propose a groundbreaking application in an opportunistic way. The success of this approach relies on mastering the technical debt and on top-class configuration management processes.
3.2.2 Component Library and Framework
Component library and framework approaches produce more substantial benefits than the clone-and-own approach. The component library approach is based on the definition of standard components. Besides the need to master the interactions and interdependencies amongst the components, the biggest challenge of the component library approach is to ensure that the emerging properties of the composed product are those expected by the customers. In the framework approach, efforts would instead be dedicated to the definition of standard interfaces in such a way that any component that complies with the standard can potentially be used to “compose” a particular product. The Autosar (Automotive Open System Architecture) framework (Autosar 2024) is a well-known example of a standardized software framework supporting a composable approach for electric and electronic system architectures in the automotive industry.
In practice, these two approaches are carried out simultaneously to foster compsability and ease of integration. They are adapted to products evolving in markets that require the delivery of a rather stable set of functionalities over time. These functionalities can be allocated to dedicated components that would evolve at a slow pace, while isolating those components that support fast-evolving functions or technologies. The main difficulties of the component library and framework approaches are that the evolution of standard components must be thoroughly planned and controlled and that managing the definition of standard interfaces can be a complicated task in large-scale systems.
