For cloud operators, digital twins are a very important building block in the functional portfolio, offering huge growth potential with high customer loyalty. The leading US companies in this area, Amazon (AWS IoT TwinMaker), IBM (Digital Twin Exchange), Microsoft (Azure Digital Twin) and Oracle (IoT Digital Twin), therefore see numerous potential uses for the virtual representation of physical objects and systems. This is primarily due to the wide range of possible applications and the associated market potential. After all, this methodology can be used to create digital models of entire environments. Such environments can be individual drive elements, vehicles and machines, buildings or production processes, but also complete factories, factory premises, complex energy supply networks, railroad lines, sports stadiums and even entire cities (smart city). Much larger interconnected systems are also possible. It can be deduced from this that there are also different digital twins with regard to the respective application.

Groups of twin instances

IBM took up the topic of twins very early on and therefore already has extensive practical experience and now differentiates between four different twin categories with the current state of the art:

• Component twins/partial twins: these form the basic unit - digital twin for an entity - of complex digital twins and usually represent a functional component, such as the electric motor or frequency converter of a machine.
• Asset twins: An interconnected system of at least two component twins that interact with each other, such as the functional components of a machine drive train. Relatively large amounts of data are generated here, which can be used to examine the interactions and obtain usable information.
• System or unit twins: In this integration stage, asset twins are combined to form a functioning overall system that can be represented as a star-shaped graph, for example. Such a digital twin for a machine transparently reflects the communication and interactions between the assets, for example, and is generally suitable for automated optimization decisions or cognitive capabilities.
• Process twins: This category forms the macro level of detail for the collaboration of subsystems, for example for a complete production plant. In other words: a digital twin for a scenario. At this level, complex questions can be answered with the help of a digital twin: Are all subsystems synchronized? Do all systems have maximum efficiency or do delays in the system have an impact on other systems? Such scenario twins help to influence overall effectiveness and productivity.

The data interfaces of an IoT hardware for a component twin can be modeled with a description language such as the Digital Twin Definition Language (DTDL): (1) A JSON object serves as a DTDL interface description. (2) The "telemetry" definition can be extended via a "unit" property with a semantic type annotation. (3) The IoT sensor data stream on the output side contains a data object that matches the model. The aim of using DTDL is IoT data plug-and-play to enable complex projects.

© SSV Software Systems

In practice, a single physical object can be used for several twin variants. For example, the US car manufacturer Ford uses a total of seven different digital twins for every vehicle it produces. The range of applications extends from vehicle design through production and operation to the customer experience.

In the German Edge Cloud environment, a working group has formed that aims to advance digitalization in the field of industrial production with a network of three twins: a plant twin - i.e. a system twin - serves as a repository for all technical and electrical data, circuit and wiring diagrams, functional descriptions of components and the entire plant itself, as well as 3D models of the highest possible quality. A product twin is used as the second twin variant. It enables product configuration and is used from the customer's request through to delivery. It is created long before the actual product is manufactured and also contains 3D models. With this twin instance, sales partners and customers can simulate and test the product functions. These 3D models can be used to check form, fit and function (FFF). The third member of the group is the production twin. This process twin supports the product manufacturer in optimizing productivity by linking and evaluating sensor data from ongoing production operations with master data.

Suitable tools required

The views and activities of cloud providers suggest that an application with digital twins can become a highly complex structure. In practice, it is not just a matter of linking two or three component twins to form an overall data technology system and using it to obtain information, make decisions and take the resulting operational actions. Rather, applications with several thousand or even millions of individual digital twins are realistic, such as in the smart city example. In this respect, there is a need for universal and high-quality development tools, architecture concepts and data structures that do not create any (cloud) vendor lock-in.