An introduction to "complex systems"

// Systems / Example / Systemic approach / Black box modelling / Complex systems modelling / Architecture & Design //
>> What is a (complex) system ?

In our acception, a system is "an object which can be broken down into a collection of interrelated elements working together to perform a function". Conversely, it is possible to integrate a set of systems, i.e to build a greater system, by making those systems work together.
From the outside (called the environment of the system), a system can be understood as a "black box" performing a function from its inputs X to its outputs Y. This function depends on an internal state Q (which caracterizes the current state of the system).

In its environment, a system can therefore be represented as follows :
At this point, it is important to understand that the word "system" refers at both a real object and an abstract description of this object.

The complexity of a system will mainly come from two aspects:

• integration of components: there are many interrelations between a possibly huge number of components, and there are recursive levels of integration
• heterogeneity of components: several specialized fields are involved in the design of a complex system, making it difficult to keep a unified vision of this system and to manage its design.

>> Example

A basic example of a system may be an individual, John, in the context of its work. In our model (which is of course restrictive, as every model, the important thing being that this model is relevant for its intended use), John has two states ("normal" or "tired"). He can receive requests from its colleagues (he must answer them by "Yes" or "No") and can also receive energy (when eating for example, what makes him normal if he was tired). Lastly, John can become tired after receiving too many requests from its colleagues. John is a very helpful guy always ready to help people, but when he is tired, he only helps urgent requests.
In the scope of our story, John can be viewed as a system such that :

• the functional behavior of John is defined by :
  • when John is tired, f("non urgent request") = "No" and f("urgent request") = "Yes"
  • when John is normal, f("any request") = "Yes"
• the states evolution of John is defined by :
  • when John is normal, Q("too many requests") = "tired" and Q("any other event") = "normal"
  • when John is tired, Q("receiving energy") = "normal" and Q("any other event") = "tired"

>> The systemic approach

The systemic approach consists in

• considering all objects as systems (and the elements obtained when breaking down a system are themselves systems, often called subsystems), and explaining behaviors only with systems (as we have illustrated with the example of John)
• studying every system within a greater system including its environment
• considering a system through its whole lifecycle to step back.

Thus, the systemic approach explains the world by modeling all the considered objects as systems (possibly resuting from an integration of smaller subsystems), while stepping back in space and time.

To avoid confusion between real objects and models, we will call :

• concrete system any "real" object that can be modelled as a system (informal point of view)
• system any abstract object fulfilling the definition of a system introduced above (semi-formal point of view)
• model of a system any mathematical object representing a system (formal point of view)

To better understand those differences, we can explain it on the case of John :

• in our scenario, we have explained how to describe John as a system
• therefore, John as an individual is a concrete system
• but we could have also proposed a mathematical modelling of John seen as a system, what would imply to define a mathematical framework in which it would be possible to define functions and states.

These definitions highlight the fact that generally, a system refers to a semi-formal and abstract representation of a "real" (existing or to be created) object, viewed through a systemic approach (therefore not anymore corresponding to the "real" object, but not yet modelled as a mathematical object).


>> Modelling the black box

The behavior of a system can be modelled as a couple of two elements :

• the functional behavior (describing the function of the system in a given state)
• the states evolution (describing how the internal state of the system changes with time and inputs)

In theoretical computer science, many different types of models exist that may be suitable for modelling a system as a black box : Mealy machines, Moore machines or Turing machines are well-known examples.
The first issue with those models is related to time. These machines doesn't take into account any time, but only steps without specifying their duration, what makes it impossible, for example, to define meaningfully the composition of several of these machines. Another problem is that they only consider discrete time, when a continuous time may be necessary for systems having continuous behaviors. However, several models have already attempted to fix this issue, like for instance : hybrid models, or non-standard computing machines (using non-standard analysis, see Krob & Bliudze).
Another issue is that the deterministic behavior may be too restrictive for explaining all the behaviors of real world objects. It may be therefore useful to introduce probabilistic behaviors (for the states or the functions).

It brings us to a first challenge : define a "black box" model of systems representing them as a new kind of computing timed-machines, and taking into account expected properties for modelling a realistic system in the tradition of theoretical computer science :

• describing the temporal behavior of the system, and allowing to use both discrete and continuous times
• manipulating flows for the inputs and outputs of the system (for modelling material, energetical or informational exchanges)
• having a "computable" description of the states and functions (so that it will be possible to place us in the line of the algorithmic complexity theory)
• making it possible to connect together two systems or to feedback the output of one system on its input (so that it will be possible to define later the integration of such systems)
• having the possibility to take into account probabilistic behaviors of states and functions

>> Towards a meaningful modelling of complex systems

We have identified a first challenge, namely defining a model suitable for systems viewed as black boxes. However, the complexity makes it difficult for human beings, from a practical point of view, to handle those systems, for the reasons described above, and called complexity.
We therefore need to extend this blackbox model (however very useful for defining computability for example), so that it will be possible to use this new model on complex systems, and to reason on this model to understand the system. The challenge is exactly the same than going from Turing machines (a low-level mechanical modelling) to programming languages (which allow to define in a meaningful way behaviors in the end converted into Turing-like behaviors, and therefore equivalent from the point of view of computability).

Our second challenge is to define a meaningful and practical model of complex systems :

• extending the black-box model of systems and defining a composition operator allowing to make systems work together by interconnecting them
• enabling to have an internal structure on systems, so that it is possible to remember the internal structure of a system (it is no more a black box)
• being able to only partially specify the behavior of a system (consequently, a system cannot generally be mecanically "concretized" into a unique lower-level system, and design choices will be necessary to do so)
• being able to describe a same system at different abstraction levels (to describe its elements and behaviors at a meaningful level) and supporting reasoning about the structural properties of a system (by working on meaningful states, events, datas and functions)

The main feature of this model is to introduce an operator called abstraction, which allows to change the view on this system (it will also account for the "interfaces", i.e. a lower-level implicit system induced when defining a connection between two systems). In this context, what is generally called integration of systems is the fact of using abstraction and composition operators to build a system from smaller subsystems.
Such a process to build a system defines what we call the architecture of a system.


>> "Systems Architecture" for the design of complex systems

To embrace, and later tame, the complexity in the design of a system, it is necessary to break the system down into smaller subsystems that can be integrated to build the target system. The process of breaking down a system when designing (or modelling, for an existing system) it will face two majors difficulties :

• dealing with complication and underspecification -> the high-level initial description of the system is not at the same level of details as the one necessary for building it, so it will be necessary to understand the relevant behavior necessary for the subsystems so that the behavior of the system resulting from the integration will match the targeted (and not fully specified) system
• dealing with emergence -> some behaviors of the system will be obtained by emergence of subsystems behaviors, so it won't be a mechanical work to find the subsystems. Moreover, the integration of those subsystems may result in unexpected and undersirable emergent behaviors of the system that must be identified and mastered.

Therefore, designing a system involves more than using models : it is also a method to progressively understand, and create/model the right behaviors at the systems involved. But the design, generally done by a team, will also involve tools and practices (individual and collective) in order to be as effective and relevant as possible. All those points (models, method, tools, practices), together with architecture principles and concepts, are constituting a body of knowledge called Systems Architecture.

Our third challenge will be to provide mathematical foundations for Systems Architecture, and to make links between Systems Architecture and the models of complex systems defined through the second challenge.

***
You can also visit my homepage for more information on my research on Systems Architecture.