The illusion of a simple system

Everyone is talking about increasing complexity, which manifests itself in the number of parts, among other things. But then products like the Citroen Ami come onto the market, a seemingly simple system that supposedly consists of only 250 individual parts. How is this possible? The answer is quite obvious, each of the individual parts is itself highly complex. This trend - the installation of complex individual parts - has many advantages, but also harbors dangers.

Before I go into detail, I would like to draw your attention to an ongoing GfSE survey on this topic:

Prozesswerk GmbH, together with the Society for Systems Engineering e.V. developed a questionnaire on the company-wide introduction of systems engineering. Back in 2018, they surveyed a total of 176 participants from various sectors, such as the automotive industry, aerospace, agricultural machinery and automation technology, regarding the status of the introduction of systems engineering in companies. (Download the 2018 study).

Also This year there is a survey. The results will be published here on the blog, among other places. In this respect, I would like to thank all readers for their active participation.

Modular systems are not a matter of course

Especially with industrial products that have long life cycles, a company will not launch a new product line lightly. Here, holistic systems engineering is often still lacking if existing products have simply been slightly adapted from customer to customer. It can happen that today, even with "new developments", we only encounter adapted designs from the 1970s.

A good example of this is Boeing, which has 737 has developed incrementally from the 1960s to the present day. Among other things, the deficits in SE and the lack of modularity have contributed to the serious accidents involving the 737-MAX with. The problems were caused - ironically - by one component, the engines. The new, efficient engines could not be mounted in the optimum position under the wings, as there was not enough space to the ground. This interface problem led to a series of design decisions that ultimately resulted in two fatal accidents.

Even if it is not always applied, today we have the know-how to develop modular, maintainable and expandable systems. After all, this is exactly what systems engineering is for. Various tactics support the aspect of modularity. These include clean Interfaces and Encapsulation.

Citroën Ami: A car made of 250 parts

e-engine

A current example is the Citroën Ami, which consists of just 250 parts. It is unclear what exactly a "part" is. I assume, for example, that the electric motor is regarded as a "part". However, the motor consists of many individual parts. But from a systems engineering point of view, the motor is a monolithic part: if it no longer works, it is replaced as a unit. Nevertheless, behind the motor hides another complex system, which probably consists of hundreds of parts. Olivier de Weck has shown very clearly in his work that the complexity of a system is independent of how we cut it.

Leaking components

This approach becomes problematic if the components are not real "black boxes". In other words, when implementation details from the system leak out beyond the system boundaries. An example from everyday life is the classic light bulb with an E27 socket, a really simple system. The light bulb has a single function, to illuminate. The light bulb has a clearly defined physical interface, the base with the corresponding thread and electrical contacts. Finally, we have the electrical interface, i.e. voltage, power, etc. If I now screw a non-dimmable LED light bulb into a lamp that works with a classic dimmer, the overall system does not work as expected. We can argue about who is to blame here, but: an implementation detail (LED) impairs the overall function, although the installed system (light bulb) should actually be a "black box".

The LED on the dimmer is a harmless example. In practice, unexpected and sometimes dangerous side effects can occur, especially in complex systems, if a replaceable component turns out to be not so replaceable after all.

It is not only functional safety that is a problem here, but also the Attack security. An insecure component, for example in a network router or smartphone, can compromise the entire system. On the ECS 2018 this topic was hotly debated in the context of IoT devices. One possible solution (at least for software) is the signing of components.

What to do?

Components are a great thing and make our lives much easier. In this respect, we are on the right track. MBSE is one (of several) enablers for component-based work. It would be welcome if the black box specification of components were available in a standardized, electronically readable format. One possible solution is the SpecIF formatto name just one.

But it is even more important to work defensively with components: We must not expect a component to behave correctly. The system must softly intercept incorrect component behavior. This in turn means that extensive testing during integration is not enough: the correct behavior must be checked at runtime and the overall system must be protected against the incorrect behavior of a component.

But that is a small price to pay compared to the many advantages that components give us. That's why I would like to see more complex products on the market that give us the illusion of a simple system due to the small number of parts.

Image source: GE Aviation Media Assets