126,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Model-based Systems Architecting is a key tool for designing complex industrial systems. It is dedicated to the working systems architects, engineers and modelers, in order to help them master the complex integrated systems that they are dealing with in their day-to-day professional lives. It presents the CESAMES Systems Architecting Method (CESAM), a systems architecting and modeling framework which has been developed since 2003 in close interaction with many leading industrial companies, providing rigorous and unambiguous semantics for all classical systems architecture concepts. This approach is practically robust and easy-to-use: during the last decade, it was deployed in more than 2,000 real system development projects within the industry, and distributed to around 10,000 engineers around the globe.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 390
Veröffentlichungsjahr: 2022
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Preface
CESAMES and the CESAM Community
CESAMES Systems Architecting Method (CESAM)
How to read this book?
The proposed agenda
Acknowledgments
Introduction: Systems
I.1. Systems from a pragmatic perspective
I.2. The need for a specific approach to deal with systems
I.3. Examples of systems
I.4. Systems are everywhere
1 Introduction to CESAM
1.1. CESAM: a mathematically sound system modeling framework
1.2. CESAM: a framework focused on complex integrated systems
1.3. CESAM: a collaboration-oriented architecting framework
1.4. CESAM: a business-oriented framework
2 Why Architecting Systems?
2.1. Product and project systems
2.2. The complexity threshold
2.3. Addressing systems architecting becomes key
2.4. The value of systems architecting
2.5. The key role of systems architects
2.6. How to analyze a systems architect profile?
3 CESAM Framework
3.1. Elements of systemics
3.2. The three architectural visions
3.3. CESAM systems architecture pyramid
3.4. More systems architecture dimensions
3.5. CESAM systems architecture matrix
4 Identifying Stakeholders: Environment Architecture
4.1. Why identify stakeholders?
4.2. The key deliverables of environment architecture
5 Understanding Interactions with Stakeholders: Operational Architecture
5.1. Why understand interactions with stakeholders?
5.2. The key deliverables of operational architecture
6 Defining What the System Shall Do: Functional Architecture
6.1. Why understand what the system does?
6.2. The key deliverables of functional architecture
7 Deciding How the System Shall be Formed: Constructional Architecture
7.1. Understanding how the system is formed?
7.2. The key deliverables of constructional architecture
8 Taking into Account Failures: Dysfunctional Analysis
8.1. Systems do not always behave as they should
8.2. The key deliverables of dysfunctional analysis
9 Choosing the Best Architecture: Trade-off Techniques
9.1. Systems architecting does not usually lead to a unique solution
9.2. Trade-off techniques
Conclusion
C.1. The first journey in systems architecting
C.2. The other key systems architecting topics
C.3. Systems architecting in practice
C.4. How to develop a systems architecting leadership?
C.5. Towards a new systems architecture modeling language
Appendices
Appendix 1: System Temporal Logic
Appendix 2: Classical Engineering Issues
A2.1. Product problem 1 – the product system model does not capture reality
A2.2. Product problem 2 – the product system has undesirable emergent properties
A2.3. Project problem 1 – the project system has integration issues
A2.4 Project problem 2 – the project system diverts the product mission
Appendix 3: Example of System Model Managed with CESAM
A3.1. The system of interest
A3.2. Environment architecture
A3.3. Operational architecture
A3.4. Functional architecture
A3.5. Constructional architecture
Appendix 4: Implementing CESAM through a SysML Modeling Tool
A4.1. Generic structure of a SysML system model based on the CESAM framework
A4.2. Example of organization of a SysML system model based on the CESAM framework
Appendix 5: Some Good Practices in Systems Modeling
References
Index
Wiley End User License Agreement
List of Tables
Introduction: Systems
Table I.1. Categories of engineered systems. For a color version of this table, ...
Chapter 2
Table 2.1. Typical examples of product and project issues
Chapter 3
Table 3.1. Examples of states for an electronic toothbrush
Table 3.2. Examples of static elements for an electronic toothbrush
Table 3.3. Examples of flows for an electronic toothbrush
Table 3.4. Standard statement patterns for needs and functional and construction...
Table 3.5. Examples of expected properties per architectural vision
Table 3.6. The CESAM system architecture matrix
Table 3.7. Example of a CESAM system architecture matrix for the electronic toot...
Chapter 4
Table 4.1. Pattern of the mission statement of a system
Chapter 5
Table 5.1. Graphic representations of temporal relationships between operational...
Chapter 8
Table 8.1. Examples of safety standards in various industries
Table 8.2. Example of a partial list of external hazards for an electronic tooth...
Table 8.3. Example of a partial list of functional hazards for an electronic too...
Table 8.4. Example of a partial list of constructional hazards for an electronic...
Conclusion
Table C.1. Systems architecting topics covered within this book
Table C.2. Other systems architecting topics
Table C.3. Generic structure of a system architecture file
Appendix 2
Table A2.1. Examples of typical product and project issues addressed by systems ...
Appendix 4
Table A4.1. SysML representations of the CESAM architectural views
Appendix 5
Table A5.1. Some good practices in systems modeling1
List of Illustrations
Introduction
Figure I.1. Mont Blanc from Chamonix (1,200 meters above sea level). For a color...
Figure I.2. Mont Blanc from the Black Lake (2,000 meters over the sea). For a co...
Figure I.3. The socio-technical dimension of systems. For a color version of thi...
Figure I.4. A complex component system: a computer system. For a color version o...
Figure I.5. Constructional interaction diagram of a computer system. For a color...
Figure I.6. An integrated product system: an extended vehicle. For a color versi...
Figure I.7. Functional interaction diagram of an extended vehicle. For a color v...
Figure I.8. A system of systems: the railway system. For a color version of this...
Figure I.9. Functional interaction diagram of the railway system. For a color ve...
Figure I.10. An ecosystem: the world as a system. For a color version of this fi...
Figure I.11. Illustration of a standard process for constructing a COVID-19 glob...
Chapter 1
Figure 1.1. The two abstracting/experimenting sides of a system modeling process...
Figure 1.2. Standard representation of a formal system
Figure 1.3. Structure of a standard complete system specification. For a color v...
Figure 1.4. Formal integration of formal systems
Figure 1.5. Example of an integrated system: the used electronic toothbrush. For...
Figure 1.6. Using models to converge on the same vision of a system. For a color...
Figure 1.7. Initial and final models as managed during a collaborative systems a...
Figure 1.8. Tentative structure of the CESAM frameworks. For a color version of ...
Figure 1.9. Example of a standard functional/constructional architecture for an ...
Chapter 2
Figure 2.1. Product versus project systems. For a color version of this figure, ...
Figure 2.2. Project effort and integration complexity relationship. For a color ...
Figure 2.3. The integrative and collaborative dimension of systems architecting....
Figure 2.4. Relative position of systems engineering and systems architecting wi...
Figure 2.5. Systems architecting as a risk management practice27. For a color ve...
Figure 2.6. NASA statistics supporting the importance of the definition phase28
Figure 2.7. The key role of the systems architect. For a color version of this f...
Figure 2.8. Ideal profile of an ideal systems architect. For a color version of ...
Chapter 3
Figure 3.1. Examples of interfaces for an electronic toothbrush. For a color ver...
Figure 3.2. Environment of an electronic toothbrush. For a color version of this...
Figure 3.3. Illustration of the three architectural visions on an electronic too...
Figure 3.4. Operational vision – mission breakdown structure (MBS) of an electro...
Figure 3.5. Functional vision – functional breakdown structure (FBS) of an elect...
Figure 3.6. Constructional vision – product breakdown structure (PBS) of an elec...
Figure 3.7. Relationships between the three architectural visions. For a color v...
Figure 3.8. Relationships existing between the three architectural visions. For ...
Figure 3.9. Organization of a system model. For a color version of this figure, ...
Figure 3.10. The CESAM systems architecture pyramid. For a color version of this...
Figure 3.11. Alignment of the project system architecture with the product syste...
Figure 3.12. Descriptions versus expected properties. For a color version of thi...
Figure 3.13. Standard representations of states. For a color version of this fig...
Figure 3.14. Standard representations of static elements. For a color version of...
Figure 3.15. Standard representations of integration relations between static el...
Figure 3.16. Interfaces standard representation. For a color version of this fig...
Figure 3.17. Standard representations of an operational dynamic. For a color ver...
Figure 3.18. Standard representations of a constructional dynamic. For a color v...
Figure 3.19. Standard representations of flows. For a color version of this figu...
Figure 3.20. CESAM system architecture cube. For a color version of this figure,...
Figure 3.21. Example of a CESAM 9-views matrix for an electronic toothbrush64. F...
Chapter 4
Figure 4.1. Impact of an error in environment architecture. For a color version ...
Figure 4.2. Example of a stakeholder hierarchy diagram for an electronic toothbr...
Figure 4.3. Example of an environment diagram for an electronic toothbrush. For ...
Chapter 5
Figure 5.1. Example of a need architecture diagram for an electronic toothbrush....
Figure 5.2. Example of the lifecycle diagram for an electronic toothbrush. For a...
Figure 5.3. Example of a use case diagram for an electronic toothbrush. For a co...
Figure 5.4. Example of operational scenario diagram for an electronic toothbrush...
Figure 5.5. Example of operational flow diagram for an electronic toothbrush. Fo...
Chapter 6
Figure 6.1. Example of a functional requirement architecture diagram for an elec...
Figure 6.2. Example of functional mode diagram for an electronic toothbrush
Figure 6.3. Example of a functional breakdown diagram for an electronic toothbru...
Figure 6.4. Example of a functional interaction diagram for an electronic toothb...
Figure 6.5. Example of a functional scenario diagram for an electronic toothbrus...
Figure 6.6. Example of the functional flow diagram for an electronic toothbrush
Chapter 7
Figure 7.1. Design structure matrix (DSM) of a system
Figure 7.2. Example of a constructional requirement architecture diagram for an ...
Figure 7.3. Example of configuration diagram for an electronic toothbrush. For a...
Figure 7.4. Example of a constructional breakdown diagram for an electronic toot...
Figure 7.5. Example of a constructional interaction diagram for an electronic to...
Figure 7.6. Example of a constructional scenario diagram for an electronic tooth...
Figure 7.7. Example of a constructional flow diagram for an electronic toothbrus...
Chapter 8
Figure 8.1. The two dimensions of a risk. For a color version of this figure, se...
Figure 8.2. Example of a risk classification grid. For a color version of this f...
Figure 8.3. Typical interface between design and safety teams according to safet...
Chapter 9
Figure 9.1. Example of a collective vote during a prioritization workshop. For a...
Figure 9.2. Example of a collective evaluation during a prioritization workshop....
Conclusion
Figure C.1. Example of a system architecture file for a power sliding door withi...
Appendix 2
Figure A2.1. The Calcutta subway case. For a color version of this figure, see w...
Figure A2.2. The missing operational analysis in the Calcutta subway case. For a...
Figure A2.3. The Ariane 5 case. For a color version of this figure, see www.iste...
Figure A2.4. The Airbus 380 case. For a color version of this figure, see www.is...
Figure A2.5. The Denver luggage management system case. For a color version of t...
Appendix 3
Figure A3.1. Our system of interest: a smartphone system. For a color version of...
Figure A3.2. Stakeholder hierarchy diagram of a smartphone system. For a color v...
Figure A3.3. Environment diagram of a smartphone system. For a color version of ...
Figure A3.4. Need architecture diagram of a smartphone system. For a color versi...
Figure A3.5. Analysis of the need distribution of a smartphone system. For a col...
Figure A3.6. Lifecycle diagram of a smartphone system. For a color version of th...
Figure A3.7. List of use cases classified per lifecycle phase of a smartphone sy...
Figure A3.8. Example of an operational scenario diagram of a smartphone system. ...
Figure A3.9. Functional requirement architecture diagram of a smartphone system
Figure A3.10. Partial need to the functional requirement matrix of a smartphone ...
Figure A3.11. Functional breakdown structure diagram of a smartphone system
Figure A3.12. Functional interaction diagram of a smartphone system. For a color...
Figure A3.13. Example of a functional scenario diagram of a smartphone system. F...
Figure A3.14. Constructional requirement architecture diagram of a smartphone sy...
Figure A3.15. Partial need and functional requirement to the constructional requ...
Figure A3.16. Product breakdown structure of a smartphone system. For a color ve...
Figure A3.17. Encapsulation pattern. For a color version of this figure, see www...
Figure A3.18. Constructional interaction diagram of a smartphone system. For a c...
Figure A3.19. Implementing a constructional architecture of a smartphone system....
Figure A3.20. Implementation architecture of a smartphone system. For a color ve...
Appendix 4
Figure A4.1. Example of a system modeling tool interface. For a color version of...
Figure A4.2. Generic structure of a system model based on the CESAM framework
Figure A4.3. Refined organization of views in a system model based on the CESAM ...
Figure A4.4. Refined organization of objects in a system model based on the CESA...
Figure A4.5. Refined organization of needs and requirements in a system model ba...
Figure A4.6. Organization of a system model based on the CESAM framework within ...
Guide
Cover
Table of Contents
Title Page
Copyright
Preface
Acknowledgments
Introduction: Systems
Begin Reading
Conclusion
Appendices
Appendix 1: System Temporal Logic
Appendix 2: Classical Engineering Issues
Appendix 3: Example of System Model Managed with CESAM
Appendix 4: Implementing CESAM through a SysML Modeling Tool
Appendix 5: Some Good Practices in Systems Modeling
References
Index
End User License Agreement
Pages
v
iii
iv
ix
x
xi
xii
xiii
xv
xvii
xviii
xix
xx
xxi
xxii
xxiii
xxiv
xxv
xxvi
xxvii
xxviii
xxix
xxx
xxxi
xxxii
xxxiii
xxxiv
xxxv
xxxvi
xxxvii
xxxviii
xxxix
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
83
84
85
86
87
88
89
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
141
142
143
144
145
146
147
149
150
151
152
153
154
155
157
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
209
210
211
212
213
214
215
216
217
219
220
221
222
223
224
225
226
227
228
229
230
231
232
Systems of Systems Complexity Set
coordinated by
Jean-Pierre Briffaut
Volume 3
Model-based Systems Architecting
Using CESAM to Architect Complex Systems
Daniel Krob
First published 2022 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:
ISTE Ltd
27-37 St George’s Road
London SW19 4EU
UK
www.iste.co.uk
John Wiley & Sons, Inc.
111 River Street
Hoboken, NJ 07030
USA
www.wiley.co
© ISTE Ltd 2022
The rights of Daniel Krob to be identified as the author of this work have been asserted by him in accordance with the Copyright, Designs and Patents Act 1988.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s), contributor(s) or editor(s) and do not necessarily reflect the views of ISTE Group.
Library of Congress Control Number: 2021952707
British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library
ISBN 978-1-78630-820-7
Preface
CESAMES and the CESAM Community
The CESAM Community, which disseminates the CESAM method and is the origin of this book, is managed by CESAMES, a non-profit organization created under the French law of July 1, 1901.
CESAMES emerged in 2009, as a spin-off of the “Engineering of Complex Systems” industrial chair of Ecole Polytechnique, the leading engineering university in France, with the objective of promoting systems architecting in academia and industry. To do so, CESAMES organizes awareness events all year long that allow scientists and industrialists to meet and to share about complex industrial systems. As an example, since 2010 CESAMES has organized on a yearly basis the “Complex Systems Design & Management” (CSD&M) international conference series. This event – that now alternates between France and Asia – gathers each year more than 300 academic and professional participants, coming from all parts of the world. CESAMES also manages working groups and professional workshops, always with the same goal: increasing awareness about systems architecting methods and tools.
Thanks to these events, CESAMES has federated a significant international community of systems architects and engineers who all share the same vision: systems architecting and engineering represent a key factor of competitiveness for companies that has to be developed.
In order to reinforce its visibility and to get more influence at a worldwide level, CESAMES decided in 2017 to manage its activities through the “CESAM Community” banner. However, the mission of the CESAM Community remained of course the same: sharing good practices in enterprise and systems architecture among the community and attesting the competences of the community members in these domains through the CESAM certification.
More precisely, the CESAM Community works to achieve the following:
– Make architecture a key tool for business competitiveness
by disseminating its use within companies and by communicating the results of its implementation through the visibility and communication actions managed by the CESAM Community.
– Propose and develop the best practices of systems architecture in industry and services
, through the creation of dedicated publications and the sharing of returns on experience between systems architects and engineers during the events of the community.
– Propose reference systems architectures
, based on the generic CESAM systems architecting methodology, that are specific to some industrial sectors in order to facilitate the work of systems architects and engineers within these sectors.
– Facilitate access to the CESAM method
and develop its use in France and worldwide.
CESAMES Systems Architecting Method (CESAM)
The CESAM Community and its members act as the initial developers and contributors of the CESAMES Systems Architecting Method (CESAM), which is presented in more detail in this book.
The CESAM is a systems architecting and modeling framework, developed since 2003 in close interaction with many industrial leading companies. It is dedicated to the working systems architects, engineers or modelers in order to help them to better master the complex integrated systems they are dealing with in their day-to-day professional life.
The CESAM framework indeed has a number of unique features:
1) First of all, CESAM has sound mathematical fundamentals, which are providing a
rigorous and unambiguous semantics to all introduced architectural concepts
. This first property is clearly key for ensuring an efficient and real understanding
1
between the stakeholders of a system development project (which is often key for ensuring the success of such projects).
2) These bases ensure that CESAM is a
logically complete lean systems modeling framework
: in other terms, the architectural views proposed by CESAM are just necessary and sufficient to model any integrated system. This second property guarantees both the completeness of a CESAM system model and that no useless modeling work will be done when using CESAM.
3) Finally, CESAM is
practically robust and easy to use
both by systems architects and systems modelers. This was indeed pragmatically observed among the very large number of concrete systems within many industrial areas (aeronautics, automotive, civil engineering, defense and security, energy, railway, space, etc.) that were modeled and architected using CESAM.
Note also that the CESAM framework – due to the right level of abstraction – can be implemented and used with both all existing systems modeling frameworks and systems modeling software tools2 available on the market.
Last but not least, one shall finally point out, as already stated, that CESAM intends both to propose a generic architecting framework, as introduced in this book, and to progressively offer specific concrete reference systems architectures for a number of industrial application domains in order to facilitate the work of the systems architects and engineers within these areas.
How to read this book?
This book on model-based systems architecting with CESAM is organized in order to be read in many different ways. Typical reading modes are presented below depending on the reader’s objectives.
– Discovering what a system is from a pragmatic perspective:
the Introduction is an introductory section that introduces systems from a purely practical point of view.
– Understanding systems architecting fundamentals:
Chapter 1
is dedicated to the reader who wants to discover the sound logical basis the CESAM framework relies upon.
– Being aware of systems architecting benefits:
you may only read
Chapter 2
where the main motivations of systems architecting are described.
– Getting an overview of the CESAM framework:
you shall then focus on
Chapter 3
where all the core CESAM systems architecture concepts are presented.
– Practicing systems architecting:
a systems architect shall know how to model a system, as well as, much more deeply, what are the needs that the system shall satisfy since they will be the compass to be used in order to regularly make the right design decisions. We thus recommend systems architects to read first
Chapter 2
to be aware of the main motivations of systems architecting. You may then pass to
Chapter 3
up to
Chapter 9
in order to get a good overview of the CESAM framework, then learn the main systemic views and their connection with dysfunctional/safety analyses, and how to use them within an architectural decision process (which is discussed in
Chapter 9
). Conclusion will finally provide you some indications on how to progress in systems architecting.
– Analyzing systems safety:
a safety expert shall know how to feed the dysfunctional/safety analyses with relevant systems architecture information. The connections between systems architecture and dysfunctional/safety analyses are explained in
Chapter 8
.
– Modeling systems:
read first
Chapter 3
to get an overview of CESAM systems architecture views and follow then from
Chapter 4
up to
Chapter 7
in order to learn one by one what are the views requested to model completely an integrated system. A last step may be to end by
Appendix 3
where you can find a rather complete CESAM model on a realistic case study.
The proposed agenda
This model-based systems architecting which uses CESAM to architect complex systems is organized into 10 chapters, with the addition of some appendices specifically dedicated to more specialized material, as described below.
–
Introduction – Systems
, which is intended for readers with only a little system background knowledge.
–
Chapter 1
– Introduction to CESAM
that may be skipped for the first approach.
–
Chapter 2
– Why Architecting Systems?
Which presents the main motivations of the systems architecting approach and of the CESAM framework.
–
Chapter 3
– CESAM Framework
that provides an overview of all CESAM concepts.
–
Chapters 4
to
7
that present in detail, one after the other, each architectural vision of the CESAM systems modeling framework:
-
Chapter 4
– Identifying Stakeholders: Environment Architecture
.
-
Chapter 5
– Understanding Interactions with Stakeholders: Operational Architecture
.
-
Chapter 6
– Defining What the System Shall Do: Functional Architecture
.
-
Chapter 7
– Deciding How the System Shall be Formed: Constructional Architecture
.
–
Chapter 8
– Taking into Account Failures: Dysfunctional Analysis
which discusses the nature of the connection existing between systems architecture and dysfunctional/safety analyses.
–
Chapter 9
– Choosing the Best Architecture: Trade-off Techniques
that introduces systems architecture prioritization, a key tool for the systems architect.
–
Conclusion
, which gives some hints to the reader on how to continue the systems architecting journey initiated by this book.
Daniel KROB January 2022
1
This feature is in particular fundamental for managing convergence between the stakeholders of a system development project. It explains why collaboration is also at the core of the CESAM framework (see
sections 1.3
and
2.4
for more details).
2
CESAM models were, for instance, industrially implemented under CAMEO
TM
from Dassault Systèmes, Capella
TM
open-source tool, Enterprise Architect¥ from Sparx Systems or Rhapsody
TM
from IBM (see
Appendix 4
for more details).
Acknowledgments
CESAMES and the CESAM Community would like to thank the numerous companies and systems architects and engineers without whom the CESAM framework would have never existed. All concepts and methods presented in this book were indeed prototyped and progressively developed during various missions in close contact with real concrete systems and problems.
The second acknowledgment goes to Ecole Polytechnique, especially to the sponsors of its industrial chair “Engineering of Complex Systems”, that is, Dassault Aviation, Naval Group, Direction Générale de l’Armement (DGA) and, last but not least, Thales. This book is indeed, for CESAMES and the CESAM Community, the ultimate outcome of a long and progressive research and maturity process that was initiated around 20 years ago with the creation of the chair.
Introduction Systems
I.1. Systems from a pragmatic perspective
Let us first point out that we shall only be concerned with engineered systems in this book, that is, systems that are designed and constructed by people1. As a result, the term “system” will only refer to engineered systems within the scope of this book.
Note that there are of course other objects – for instance, biological or natural systems – that may be considered as systems in an unformal meaning, but we shall not consider them in the perimeter of this book, which intends to focus on a methodological framework for architecting the systems that are developed by engineers. However, notice that engineered systems are not purely technological systems: organizational systems, such as a company or a city, which are a mix of technical systems and organized people, may also be considered to be the result of a voluntary design process and, thus, engineered systems.
From a pragmatic perspective, engineered systems can be classified in the following different types, depending on their level of integration, as described in Table I.1:
–
Product components
, that is, systems that do not make sense independently of the product in which they are integrated: a typical example is an aircraft engine which only works within an aircraft. The classical design strategy for such systems is called the V-cycle: the system is first designed (the left-hand side of the V), then constructed (the bottom part of the V), before being finally verified and validated (the right-hand side of the V).
–
Integrated products
, that is, systems which can be used as such, without being integrated into a larger system. These systems are usually obtained by integrating in a fixed way many product components which are therefore strongly coupled within the resulting integrated product. An aircraft is an example of an integrated product since it results in the integration of aircraft engines, landing systems, wings, fuselage, cabin, avionics components, etc. Note that the design strategy of an integrated product is more complicated than the design strategy of a single product component, since one now has to coordinate the different design cycles of the components forming the final product: in this matter, one speaks sometimes of a W-cycle when one wants to highlight the fact that the overall design cycle of the integrated product is the union of a lot of inter-related V-cycles associated with each product component.
–
Systems of systems
, that is, systems formed of several integrated products, each of them having its own life (see also Luzeaux and Ruault (2010)). These systems typically result from a weak coupling – with interfaces that can be realized or broken, depending on time – of several moving/fixed integrated products. An airport is an example of system of systems since it results in the integration of a fixed, but time evolving, part, made of several integrated products such as local air traffic management system, aircraft maintenance facilities, passenger, luggage and cargo transportation systems, passenger areas, security systems, garages and roads, and a permanently moving part, consisting of the various aircrafts that enter and leave an airport. Such systems are much more difficult to design since the coordination effort to achieve smooth integration is more important due to the huge number of independent systems that one needs to consider. Hence, interface standardization between the various systems forming a system of systems becomes now a key design tool and strategy.
–
Ecosystems
, that is, systems that are formed of several interconnected systems of systems. Here, we are therefore dealing with many inter-dependent components that are interacting from time to time, depending on the needs. The global air traffic management system in its whole – at Earth level – is such an ecosystem that involves all airports, all local and regional traffic management systems and many satellite systems. Such an ecosystem has no owner, and its good design and behavior only results in the agreement of the involved actors.
Table I.1 summarizes these different categories of engineered systems that are illustrated on different aeronautics examples, as presented above.
Table I.1.Categories of engineered systems. For a color version of this table, see www.iste.co.uk/krob/systems.zip
Type of system
Characteristics
Typical example
Design Strategy
Product component
Does not exist independently of a product
V-cycle
Integrated product
Strong coupling of fixed components
W-cycle
Systems of systems
Weak coupling involving moving components
Interfaces standardization
Ecosystem
Interactions involving moving components
Actors Influence
As one can see, the notion of system – from a pragmatic perspective – covers various realities. As a matter of fact, engineered systems can indeed be found in all industrial domains where they may, for instance, refer to the following objects:
–
In the automotive sector
: a car, any component of a car (cockpit, chassis, electric/electronic infrastructure, powertrain, etc.) or an advanced driver assistance service (ADAS).
–
On the aeronautical sector
: an aircraft, a helicopter, a drone or any component of these systems (cockpit, fuselage, cabin, engine, landing system, avionics, etc.).
–
In the defense sector
: a military system (vehicle, missile, communication and control system, etc.), a system of systems that involves these systems or any component of these systems.
–
In the energy sector
: an energy production system (nuclear plant, thermal power plant, wind turbine farm, etc.), an energy distribution system or any component of these systems.
–
In the naval sector
: a ship, a sub-marine, a marine drone, a system of systems involving these systems or any component of these systems.
–
In the railway sector
: a train, a metro, a tram, a railway infrastructure, a railway signaling system or any component (e.g. traction, embedded system, station, etc.) of these systems.
–
In the service sector
: an enterprise information system, a service organization or any socio-technical component of these systems.
–
In the space sector
: a satellite, a space launcher, a spaceship, a satellite constellation, a value-added space service or any component of these systems.
Note that most of the systems that we just mentioned here above are either product components or integrated products. This reflects the fact that these two last categories of engineered systems are clearly the ones that one finds the most in the industry, from a pragmatic perspective. On the other hand, it is indeed rather rare in practice that one has to design a system of systems or an ecosystem, which does not however mean that such systems are less important. The point is just that system design always requires a system owner who requests the design of a given system and that unique ownership of systems of systems and of ecosystems is often non-existent.
Note finally that we specially dedicated section I.3 to the presentation and discussion – in more detail – of a number of concrete examples of systems, following the categorization we introduced within this section, in order for the reader to become more familiar with engineered systems.
I.2. The need for a specific approach to deal with systems
Now that we have explained the notion of a system from an empirical point of view, we can see why it is necessary to introduce a particular approach to conceive them, which is indeed the purpose of this book. After all, all the engineered systems that we listed in the previous section, are working perfectly and we could therefore very well conclude that there is no need of a specific approach to their design. The point is that these engineered systems are all characterized by a huge complexity and their design is extremely difficult (see section 2.2 for more details on system complexity). Moreover, traditional engineering disciplines and methods generally fail to take into account a certain number of specificities of complex engineered systems on which we shall now focus. This motivates systems architecting, which is the specific system design discipline to which this book is dedicated.
The very first point that we think is important to highlight is the fact that the design and development of an engineered system that is somewhat complex, requires us to deal with a multitude of details in which it is easy to get lost. Managing all of these details is of course necessary, but the problem is not to see and think of a system as a sum of details, knowing that experience shows that it is easy to lose the overview of a given system and to miss some of its absolutely structuring elements.
To give just one real example of such a situation, during the recent construction of an energy plant, a key industrial equipment arrived on site and it was not possible to install it: the location – a dedicated room in the center of the power plant – where it was to be placed was indeed built, but the designer just “forgot” to think of how to put it there. It was therefore necessary to break the concrete infrastructure to make room in order to move the equipment into place, which generated quality losses, additional costs and delays and new operational safety problems which required some of the dysfunctional studies to be redone. Such examples are unfortunately not isolated at all, and avoiding them is a key challenge for many industries.
In order to avoid such issues, systems architecting proposes analyzing system problems from a high-level perspective, in order to be sure to capture all the most structuring elements of a system, rather than from a low-level perspective, in order not to become lost in the details. To explain this key idea, let us take a mountain metaphor. Look first at the photo of Figure I.1, showing Mont Blanc, the highest summit in Europe, which was taken from Chamonix at 1,200 meters above sea level, a small village in the French Alps, where mountaineering was invented at the end of the 18th century. The point is that Mont Blanc does not look very impressive in that photo and one cannot perceive very well why it has such international fame. However, on the other hand, one can see very well on the photo all the details on the flowers within the streets of Chamonix.
Let us now have a look at the second photo of Mont Blanc provided in Figure I.2. It was taken more or less at the same geographic location as the first photo, the only difference in this case is that we are now 2,000 meters over the sea. We have lost here the details of the flowers of Chamonix village, but gained a wonderful overview of the Mont Blanc massif, which was invisible to us when looking on exactly the same landscape from Chamonix valley. This new perspective provides us with a much better understanding of why these mountains are so famous around the world!
Figure I.1.Mont Blanc from Chamonix (1,200 meters above sea level). For a color version of this figure, see www.iste.co.uk/krob/systems.zip
Figure I.2.Mont Blanc from the Black Lake (2,000 meters over the sea). For a color version of this figure, see www.iste.co.uk/krob/systems.zip
As we can see from that metaphor, the point of view that one takes when looking on a system can radically change the perception of the considered system and not taking a high enough overview of a system leads to losing the global picture, while risking focusing on details, which are ultimately of no great importance. The first key idea behind systems architecting – the discipline that proposes a specific approach to system design and to which this book is dedicated, as already stated – is therefore to maintain permanently a global vision of the system of interest, meaning both not to forget crucial points for the system design and to guarantee to reach all details, when refining this global vision.
The second key point that we would like to highlight is that any reasonably complex system design always has a socio-technical dimension. An engineered system can indeed always be broken down into a series of technical components, each of them being owned by a given designer. Designing the full system can thus be seen as both, solving a complex technical puzzle where one needs to understand how these various components shall be smoothly integrated within the complete engineered system, as well as aligning all the local designers around a global vision of the system (see Figure I.3).
Figure I.3.The socio-technical dimension of systems. For a color version of this figure, see www.iste.co.uk/krob/systems.zip
This explains why the second key characteristics of systems architecting consists of always analyzing systems problems from a global multi-disciplinary perspective rather from a local mono-expertise point of view and ensuring the collaboration between all actors involved in a system design (see also sections 1.3 and 2.5 for more details on the collaborative dimension of systems architecting).
I.3. Examples of systems
The purpose of this new section is to present in more detail some concrete examples of systems. To this aim, we shall use the system classification introduced in section I.1 and present and discuss a significant example of a system for each level of this classification. We shall therefore analyze from a system perspective, first a computer system as an example of a complex component, second an extended vehicle as an example of an integrated product, then the railway system as an example of system of a systems and finally the world as an example of a complex ecosystem.
We hope that these examples will allow the reader to become more familiar both with the notion of a system and with the way an engineered system is analyzed from a systems architecting perspective.
I.3.1. A complex component: a computer system
The first system that we shall consider is a computer system like the ones typically found in a data center as shown in Figure I.4. Let us indeed recall that data centers are dedicated buildings that house operational computer, telecommunications and data storage systems, as well as redundant/backup components and infrastructure for power supply, data communication connections, environmental controls, such as air-conditioning, fire sensing and suppression or intrusion detection and various security devices. Data centers are therefore integrated products – in the meaning of section I.1 – and a computer system is therefore just one of its key complex components.
Figure I.4.A complex component system: a computer system. For a color version of this figure, see www.iste.co.uk/krob/systems.zip
To better understand such a system from a systems architecting perspective, let us present its constructional interaction diagram (see section 7.2 for more details on that concept) that focuses on the interactions existing between the different components of a computer system (see Figure I.5) and allows us to both capture all its components and the way they are interconnected.
These interactions involve, in practice, various types of objects such as, for instance, mechanical forces, electricity, data, electromagnetic signals, air, time, etc. It is therefore important to distinguish these different types of interactions when designing a constructional interaction diagram, which can be achieved by using a different color code for each type of interaction (see Figure I.5).
Figure I.5.Constructional interaction diagram of a computer system. For a color version of this figure, see www.iste.co.uk/krob/systems.zip
A key point is also to structure the constructional interaction diagram by organizing the components of a computer system into logical layers, each of them formed of components that have the same nature (see Figure I.5 where we used three different colors to distinguish the three logical layers that we introduced for a computer system). Such structuration allows us to more easily understand the architecture of the considered system through the meaning associated with the layers, to simplify the network of interactions between components and to separate the core components from the less important ones. The knowledge of the interactions between the different components of a given system is also key in the context of a modular approach since it highlights the interfaces that shall be standardized – that is, those that exist between the different logical layers – and allows us to better master the standard module configurations that are to be proposed in such an approach.
The generic constructional interaction diagram of a computer system is elicited in Figure I.5. This diagram organizes all computer system components in the following three logical layers:
–
Layer 1 – Support components
: this first layer is formed of all the components of a computer system that support its main functionality, that is, computing. These components are also in direct interaction with key external stakeholders: the
chassis
mechanically interacts with the bay in which it lays in the data center; the
power unit
is interfaced with the electric infrastructure provided by the data center; the
logical network unit
, formed of all network cards of a computer system, independently of their locations, is connected to the external network through the data center telecommunication infrastructure and the
ventilation unit
, formed of all fans and heat dissipaters, manages the air exchanges through the chassis.
–
Layer 2 – Computing components
: this second logical layer contains all core components of a computer system that achieve the core computing functionality, that is, first the
main board
, which orchestrates the other components of this layer, then the
data processing unit
with all CPUs and GPUs
2
(if any), the
memory
and the
logical storage unit
formed of all the possible storage devices, independently of their physical locations. Note that this computing layer is organized according to a classical von Neumann architecture that can be traced back to the very origin of computers in the 1940s (see von Neuman 1945; Godfrey and Hendry 1993; Wikipedia (2021p)).
–
Layer 3 – Software components
: this last layer consists just of the software components of a computer system that can be separated into two groups: the first group is formed of the
operating system
and of the
firmware software
that are both installed by the computer system manufacturer, the second one is formed by the proprietary software installed by the final end-user, which is another key stakeholder of a computer system, during the normal operation of the computer system.
Note finally that the mechanical, electrical, data and air interactions/exchanges between the various computer system components are traced in the constructional interaction diagram with the following different color codes: black for mechanical interactions, red for electrical interactions, green for data exchanges and finally purple for air exchanges.
The key point that this first example allows us to see is that the architecture of a modern computer system is fundamentally the same as the one that was imagined by J. von Neuman in 1945, as pointed out above. Good systems architectures are indeed often remarkably stable with time, which explains their importance! Finding a good architecture – which is usually characterized by its simplicity and its apparent obviousness – is however not simple and obvious at all.
I.3.2. An integrated product system: the extended vehicle
The second system that we shall consider in this example section is an integrated product system coming from the automotive industry, that is, an extended vehicle
