0.2 CESAM: a Framework focused on Complex Integrated Systems
A second key point to stress is that CESAMES Systems Architecting Method (CESAM) is fundamentally a complex integrated systems-oriented framework. This means that CESAM is especially dedicated and adapted to the architecting and modelling of complex systems, that is to say – in equivalent terms – of non-homogeneous systems which result from an integration process. To be more specific, let us first recall that system integration is the fundamental mechanism1 Integration is thus an operator between systems that maps a series of systems into another new system. It is interesting to point out that most of the existing system “definitions” which can be found in the systems engineering literature (see for instance [30], [42], [44], [57], [61], [62], [71] or [74]) are defining systems as the result of an application of the integration operator. From a mathematical perspective, this gives unfortunately rise to inconsistent definitions since the set on which acts this operator is never defined. However all these “definitions” are clearly expressing a real pragmatic dimension of all systems, which is rigorously captured in our framework by the notion of integration as provided in Definition 0. that allows in practice to build a new system from other smaller systems (typically of hardware, software or “humanware” nature), by organizing them so that the integrated system can accomplish – within a given environment – its missions (see for instance Figure 5). For the sake of completeness, a more formal definition of this key mechanism is provided below.
Definition 0.5 – Integration – Let S1, … , SN be a set of N (formal) systems. One says then that a (formal) system S is the result of the integration of these systems if there exists on one side a (formal) system C obtained by composition of S1, …, SN and on the other side dual abstraction and concretization operators2 In order to avoid mathematical technicity, we will not define here the notions of abstraction and concretization that shall be considered in the meaning of the theory of abstract interpretation (see for instance [25] for more details on this topic). that allow to express:
- the system S as an abstraction of the system C,
- the system C as a concretization of the system S.
Figure 4 – Formal integration of formal systems
This somewhat technical definition has for fundamental purpose to position integration as a different mechanism from a simple composition of models in order to try to capture structurally emergence in our approach. The previous Definition 0.5 indeed clearly shows that the description of an integrated high level system, obtained through interconnection with other systems, requires having:
- models of each system contributing to the integrated high level system,
- a new high level model, specific to that integrated system.
In other words, the mere knowledge of the models of the components of a system is never sufficient to model this system! This modelling postulate can be seen as the direct translation of the universal phenomenon of emergence which is always a mechanical consequence of integration: an integrated system will indeed always have emerging properties, that is to say specific properties that cannot be neither found in its components, nor deduced from the properties of its components.
This emergence postulate can be observed on all simple integrated systems of day-to-day life. Let us consider for instance a wall formed solely of bricks (without mortar to bind them) for the sake of simplicity. A simple systemic model of a brick can then be characterized by:
- a functional behavior consisting on one hand in providing reaction forces when mechanical action forces are acting on the brick and on the other hand in absorbing the light rays,
- an internal behavior provided by three invariant states “length, width, height”.
By composing such brick models, a wall will just be a network of bricks connected by mechanical action/reaction forces. But it will be difficult to get anything else from such a wall than a resulting functional behavior consisting in absorbing the rays of light. This is however clearly not the usual behavior of a wall, since we want to make account the existing holes in the walls (for the windows) that should just let the light pass! Note also that it is difficult – and probably vain – to try to express the form of a wall (which is one of its typical internal state) depending on the lengths, widths and heights of the bricks that compose it. All these facts call for the obvious need of creating a dedicated systemic model, more abstract, to specifically model a wall.
Figure 5 – Example of an integrated system: the used electronic toothbrush
These considerations may appear to be common sense, if not naive, but we unfortunately noticed that their consequences are usually not understood, which directly causes lots of non-quality issues as observed on many modern complex engineered systems. Most engineers & managers indeed still continue thinking that mastering the components of an integrated system is sufficient to master the system as a whole. However the very nature of the integration mechanism imposes not to have only components responsible when one has to design an integrated system: it is key to also have somebody specifically in charge of the integrative high-level model of the considered system, that is to say a systems architect, who does unfortunately often not exist3As a consequence, high level models of integrated systems are also often non-existent in practice … in most industrial organizations, as strange it may sounds when one is aware of the underlying systemic fundamentals!
Note also that emergence obliges to privilege a top-down design strategy – rather than a bottom-up approach4This is unfortunately still the most common design strategy in the industry for integrated systems … – when one deals with integrated systems. As a matter of fact, it is indeed not possible to predict the emergent properties that result from integration: any bottom-up design strategy will thus statistically create numerous undesirable emergent properties that will be difficult to master. In such a context, the only possible efficient design strategy is to start by imposing the expected properties of the integrated system, and then deriving from them the properties required from its components, which naturally lead to a top-down design strategy.
Finally, note that the integration mechanism naturally hierarchizes systems, while giving a recursive dimension to systemic analysis. Engineered systems are indeed obtained in practice by a number of successive systems integrations: each integrated system thus generates in this way an integration hierarchy, which is also an abstraction hierarchy due to the nature of integration, called the systemic hierarchy of the initial system. This allows in particular to speak about the system, sub-systems, subsystems, etc. levels (that are also called sometimes “layers” or “tiers”) of any integrated system.
NEXT PAGETABLE OF CONTENTS
References
[25] Cousot P., Cousot R., Abstract Interpretation, Symposium on Models of Programming Languages and Computation, ACM Computing Surveys, 28(2):324-328, June 1996
[30] de Weck O.L., Roos D., Magee C.L., Engineering systems – Meeting human needs in a complex technological world, The MIT Press, 2011
[42] IEEE, IEEE 1220-2005 – Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, 2005
[44] ISO/IEC/IEEE, ISO/IEC/IEEE 15288:2015 – Systems and software engineering — System life cycle processes, May 2015
[57] Maier M.W., Rechtin E., The art of systems architecting, CRC Press, 2002
[61] Meinadier J.P., Ingénierie et intégration de systèmes, Lavoisier, 1998
[62] Meinadier J.P., Le métier d’intégration de systèmes, Lavoisier, 2002
[71] Sage A.P., Armstrong J.E., Introduction to systems engineering, Wiley, 2000
[74] Sillitto H., Architecting systems – Concepts, principles and practice, College Publications, 2014