Operating Systems will Empower Systems Engineering

Oct 19, 2020
Dr. Thomas Kamps

(The original version of this article was published on LinkedIn.)

In my last article, I talked about the challenges of manufacturers seen from the perspective of mobility service-driven businesses. The latter are widely seen as promising better profits and are an opportunity to distinguish oneself in an increasingly competitive market. That is why I assumed that the way product development takes place will change significantly in the future. In this article, I focus on the impact of operating systems to cope with the complexity imposed by services and solutions. I argue that the challenges imposed by these new developments will require the digital twin to reach over three dimensions: disciplines, lifecycle, and supply chain. This presupposes a holistic representation of a digital twin which can be provided by employing analytics-driven computation of knowledge graphs out of the brown field data.

OS-Based Product Architecture

The increased complexity caused by new service- and solution-based offerings requires the introduction of new operating systems. The intention is to prevent this complexity from directly affecting the mechatronic system, which would collapse under this additional load. Technically, an intermediate layer needs to act as a broker between the world of software and the world of mechatronics. This is crucial because it allows a decoupling of the mechatronics world from the services and solution world. It relieves the mechatronics world from the complexity of the services by introducing an abstract OS layer with well-defined software-based system service interfaces connecting to the mechatronics components. In the same process, a simplification of the mechatronics world takes place. Like the operating system of a computer, an automotive operating system is a software system that manages computer hardware, software resources, and provides common services for computer programs that are used in a vehicle. And this is what centralized operating systems as we know them from computers and mobile devices are well designed for. The OS reorganizes the functionality of today’s manifold communication bus components and on-board electronics systems so that a uniform management of the mechatronics world becomes easier as well.

Product Architecture_OS_Kamps
Figure 1: The change of product architecture over time and its relationship to customer requirements as well as OEM services and solutions. This architecture is quite general and not at all limited to automotive OEMs.

The development of the product architecture over time is depicted in Figure 1. For the sake of simplicity, I distinguish only three historical phases: yesterday, the customer required a mechatronic system plus applications (e.g., different hardwired modes of driving, built-in navigation service). The customer had to take care of the mobility services himself (e.g. download new maps to update the navigation system, take the car to the workshop for inspections). Today, we have a hybrid system, the customer requires services and the OEM provides specific services (e.g., financial services or flashing services for on-board entertainment) whereas the customer still has to take care of most of his mobility services (e.g., organizing trips). Tomorrow, the customer requires high-end services and solutions like autonomous driving or outsourced fleet management for corporate customers and the OEM might act as a service and solution provider (e.g., “reach now”, former [1] “moovel”, [2] daimler lkw).

Technology Stack vs. Business Models

However, it is important not to confuse the technological aspects of the system disciplines with the business aspects of the offerings. Technology is used to realize the business models. Figure 2 contrasts both systems and service disciplines along a time scale. A future development will be the integration of mobility solutions in smart cities. Corwin and Pankratz [3] of Deloitte as well as Guo and Hai [4] have given an interesting account on future urban development. They describe a mobility operating system as a platform based on three dimensions of maturity: geography, transportation assets and modes as well as capabilities. [5] Keupp of Boston Consulting Group describe how mobility platforms connect end users with different transportation operators.

Technology Stack vs Business Models_Operating Systems_Kamps
Figure 2: Technology Stack vs Business Models

Focus on Business Service Portfolios Requires Coherent Business Data Along the Product Lifecycle and Beyond

The major impact of this development is that OEMs focus their development strategies on the service portfolio they want to provide to their customers. This makes software development much more important than before. It even seems to become the predominant discipline. What is the impact of business services on the product lifecycle? As outlined above, complexity is determined by the service level and goes beyond what we have seen so far, even if electrification makes the technical system below the operating system less complex. Hence, systems engineering, and intelligent front loading become even more important. On top of that, new business services like autonomous driving impose liability and burden of proof to the OEM. Thus, powerful traceability functions are needed, not only to cover the product lifecycle but also the supply chain. The interdependencies between these three dimensions (see Figure 3) can in a natural way be represented by means of a knowledge graph. In a brown field the latter must be computed from data residing in the authoring system. This, in turn, requires application of sophisticated data analytics methods. Matthias Ahrens cites an article by Peter Louis and Ralf Russ of Siemens see data analytics as a vehicle to combine data science and engineering

Successful implementation requires systematic procedures for managing and analyzing data, but today such procedures are not covered in the PLM processes.

As our understanding of the digital twin is holistic, we must even go beyond the disciplines. We claim that the total potential of the digital twin can only be leveraged if we link up the product lifecycle and the supply chain in addition to the systems dimension. Only then it is possible to realize new business models based on services (connected use cases) and increase quality as well as effectivity and efficiency. In case of brown field IT landscapes, data linking may even be a very smart tool to migrate from today’s world into tomorrow’s world because you can catch two birds with one stone. Improve business processes today and be prepared for the service-driven business of tomorrow.


To conclude, systems engineering will face never seen challenges from factors which have not existed in the past. Systems engineering as a holistic, interdisciplinary management method needs powerful tools to grapple with these challenges. An important one is related to efficient information provision for all roles along the lifecycles involved, to be able to walk up and down the information chains along systems either by humans or machines. This view of the digital twin as a holistic entity reaching across internal processes and even beyond can only be achieved by using the most natural way of representing connectivity along the lifecycles: the knowledge graphs. They are the technological answer to the holistic challenge which systems engineering is confronted with. Knowledge graphs guarantee connected data across the lifecycle in this way, provide the needed business context. Starting from the brown field, OEMs might use knowledge graphs to kill two birds with one stone: linking up mechatronics data assets to improve business processes during the transition time (from the current system architecture to the new one) and using the resulting knowledge graphs to connect with the service and application data above the operating system.

See also:

  1. New OEMs Business Models Change Product Development from Head to Toe
  2. Does conceptional confusion lead to a search for a new label for PLM?
  3. Linked Data Connectivity – Graphs are the Crux of the Biscuit




[3] Corwin, Scott & Pankratz, Derek:

[4] Guo, Xiaolei & Yang, Hai: A Pareto improvement is a change that leaves no party worse off. For an application to mobility, see Yang Liu, Xiaolei Guo, and Hai Yang, “Pareto-improving and revenue-neutral congestion pricing schemes in two-mode traffic networks,” Netnomics 10, no. 1 (2009): pp. 123–40. View in article

[5] Keupp, Dominik, Lang, Nikolaus, Egloff, Camille & Hagenmaier, Markus:

[6] Louis, Peter & Russ, Ralf: How to develop digital products and solutions for industrial environments?, in Data Science, Insights, Main Category, Use Case, Use Cases /by Siemens Advanta Consulting, September 18, 2020

Ihr Ansprechpartner


Termin vereinbarenMake an appointment


Ihr Ansprechpartner

Further Information
Weitere Informationen