130,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Organization and Pedagogy of Complexity deals with real systems, their architecture, and speaks of those who design, develop and maintain them. After a summary of the architecture proposed by Daniel Krob, president of CESAMES in Paris, France, the book focuses on the sensor and effector equipment that routes and converts the system's information to the place where it is processed. These are the equivalent of the system's sense organs. It also analyzes the roots of complexity from the perspective of combinatorics: in real systems, everything comes down to cases and/or configurations being validated in greater or lesser numbers, but which must be kept under control. This book presents two case studies, giving a global vision of complexity. Finally, it presents a prospective approach that brings the engineering of artificial systems closer to that of biological systems, based on first-hand information provided by Philippe Kourilsky, Emeritus Professor at the Collège de France.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 508
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Title Page
Copyright Page
Preface
Part 1: The Organic Component of Systems
Introduction to Part 1
1 Elements of Systemics
1.1. Introduction
1.2. Systemic definition of a system
1.3. Organization of a systemic model
1.4. Architecture of a system
1.5. In conclusion
2 Natural Functions
2.1. The notion of energetic transducers, revisited
2.2. Some fundamental transducers
3 Emergent Properties
3.1. Integration
3.2. The stack structure and its constructive logic
3.3. Milestones from the history of computer stack development
3.4. Moore’s “law”: a structure for integration
Part 2: A Complex World
Introduction to Part 2
4 Phenomenology of Complexity
4.1. Drive and control in a complex environment
4.2. Communicating in a complex environment
4.3. The four dimensions of complexity
4.4. Measuring complexity
4.5. Counting
5 The Roots of Complexity: Inaccessible Numbers
5.1. The provenance of inaccessible numbers
5.2. Typology of inaccessible numbers
5.3. Familiar numbers
5.4. The library of Babel
5.5. Inaccessible numbers of the third infinity: information sciences
6 Walking through Complexity
6.1. The example of the computer stack
6.2. The organized objects of the 3rd infinity
6.3. Facing the immensity of the infinitely complex
6.4. Testimonials: another look at the interface stack
Part 3: Examples of Systemics and Complexity
Introduction to Part 3
7 Systemic Aspects of the French Electrical System
7.1. Growth: the “life” of an electrical system and its end
7.2. Interoperability and cooperation
7.3. Resilience
7.4. Computerization and organization
7.5. Future problems
7.6. Conclusion
8 Systemic Aspects of Project Systems
8.1. The science of projects
8.2. Control
8.3. Volume of information exchanges in projects
Conclusion ConclusionProspective DialogueProspective Dialogue
List of Acronyms
References
Index
Other titles from iSTE in Systems and Industrial Engineering – Robotics
End User License Agreement
List of Illustrations
Chapter 1
Figure 1.1
The process of systemic modeling
Figure 1.2
Classic understanding of a formal system
Figure 1.3
Formal integration of (formal) systems
Figure 1.4
Concrete integration of (real) systems
Figure 1.5
Formal environment of a (formal) system
Figure 1.6
Example of the reference environment of a real system
Figure 1.7
Generic examples of systems in the interior of (I) and the exteri
...
Figure 1.8
Example of architectural visions for a real system
Figure 1.9
A universal framework for the architectural analysis of a real sy
...
Figure 1.10
Sample organization of real system descriptions
Figure 1.11
The angles of analysis of a (real) system
Figure 1.12
The cube of architectural analysis of (real) systems
Figure 1.13
Systemic perspective of the architectural conception system
Figure 1.14
Description of the functional dynamic of the architecture proces
...
Figure 1.15
The role of a systems architect
Chapter 2
Figure 2.1
Transduction chain
Figure 2.2
Mechanical energy transducer
Figure 2.3
Cerebral/aural/phonation transducer
Figure 2.4
Transformation transducer for an energetic signal
Figure 2.5
Transducer with a power law
Figure 2.6
Functional spaces and transduction between spaces
Figure 2.7
“Intelligent” transducers
Figure 2.8
Logical addition with remainder
Figure 2.9
Diagram of logical addition with a remainder
Figure 2.10
CMOS transistors
Figure 2.11
Adder circuit with CMOS transistors
Figure 2.12
Iterative adder circuit
Figure 2.13
Connection elements
Chapter 3
Figure 3.1
The computer stack in its user context
Figure 3.2
Broken symmetry: beam compression
Figure 3.3
Structure of the computer stack
Figure 3.4
Constructive logic of matter in circuitry
Figure 3.5
Organizing the circulation of events in the stack
Figure 3.6
System and sub-system levels
Figure 3.7
Organizing the inside/outside boundary
Figure 3.8
Confusion between observation levels
Figure 3.9
The middleware layer of ACID transactions
Figure 3.10
The functional/organic mediator
Figure 3.11
Inside/outside interface costs
Figure 3.12
Growth rates in the population of programmers
Figure 3.13
Moore’s law and engineer performance
Figure 3.14
VLSI engraving
Figure 3.15
The computer stack and interoperability
Chapter 4
Figure 4.1
Complexity in interactions.
Chapter 5
Figure 5.1
An illustration of the three infinities (source: Gilles Cohen-Tan
...
Figure 5.2
Maxwell’s demon and the infinitely complex
Figure 5.3
The Galton board
Figure 5.4
A Bézier curve
Chapter 6
Figure 6.1
From the PC to the smartphone (exterior) (source: Laughlin, R.,
A...
Figure 6.2
Organizing the cohabitation of different logics
Figure 6.3
From the PC to the smartphone (interior)
Figure 6.4
Image of impossibility
Figure 6.5
The three infinities revisited via the smartphone
Figure 6.6
Varieties of complex systems
Figure 6.7
The world of programmers
Figure 6.8
René Thom’s meaning map
Figure 6.9
Real world/virtual world correspondences
Figure 6.10
Architecture in layers
Figure 6.11
Hierarchy of observers
Figure 6.12
Translation/transduction interface
Chapter 7
Figure 7.1
Energetic mutation in the early 20th century
Figure 7.2
Energetic mutation: overview
Figure 7.3
The French electrical system in the 1920s (source: Tribot-Laspier
...
Figure 7.4
Electricity advertisement from the 1920s. It outlines the ways of
...
Figure 7.5
Interconnections of European systems
Figure 7.6
Interoperability among means of production and transport
Figure 7.7
Time constants of the transport network
Figure 7.8
Regional frameworks and security perimeters
Figure 7.9
Principles of computerization
Figure 7.10
Progressive complexification of the IS of the electrical system
...
Chapter 8
Figure 8.1
Sets involved
Figure 8.2
Active information
Figure 8.3
Organization control
Figure 8.4
User/engineering interface
Figure 8.5
Notion of a reference framework
Figure 8.6
The exchange reference between {U, S, E}
Figure 8.7
The languages of the exchange reference framework
Figure 8.8
Complementarity of hierarchies
Figure 8.9
The nominal “life” of a system {U, S, E}
Figure 8.10
Analytic structure of conception/realization costs
Figure 8.11
Monitoring physical equipment
Figure 8.12
Mechanics of the integration operator
Figure 8.13
Coupling matrix
Figure 8.14
Evolution of error costs
Conclusion
Figure C.1.
Protein networks inside a cell
Figure C.2.
Modules, annotation and modeling
Guide
Cover Page
Title Page
Copyright Page
Preface
Table of Contents
Begin Reading
Conclusion: Prospective Dialogue
List of Acronyms
References
Index
Other titles from iSTE in Innovation, Entrepreneurship and Management
Wiley End User License Agreement
Pages
iii
iv
ix
x
xi
xii
1
3
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
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
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
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
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
279
280
281
282
283
Systems of Systems Complexity Setcoordinated byJean-Pierre Briffaut
Volume 4
Organization and Pedagogy of Complexity
Systemic Case Studies and Prospects
Jacques Printz
First published 2023 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
John Wiley & Sons, Inc.
27-37 St George’s Road
111 River Street
London SW19 4EU
Hoboken, NJ 07030
UK
USA
www.iste.co.uk
www.wiley.com
© ISTE Ltd 2023The rights of Jacques Printz 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: 2022951290
British Library Cataloguing-in-Publication DataA CIP record for this book is available from the British LibraryISBN 978-1-78630-704-0
Preface
This work illustrates some of the fundamental notions introduced in the book System Architecture and Complexity: Contribution of Systems of Systems to Systems Thinking (Printz 2020), but it can be read independently since the case studies and reflections presented here are written in an independent manner, without referring to precise aspects of the book in question.
What is difficult to understand in the engineering of these systems, which have relatively recently been named “complex systems” – indeed a proven pleonasm – is that once “integrated”, they appear to be a whole that is more than the sum of its parts; but this whole is retroactive on the constituent elements of these parts, thus forming an adaptive cycle which synchronizes the whole with its elements, even as they continue to maintain their autonomy, hence the expression “inseparable yet distinct.”
A system is defined to fulfill certain functions in any given environment constituting the outside of the system, as opposed to its organic elements constituting the inside. The two are connected, but an integrated system must constantly monitor its environment to ensure the latter remains within limits that permit it to continue its nominal functions, that is, what is expected of it as a whole.
In system maintenance operations – there are often decades of useful “life” before the inevitable retirement from its service – whether corrective, punctual or adaptive/progressive maintenance, which is more general, the elements reappear as they are, but we must never forget that they constitute a whole.
The presence of this whole manifests itself as constraints that translate into requirements which these elements must satisfy. The best physical analogy we can find is the measurement of something like the temperature of a body or the pressure of a gas or a liquid, which are known as intensive measurements. In the language of systems engineering, these intensive properties, “diffused” throughout all the elements of the system, are sometimes qualified as non-functional in the sense that they cannot be defined by some precise function in one or more units of these elements. For example, the performance or accessibility of the system, which are global properties of the architecture as a whole1.
Architecture is the means used to organize the complexity of systems, whether they are natural, like those produced by nature, or artificial, like those we build using resources and our intelligence. This is what some occasionally designate using the curious neologism of “simplexity”2. It is for this reason that we chose to introduce this volume with some text by my colleague, Professor Daniel Krob, the President of the Center for Excellence in Architecture, Management, and Economy of Systems (CESAMES), presented in the conference cycle at the College de France and lightly edited to comply with editorial constraints; and for which I thank him warmly. It is called Elements of Systemics – System Architecture, which is a perfect transition between our previous book and the subject of this one.
The first two parts are essentially dedicated to the organic components of systems, that is, the place or places in which a system acts in the real world. For it to be able to function there must be connections within it to transform the conceptual intention of the system’s architectural creator into action in the real world. The key equipment in this transformation is referred to by the generic term “transducers”, which were developed massively in the context of World War II, alongside the rapid rise of electronics and means of communication. Transducers, as will be explained, are energy converters that can, during this transformation, reliably amplify well above a million, like the opening of a valve in a hydroelectric dam or the removal of control rods in a nuclear reactor. They can also be giant microscopes, like the LHC at CERN, in Geneva.
The consequence of using this kind of equipment is that it will disseminate into the idealized world of the logical conception of the system, with all the complexity of the real world and its eventualities. This was the principal challenge taken on by the founding fathers of cybernetics, von Neumann, Shannon and Wiener. At the beginning, very few believed the obstacle could be overcome, but it was, hence the importance of thoroughly understanding the inherent complexity of the real world, correctly seen as primordial by von Neumann. This explains the presence of the chapters devoted to complexity, not from the perspective of theoretical complexity, which is itself fundamental, but from the perspective of complexity as experienced daily by the engineers designing and creating these systems, a complexity which concretely translates into the energy costs of verification and validation that ensure the fulfillment of a system’s service contract, established according to the needs of its users.
These notions will be illustrated through two case studies; the first concerns the French electrical system, which we were lucky enough to see from within, and the second concerns the system project, an essentially human system without which, however, none of the artificial systems discussed in this and the previous volume would have been possible. The system project has a complementary relationship with the technical system, which is necessarily the result of its activity. These two systems are distinct, but inseparable from one another.
All systems which are discussed in this book are artificial systems. We – both my colleague, D. Krob, and myself – have made the effort to avoid evoking an “explanation” that comes from systems which are far less comprehensible than the ones we have built ourselves. Nevertheless, the points of contact are numerous, even if only in complexity.
During the 1990s, artificial systems rose to the next level in complexity. Von Neumann, from the founding years, was very aware of the limitations in centralizing the systems of the time; his slogan was “who guards the guardians?” because every “center” is a point of weakness. But in the 1990s, the inherent centralization of the first mainframes took off with the arrival of distributed systems in architectures, called client-servers. The “center” disappeared, or rather, was everywhere. Moreover, their integration with the environment that saw them emerge from nothing was more and more direct. Their survival in terms of service contracts, for those using them – that is, all of us – requires them to contain, at their core, a realistic operational image of this environment, which is the source of all unforeseen eventualities. Artificial systems are beginning to develop a strange resemblance to living systems, which are totally integrated within their environment themselves.
This is why we have decided to conclude this book in the form of a dialogue between ourselves and an uncontested authority of one of the most emblematic systems of the living world, the immune system, without which we would be unable to survive: Philippe Kourilsky, Emeritus Professor of the College de France, a member of the French Academy of Sciences, and the general director of the Institut Pasteur. To live, he tells us, “we must first survive.” He is the author of numerous books including Le jeu du hasard et de la complexité (Kourilsky 2014), which makes connections between bioengineering and the engineering of engineers. “Living and surviving”, a systemic cycle between two distinct but inseparable notions, is how we will conclude.
I would like to take this opportunity to sincerely thank my two colleagues, Philippe Kourilsky and Daniel Krob, for the time they have dedicated to my project during the several discussions generated by this book and the previous one.
January 2023
Notes
1
See, for example:
https://en.wikipedia.org/wiki/ISO/IEC_9126
and the ISO/IEC norms 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models, whose importance was underscored in our previous work.
2
See, from the collection
Les Conférences du Collège de France
, the volume
Complexité-simplexité
(2014), by Alain Berthoz and Jean-Luc Petit (eds), and the book
La Simplexité
(2009) by Alain Bertoz.
Part 1The Organic Component of Systems
Introduction to Part 1
This first part illustrates an essential aspect of systems, which could not exist without said material aspect, the hardware (or “organic” as it is called in French), in the sense of the organ allowing concrete action. The entire difficulty of systems is that this component must be the exact mirror of the abstract model set out by the architecture, as recalled in Chapter 1, and reciprocally. Here, we are faced with what physicists call a relationship of complementarity. There are indeed two distinct realities, each with its own logic, but these two realties are inseparable; they are each the reflection of one another. Their correspondence must be maintained in all circumstances, including in the case of a failure following an unexpected event. Every organic element of the system is subject to the environmental constraints of wherever the element is found. It captures information and acts locally thanks to equipment called sensors and effectors, which allow the system to interact with reality while maintaining the service level negotiated with users. The system monitors its environment and monitors itself to ensure that it continues to work properly. In the “engineered” systems discussed in this book, the information required for the “life” of the system circulates electronically or electromagnetically, whatever the scale of the reality it represents, but in reality, several other sources of energy do the work. We must thus define and manage these energetic correspondences with special equipment generically called transducers. This is the principal subject of this first part, for without transducers, the science of systems would be nothing but an abstract game of logic and mathematics, and while this is certainly interesting – fascinating, even – it would not have any real claim on reality. In this game, we will see that that the human element remains preponderant, for it is all part of the creative genius which characterizes the human race, when faced with the many challenges for survival in a world whose complexity is more and more obvious to us.
1Elements of Systemics: Systems Architecture
1.1. Introduction
This chapter is a summary that my colleague, Professor Daniel Krob, President of the French Center for Excellence in Architectural, Management and Economy of Systems (Centre d’excellence sur l’architecture, le management et l’économie des systems, CESAMES), allowed me to reproduce from his lectures and various publications, with some minor adjustments for this present edition. This synthesis contains eight fundamental definitions and a theorem on existence. It is in perfect harmony with my previous book, System Architecture and Complexity: Contribution of Systems of Systems to Systems Thinking, from the same collection.
The systems that humans design and make are at the heart of the modern world: it is indeed enough to think of social and political systems, economic and industrial systems, monetary and financial systems, energy production and distribution systems, transport systems, communication systems and more generally, the many organizational and technological systems that surround us, to realize that “engineered” systems are simply everywhere1!
More and more, all these systems are characterized by both a great intrinsic complexity and ever-increasing interdependencies. Mastering these systems has become a high stake in a world going through profound transformations. They must be able to resist the constant and often contradictory pressures of citizens and consumers, markets and regulation, competition and technological innovation, to cite but a few examples of the forces to which they are subjected2.
But mastering the complexity of a system fundamentally means being able to master its integration processes, in other words, its construction through interconnectivity and/or the networking of smaller systems. This process surely remains largely misunderstood, for it generates the mysterious phenomenon that is emergence: an integrated system will indeed always have new “emergent” properties that cannot be easily obtained or expressed through its building blocks.
Theorizing the integration of a heterogeneous complex system resulting from the interaction of several homogeneous systems consequently requires us to reason transversally, by constructing a new type of model that captures its emergence by coherently integrating the parts of each homogeneous model constituting the general systemic model. Now, we must acknowledge that nothing prepares us for this new paradigm of systemic reasoning, which obliges us to make connections between very different types of expertise and transcend the traditionally siloed categories of knowledge3.
The emergence of a true science of systems – systemics – capable of rigorously considering the numerous problems posed by the conception and management of the evolution of modern complex systems, is thus an urgent necessity if we are to be able to provide satisfactory responses to the many profoundly systemic challenges that humanity will have to face at the start of the third millennium.
This introduction to the subject thus seeks to be a modest yet resolute contribution to this new scientific discipline in proposing an integrated vision of systems architecture, that is, of the area of systemics that deals with the structure of systems and their process of conception.
1.2. Systemic definition of a system
1.2.1. From real systems to formal systems
When we speak of a “system” in systemics, it is fundamental to understand that we are speaking from a logical point of view of modeling, which immediately leads us to the distinction between the concepts of the “real system” and the “formal system.”
Figure 1.1The process of systemic modeling
The process of systemic modeling can indeed be seen as a permanent cycle between a process of formalization that consists of constructing a formal abstract model from an object in the real world – using the tools of systemic analysis – and a process of experimentation that consists of verifying that the structure and behavior of the real object, given or predicted by the model, are indeed those observed in reality: the real object will therefore not be considered a (real) system except in that a modeling process analyzes it as a (formal) system within the context of systemic modeling4. In short, we naturally often conflate these two notions of a “system”, but it is important to never forget that “the map is not the territory” in order to maintain a clear idea of what we are conceptualizing5.
1.2.2. Definition of a system
With these preliminary considerations posed, we are now equipped to provide our first two key definitions, namely, that of a formal system and a real system.
DEFINITION 1.1.– Formal system: a formal system S is characterized on the one hand by the overall data on inputs X, outputs Y and internal states Q, and on the other hand, by the two following kinds of behavior that tie these systemic variables to each other over time:
– functional behavior, which produces an output y(t) ∈ Y at any time t depending on the input x(t)∈X and the ordinary internal state q(t)∈Q of the system;
– internal behavior, which causes the internal state q(t)∈Q of the system to evolve over the course of time t as a result of an input x(t)∈X into the system.
Figure 1.2Classic understanding of a formal system
This definition is intentionally extremely flimsy, for it simply tells us, in essence, that a system is the data of input/output behavior and internal behavior6. This is not strange because the purpose is to capture the common points among all real systems, which are necessarily very limited given the diversity of objects which we must take into account. On the other hand, we now have a unified framework within which we will be able to reason in a consistent manner about every type of system, and thus theorize integration, which was the first of our objectives (see also, D. Krob, Elements of Complex Systems Architecture)7.
DEFINITION 1.2.– Real system: an object from the real world is called a real system from the moment its structure and behavior can be described by a formal system (in the sense of Definition 1.1), which we then call a model of the real system.
The near totality of human inventions – whether they be of an electro-mechanic, computing, or organizational nature – are thus analyzable as systems: the only change that occurs is in the nature of the laws – in this case physical, logical or sociological – which we use to define the functional and internal behaviors that make them into systems. The previous definitions also underscore that it is neither the nature, nor the size, nor the hierarchical position that make up a system, since almost every object can be seen as a system8. Considering an object as a system rests first and foremost on the choice in modeling: it is indeed the same as considering a particular object in the abstract to restrict the analysis to the systemic perspective, that is, within the framework given by Definition 1.1.
Let us point out that from here on, we will only provide definitions for formal systems, bearing in mind that they transfer directly onto real systems, given the modeling perspective that we have adopted here.
1.2.3. Integration of systems
We are now equipped to introduce the notion of system integration, which is the fundamental mechanism that allows, in practice, for the construction of a new system using other, smaller systems (materials, software, humans) by organizing them in such a way that it can execute – within a given environment – its assigned tasks.
DEFINITION 1.3.– Integration: let S1, …, SN be a set of N (formal) systems. We can thus say that a (formal) system S is the result of the integration of these systems if there exists, on the one hand, a (formal) system C obtained through the composition of systems S1, …, SN, and on the other hand, dual abstraction and concretization mechanisms that let us express:
– system S as an abstraction of system C;
– system C as a concretization of system S9.
This somewhat technical definition has the fundamental objective of positing integration as a mechanism that is distinct from the simple composition of models, in order to try to capture the emergence in our approach, structurally.
Figure 1.3Formal integration of (formal) systems
Our definition indeed clearly presents the fact that the description of a high-level system obtained through the interconnection of other systems requires us to have:
– models of each of the systems that constitute the high-level system;
– a new, high-level model that is specific to this system.
In other words, simply knowing the models of the constitutive parts of a system is never enough to model this system! This modeling postulate can be seen as the direct translation of the universal phenomenon that is emergence. It can moreover be verified within all the elementary systems of everyday life.
Let us consider, for example, a wall made only of bricks (without mortar to hold them together), to simplify things. A simplified systemic model of a brick can thus be characterized by:
– functional behavior consisting of the absorption of rays of light;
– internal behavior specified by the constant states of “length, width, height.”
In making a model of bricks, it is thus difficult to obtain anything other than the functional behavior of absorbing rays of light, which is clearly not the usual behavior of a wall since we want to be able to reflect the holes that exist in walls (windows), which themselves actually let the light through! We will also note that it is difficult – and surely in vain – to try to express the form of a wall (which is one of these typical internal states) in terms of the lengths, widths and heights of the bricks that make it up. All of this is therefore an argument for the fact that we must clearly create a dedicated, more abstract, systemic model in order to model the wall.
These observations perhaps appear to be merely common sense, if not naïve, but we unfortunately see that their consequences are more often than not misunderstood, which is the direct source of many of the quality problems observed in the great engineered systems of modern times. In fact, most people in the industry continue to think that mastering the components of an integrated system is sufficient for mastering the system as a whole. But the very nature of the mechanism of integration requires us to go beyond the satisfaction of managing components, when what we should be doing is appreciating it as an integrated system: it is just as necessary to have someone specifically managing the integrative model of the high-level system, that is, a systems architect, who is in fact usually missing from industrial structures, however strange that may appear10!
Figure 1.4Concrete integration of (real) systems
Finally, we should point out that the integration mechanism naturally creates hierarchies in systems, while simultaneously giving the systemic analysis a recursive dimension. Engineered systems are indeed made through successive system integrations: any integrated system therefore creates an integration hierarchy, which is also a hierarchy in abstraction given the nature of integration, and is called the systemic hierarchy of the initial system, which allows us to speak of the levels, sub-systems, sub-sub-systems, etc. of an integrated system.
1.3. Organization of a systemic model
1.3.1. Architectural visions of a system
The systemic approach consists of analyzing real systems as formal systems, which are therefore models that need to be identified through a systemic lens, in which we only think in terms of the interacting systems. The recursive character of systemic analysis thus automatically leads us to introduce the notion of the system environment, which denotes a closed super-system (i.e. without inputs or outputs) containing the system, therefore acting as the natural starting point for the process of recursive system analysis (see the following section).
DEFINITION 1.4.– Environment of a system: let S be a (formal) system. We can therefore say that a (formal) system E(S) is an environment for S if it is a (formal) closed system11that results in the integration of S and another (formal) system Ext(S), which we call the exterior of S in the environment E(S).
Figure 1.5Formal environment of a (formal) system
A real system of course has several (real) “environment” systems in the sense of Definition 1.4 (the physical world as a whole is the typical environment common to all real systems). The pragmatic constraints of the process of systemically conceiving of a given (real) system S lead us however to introduce the reference environment for S (which is often simply called the environment of S, in short), corresponding to the smallest “useful” environment of S. This is in fact none other than the system resulting from the integration of system S with all the (real) systems external to S that have an influence on its conception, consequently ignoring all the other (real) systems external to S when they are considered to have no interdependence (and thus no functional interaction) with the system being envisaged12.
Figure 1.6Example of the reference environment of a real system
We should point out that from this point on, everything that follows will be relative to a chosen environment for a system that will therefore always be considered as fixed a priori, which will let us speak without misnomers about the “environment” of a system. We can thus naturally adopt the following definitions, which model the fact that the environment of a system S automatically defines a boundary between the interior and the exterior of S.
DEFINITION 1.5.– Interior and exterior: let S be a (formal) system, E(S) its (formal) environment, and Ext(S) its (formal) exterior in this environment, in the sense given in Definition 1.4. We can thus say that a (formal) system I (with respect to E) is in the interior (with respect to the exterior) of S if system S (with respect to system Ext(S)) can be obtained by integrating I (with respect to E) and another (formal)system U (with respect to V), necessarily in the interior (with respect to the exterior) of S.
Figure 1.7Generic examples of systems in the interior of (I) and the exterior (E) of a (formal) system S
In practice, placing this boundary between the exterior and the interior of a (real) system is in fact the first key act in modeling since it allows us to clearly define the system, something that is generally always difficult to do, in reality. We can also note that this distinction is at the heart of the categorization of architectural visions used in systemic analysis (see below), and notably the definition of the first architectural vision of a (real) system, called operational, that synthesizes the interactions of the system’s exterior with the system itself.
We are now equipped to introduce the notion of the architectural visions of a system. Keep in mind, these are concepts about modeling that therefore only refer to a real system, contrary to the previous definitions, which all had a common meaning that works for both formal and real systems.
DEFINITION 1.6.– Architectural visions: let S be a real system made by integrating a set C(S) of smaller, concrete systems. We can therefore introduce the three overall categories of models forming its architectural visions:
– an operational model of S (in short) is the part of a formal system constituting a model of the exterior of S;
– a functional model of S is the part of a formal system that is a non-organic model of S (see below);
– an organic model of S is the part of a formal system modeling S, obtained through the composition of formal systems modeling the concrete systems of C(S).
Figure 1.8Example of architectural visions for a real system
We can first note that Definition 1.6 is indeed consistent, since the existence of non-organic functional models is directly tied to the postulate of emergence (see section 1.2.3), which, let us recall, confirms that the mere knowledge of the concrete components of a system and their laws of interaction is never enough to describe the behavior of the integrated system resulting from their interconnection. This explains why there are still purely functional models of systems whose role is to clearly express the emergent functions that we would not be able to see at the organic level13.
Figure 1.9A universal framework for the architectural analysis of a real system
We now also understand why it is necessary to have three types of models to model a real system in practice: the operational vision captures the external point of view, while the functional and organic perspectives capture the internal point of view by respectively modeling the emergent behaviors on the one hand, and, on the other, the concrete constitution of the system being considered.
With this now elucidated, it is useful to underscore that the architectural visions play a key role in systems architecture: the first job of a systems architect will as matter of fact consist of classifying the modeling elements at hand, which most often, in practice, include various conceptual levels, according to the classification from Definition 1.6, in order to obtain homogeneous models, each capturing a very limited perspective.
1.3.2. Properties of a system
The first way of systemically analyzing a system consists of describing the properties that must be satisfied, which gives rise to the logical models describing the systems that these requirements constitute (which are typically used, in practice, as specification tools for writing requirement specifications in engineering).
DEFINITION 1.7.– Requirement: let S be a (formal) system. Any logical property (temporal or not) that can be expressed in the language of S, that is, by way of its inputs, outputs and states, can thus be called a requirement of system S.
To say that an airplane is safe, for example, is in essence the same as imposing a safety requirement upon the “airplane” system, affirming that there is no moment in time in which this system is in a state of “catastrophe” (which must naturally be defined precisely and integrated into the model of the airplane in advance in order to be able to express the previous requirement of safety).
We can now identify how this generic notion of a requirement overlaps with all the architectural perspectives defined in the previous section, which brings us to Definition 1.8.
DEFINITION 1.8.– Need, functional requirement and organic requirement: let S be a real system. We can thus say that a logical property is:
– a need if it is a requirement of an operational model of S;
– a functional requirement if it is a requirement of a functional model of S;
– an organic requirement if it is a requirement of an organic model of S.
These three concepts are fundamental since the entire architectural reasoning consists of starting from needs, that is, the properties expected by the exterior of the system (what the “clients” of the system want), in order to translate them into functional requirements (what the system must do), and then into organic requirements (how the system must concretely be made).
In practice, organizing the properties that appear empirically throughout the engineering process according to the categories in Definition 1.8 presents major difficulty. It is indeed very easy to identify properties that merrily blend the three architectural perspectives: from the point of view of the constructor of military vehicles, the property “soldiers must move around in a transport vehicle for troops that is painted in green” is thus not a need, nor a requirement of the “transport vehicle” system as it combines external elements (soldiers) and internal elements (the color of the vehicle). Architectural reasoning demands us to rewrite this property in the form of an organic requirement: “the vehicle must be the color green,” which then immediately raises the question of what the (unspoken) need of the soldiers was. We can easily understand with this example that a functional requirement for the vehicle is missing, namely, “the vehicle must be invisible,” which itself is derived directly from a very simple need that the soldiers have: “the soldiers must not die during operations!” By proceeding with this reasoning, we thus make explicit the role of the field of operations in the environment of the target transport system, which in turn lets us realize that the choice of green paint is perhaps well adapted to the wooded terrains of Europe, but surely much less so in the sands of the Gulf, where an ochre color or camouflage would be much more efficient in covering the primitive need of the soldiers, now made clearly explicit.
1.3.3. Descriptions of a system
The second way of analyzing a system systemically consists of explicitly describing its behavior in the form of symbolic descriptions using a (formal) ad hoc syntax or, in other words, making its “blueprint.”
The architectural perspectives introduced in Definition 1.5 thus let us posit the following definitions.
Figure 1.10Sample organization of real system descriptions
DEFINITION 1.9.– Operational, functional and organic descriptions: let S be a real system. We can thus say that a symbolic representation of this system is:
– an operational description if it is part of an operational model of S;
– a functional description if it is part of a functional model of S;
– an organic description if it is part of an organic model of S.
We should take note that the very definition of a (formal) system naturally allows us to organize each description of a system according to the following axes, which convey all of the possible components of such a (formal) model of the system:
a (static) representation listing states;
a (static) representation listing inputs/outputs;
a representation of the dynamics of the evolution of states;
a representation of the dynamics of the behavior of inputs/outputs.
For practical reasons, we usually group the representations in categories (1) and (3) into just one representation – in the form of a finite-state machine – focused on states, giving both their list and their evolution dynamic, and we break representation (4) into two representations, the first of which simply lists the components necessary for the second in a static manner, focused on modeling the behavior dynamic of the system. Figure 1.10 illustrates an example – by abstracting the representation of inputs/outputs – of this way of organizing the descriptions of a system.
1.3.4. Reference framework for system analysis
In summary, we have thus clearly shown that a real system can be analyzed according to the three angles given by its architectural perspectives (operational, functional and organic), its properties and its descriptions (see Figure 1.11).
If we also integrate the fact that a system additionally has a systemic hierarchy (its system levels, sub-systems, sub-sub-systems, etc.), we understand that a system is a fundamentally multidimensional object that is structurally difficult to analyze since we must understand not only each of its architectural components, but also the entirety of their relationships!
Figure 1.11The angles of analysis of a (real) system
Finally, we should note that all our considerations can be summarized in the architectural analysis cube presented in Figure 1.12, which provides a generic organization of a systemic model of a real system and therefore necessarily contains the reference framework of the systemic analysis (which consists of analyzing a real system according to the different axes of the cube).
Figure 1.12The cube of architectural analysis of (real) systems
1.4. Architecture of a system
1.4.1. Systemic perspective of the systems architecture process
In the previous section, we presented the universal structures that exist in all systems which, in particular, led us to the mode of universal organization for systemic models. We can likewise note that the problems in systemic conception also have a common, universal structure since they “simply” consist of making constructive proofs of theorems that (theoretically) all have the following form14.
THEOREM 1.1.– There exists a system S that satisfies a set B of needs.
Equation 1 – Universal structure of a statement of systemic conception.
We thus understand more easily why the existence of a universal identification and construction algorithm for systemic models, which we can call the systems architecture process, is not at all abnormal. It is this latter process that we will now quickly present in section 1.4.2.
Let us first note that the systems architecture process is the same as the functional perspective of the organization in charge of this process, in other words, the functional trace of an architectural conception system that can therefore be systemically analyzed (see Figure 1.13). This “strange cycle” – very characteristic of the reflexivity of systemics which can make use, like mathematics, of its own tools for studying its internal functioning – lets us use the reference framework of architectural analysis, introduced in the previous section, to describe the systems architecture process, as we will now do15.
Figure 1.13Systemic perspective of the architectural conception system
1.4.2. Architectural perspectives of the systems architecture process
As we underscored above, any method of systemic analysis first consists of identifying the environment of a system. In the case of an architectural conception system, it is none other than the environment of the engineering process itself, of which the systems architecture process is a component: the latter is typically formed of the company in which the process is deployed, its competitors and clients, the users, operators and suppliers it interacts with, and the regulations and technologies it must account for.
Performing an operational analysis of the architectural conception system thus means asking ourselves what the service that the systems architecture process provides its environment with is; recall simply that systems architecture seeks to master the conception and evolution projects of systems, respecting their cost, deadline, quality and performance constraints. Seen from the outside, the architectural conception system therefore has the principal objective of helping the actors in a project making or transforming a system to always act in a synchronized manner, the absolute condition for succeeding in any integration, by leaning on universal, exhaustive, coherent and shared models.
At the functional level, the activities of the systems architecture process are very simple to describe since they automatically derive from the reference framework of the systemic analysis, introduced in the previous section. These can indeed be separated naturally into the following activities:
– the architecture of a (real) system’s needs and requirements, with the objective of formalizing its functional and organic needs and requirements;
– the operational, functional and organic architecture of a (real) system, with the objective of building its operational, functional and organic models;
– verification and validation, which consist of moving up the cycle in order to ensure the real system actually satisfies its requirements and needs.
The key point that should be underscored here is that we can associate a generic process (that would of course be too long to describe here) to each of these architectural activities, which simultaneously allows for the universal method of system conception that we spoke of earlier to emerge, along with a “toolkit” of systems architecture16. It is also interesting to give the overall dynamic that exists between these different activities (see Figure 1.14). Finally, let us finish with the organic dimension of the architectural conception system. It is made up of two primary components:
– humans including, notably, the key character of the systems architect, who has a double role in managing the integration of the technical systems and human systems in their field of charge: building coherent interfaces within a technical system always in fact requires bringing the interested parties of these interfaces around to a unified vision of their system;
– the tools of the systems architecture process, which on the one hand include software tools for the engineering requirements and behavior modeling, based on description languages such as BPMN (Business Process Modeling Notation), UML (Unified Modeling Language) or SysML (System Modeling Language), and on the other hand, the conceptual tools introduced in section 1.3.3, not to mention common sense and heuristic rules, of course, as well as the good practices that come from experience17.
1.5. In conclusion
We hope that this summary has allowed the reader to better understand the stakes and issues involved in systemics. It naturally does not have the pretension of covering the entirety of this discipline and intentionally omits numerous very important subjects: systems dynamics, systems sizing and optimization, systems evolution trajectories, the conception of homogeneous families of systems, agile and collaborative approaches to systems development, systems governance, etc., which are covered in the previously mentioned book, Systems Architecture and Complexity, and the others mentioned throughout the following chapters and in the references. The world of systems is indeed a “continent” that forms a real scientific field for a science of systems18.
Systemics still however needs to be developed, necessarily through a profound interaction between theory and practice, despite realizations that are, even now, old – and unfortunately almost without follow-up – by the great fathers of the field such as Simon19 or von Bertalanffy20. Let us therefore hope that the systemic challenges that the world is beginning to face, with the financial crisis of 2008, then the much more profound one caused by the emergence of the Covid-19 virus, will finally allow the field to fully emerge21.
Figure 1.14Description of the functional dynamic of the architecture process of systems
Figure 1.15The role of a systems architect
Notes
1
Living systems in particular will not be considered in this chapter (see the Conclusion, however), which is restricted to engineered systems, in other words, artificial systems (as opposed to natural systems) designed by man, which already covers a vast spectrum, given that technical systems as well as organizational systems can fall into this conceptual category.
2
Not to mention the intrinsic limits of the physical and environmental resources of our planet that are no longer impossible to ignore (see Meadows, D.H., Meadows, D.L., Randers, J., Berhens III, W.W. (1971).
The Limits to Growth.
Universe Books, more well known under the name “The Club of Rome Report”).
3
The property of emergence cannot be understood, stricto sensu, in the context of Aristotle’s logic since the whole is greater than the sum of its parts.
4
We will use an electronic toothbrush as an elementary system to illustrate the systemic concepts in this chapter.
5
See Korzybski (1994).
Science and Sanity
. Institute of General Semantics, p. 58.
6
Modeled by a law of evolution of its internal variables, which we call “states” here.
7
In Appriou, A. (ed.) (2009).
Gestion de la complexité et de l’information dans les grands systèmes critiques.
CNRS Editions, 179–207. See also
Model-based Systems Architecting
, ISTE-Wiley, 2022.
8
A notable common error is to assume that a “sub-system” of a system (see
section 1.2.3
for more details) is not a system, which is naturally not the case (and which lets us apply the principles of systemic analysis to this level too).
9
We will not specify the notions of abstraction and concretization here, which should be taken in the sense of the theory of abstract interpretation (see, for example: Cousot, P., Cousot, R. (1996). Abstract interpretation
. Symposium on Models of Programming Languages and Computation, ACM Computing Surveys
, 28(2), 324–328, for more details on this subject).
10
The high-level models of integrated systems also often being consequently almost inexistent, in practice.
11
That is, a system whose sets of inputs and outputs are empty, which is the same as saying that there are no inputs or outputs.
12
We can in fact reason by considering that Proxima Centauri has no influence on most earthbound engineered systems.
13
In order to understand this phenomenon well, let us take the example of a car whose (high-level) systemic constitutive components are the undercarriage, the motor, the passenger compartment, the contact with the ground and the built-in electronics. The interaction of these different components is typically sufficient for the performance of functions such as the detection of obstacles, which requires the cooperation of a radar (placed in the undercarriage), an accelerometer (part of the built-in electronics), an illuminated indicator (placed in the passenger compartment) and even the contact with the ground or the motor if we want to act upon the brakes and/or reduce the engine torque when an obstacle is too close to a car. Such a function – called transversal – would clearly be difficult to capture in a purely organic model of the car, where we see exchanged flows between the different components of the vehicle without being able to explain their overall logical structure. Only a functional model of the whole car can therefore capture the semantics of such a transversal function.
14
That is, by concretely building a system that verifies the theorem that needs to be proven.
15
See the book Hofstadter, D.R. (1979).
Gödel, Escher, Bach: An Eternal Golden Braid
, Basic Books, which also exists in a French translation.
16
See Printz (2019), which exists in an English translation.
17
On BPMN, see White, S.A. and Miers, D. (2008).
BPMN Modeling and Reference Guide, Understanding and Using BPMN.
Future Strategies, as well as the general bibliography. On UML, see Booch, G., Jacobson, I., Rumbaugh, J. (2004).
The Unified Modeling Language Reference Manual
, 2nd edition. Addison-Wesley, as well as the general bibliography. On SysML, see Friedenthal, S., Moore, A.C., Steiner, R. (2012).
A Practical Guide to SysML: the Systems Modeling Language
. Morgan Kaufmann OMG Press.
18
To use the expression that Marcel Paul Schützenberger surely would not have rejected (founding “father” of the French school of theoretical computer science, with Maurice Nivat).
19
See Simon, H. (1962). The architecture of complexity.
Proceedings of the American Philosophica
, 106(6), 467–482, as well as the general bibliography.
20
See von Bertalanffy, K.L. (1968–1976).
General System Theory: Foundations, Development, Applications
, George Braziller, a French translation has been published with Dunod,
Théorie générale des systèmes
, 1973. For a detailed study of the historical aspects, see the thesis Pouvreau, D. (2013). “Une histoire de la ‘systémologie générale’ de Ludwig Bertalanffy – Généalogie, genèse, actualisation et postérité d’un projet herméneutique”, EHESS, March.
21
See De Weck, O., Krob, D., Lefei, L., Lui Pao, C., Rauzy, A., Zhang, X. (2020). Handling the COVID-19 crisis: Towards an agile model-based systems approach.
Systems Engineering
, 23(5), 656–670.
2Natural Functions
2.1. The notion of energetic transducers, revisited
In the systems literature in general, and in the aforementioned book, System Architecture and Complexity: Contribution of Systems of Systems to Systems Thinking, we often use the terms “transducer” and/or “transduction”, which come from physics, and more specifically, from electronics. They are also used in linguistics, often in relation to the more familiar term “translation”, as well as in biology for organelles such as ribosomes, which “translate” the genetic information in DNA into amino acids, which in turn make up the proteins that are the basic building blocks of the living.
It is important to clearly grasp the nuance in transduction/translation, as well as the way they are used in systemics and in this book.
A transducer is a physical or physio-chemical system (but we can also speak of a transducer component or element, depending on the level of abstraction in which we find ourselves) that provides a useful physical measure (i.e. a finalized measure with a precise objective) as an exit signal in response to another specified physical measure, such as an entry signal. Anyone who handles a touchscreen device makes use of transducers.
In theory, transduction is a phenomenon of synchronous energetic conversion that conserves the information carried by the entering physical measure. It is a process for which we could establish a conversion table, “Entry × Exit”, depending on the physical phenomena implemented: mechanics, optics, chemical, electric, magnetic and thermal. The diagram for the principle of transduction is presented in Figure 2.1.
Figure 2.1Transduction chain
This is also a “machine”, in the thermodynamic sense of the term, which functions with a certain return, notwithstanding the unexpected events which can arise in the process of transduction. Historically, these have been mechanical phenomena that were the first to be used (levers, sloping surfaces, cams, bearings, exhausts, etc.), as well as the hydraulic phenomena that the Greeks and Romans mastered relatively well: sluice gates, siphons, aqueducts, clepsydras, etc. People say, but these are theories, that the Egyptians used a very particular fluid, the sand of the desert, to lock the tombs of their pharaohs. Indeed, we know that in certain conditions, dry sand acts like an incompressible fluid that, like real fluids, does not present resistance to slicing, hence the efficiency of sluice gates.
REMARK 2.1.– The physics of sand piles is quite interesting, as pointed out by the physicist Per Bak in his book How Nature Works (Copernicus, 1996); see also La matière en désordre, by E. Guyon et al. (CNRS Editions, 2014).
The first widely available transducers were the microphones and phonographs of our great grandparents at the end of the 19th century. The transduction chain they contained was as follows: a modulated mechanical groove (1D, then 2D) sculpted in wax (then vinyl) + a reading needle made of steel → mechanical vibrations + acoustic membrane/cone → amplified audible sound vibrations (waves of pressure) → hearing; and the inverse chain had a microphone to sculpt the wax.
In a four-stroke combustion engine, the chemical/thermal energy first transforms into discontinuous mechanical energy following the combustion – a series of shocks – and then, with the help of a shock-absorbing mechanism, into continuous mechanical torque on the driving wheels of the vehicle.
