From each software component, we derived a twin that behaves non-functionally the same as its original. This already allows us to examine individual functions.

In a real software system, several of these components are distributed across different processes and make use of operating system services. It is therefore not sufficient to simply add up the load and energy demand of the individual components. Instead, we want to integrate the twins into a real system. This system can then be quickly modified and controlled. For example, the operating system can be swapped out to try a better option.

Two tasks are central to this: the OS layer and the middleware layer.

The OS layer primarily decides which process or which task derived from twins may run at which time. In most cases, for an OEM, the operating system (OS) is already a generated subsystem that only needs to be configured. It must therefore be determined which twin belongs to which process, and what priority and invocation frequency this process receives. The scheduling of the original system can, of course, be reused – or a new one can be designed. The crucial point is only that interacting twins are invoked in time with one another. These requirements are, for example, captured in the system through event chains.

The middleware layer (e.g. AUTOSAR RTE) organises system-wide communication between the individual twins. It ensures that the components do not need to know the exact memory locations of the signals to be exchanged, but instead only need to call a function that returns the respective signal. It is therefore quite simple to exchange communication partners – provided they call the correct middleware functions. The communication needs of the twins are also stored in their LPDL (Load Profile Description Language) model, specifying which signals each component provides or reads. Middleware functions can thus be generated easily.

In addition to these central tasks, further system-specific factors can of course be integrated, such as efficient memory utilisation.

Once integrated into the system, the twins not only reproduce their non-functional behaviour, but depending on their communication modes, also fill the system level with representative loads – without having to functionally interact with each other. This reduces dependencies within the system, which in turn benefits fast and smooth integration.