Operating Systems will Empower Systems Engineering
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.
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 et.al. of Boston Consulting Group describe how mobility platforms connect end users with different transportation operators.
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.
Conclusions
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:
