Digital Twins 2.2

Various definitions of digital twins are in use. Here, we condense these definitions into an innovative one that not only allows simulations but various other forms of uses. An earlier version of this text is based on [DMR+20], [BMR+22], and [BBD+21b]. See also our topic discussion on Digital Twins.

Rationale for this Definition of a Digital Twin

• We originally published in [DMR+20] a first version but updated it to this version after discussions on a Dagstuhl seminar on DTs and further meetings, such as the Modellierung’23.

• Because digital twins (DT) are currently a hot topic that promises a variety of improvements for the development and operations of physical systems, there are also a lot of different definitions. We felt it necessary to come up with the above definition to clarify our understanding of DTs.

• One major difference is that we do not only understand DT as a virtual decal of the physical system during development but also as a software system that actively accompanies the physical system during its operation. The digital twin collects, keeps, aggregates, and uses data in the form of digital shadows and it provides useful information and forms of active software services to users and connects with other systems.

• We use the term “original system” in a wider sense, not only focusing on physical, engineered systems but also including natural systems, biological systems, civil structures, and (immaterial) processes or workflows executed by humans, robots, and/or computers. We can also envision use cases for a digital twin of a pure software system. Note, we sometimes also use the commonly applied terms “physical twin”, “physical system”, or “actual system” instead of “original system”.

• A “digital companion” is actually a very good name for what we envision. It is used only in medicine for the digital twin of a human being (i.e. the patients).

• A digital twin needs to know many things about its physical twin. This form of information can only be provided when the engineering documents, that means the development models, can be reused and transformed into a productive digital twin. For example, a structure model helps to understand where sensors are located and thus provides the meta-information for the sensor data in the digital shadows. We thus explicitly added models as constituents for digital twins.

• As a consequence, digital twins share some characteristics with models. Below, we take a deeper look at the similarities and differences between these two constructs.

• The physical twin may actively or passively evolve its structure over time, e.g., failing components are replaced, extensions are added, etc. This typically also needs the update of the models describing the physical twin. These kinds of updates will be rare but may happen. However, the old models may then be kept as well, which leads to a versioned description of the physical system. Furthermore, the digital twin may assist in evolutionary adaptations of the physical twin.

• The digital shadows are either continuously extended or new ones are permanently created while the system is operating. Therefore, the digital shadows are
  updated either on each event (event-based), or on a fixed or dynamically adaptable timescale (measurements). This information flow introduces some delay, which in most cases must be below a certain (clearly defined) threshold and is very purpose-dependent. Updating can be done manually or automatically, using various sub-storage and transmission techniques.

• Communication is bidirectional, allowing, e.g., to send various forms of information about the systems context including other systems to the physical system. For example, an autonomous car may receive traffic information, weather, etc., and production engines may receive expected humidity or logistical information.

• Along the communication lines to the physical system, the DT may also send various forms of control commands, from configurations up to hard real-time execution commands, if the overall system is designed to enable this.

Rationale for this Definition of a Digital Shadow

• A digital shadow is obviously a set of data that was collected during the operation of the original system.

• To keep the connection with the original system, augmentation with various forms of meta-data is obviously necessary.

• When looking at the amount of data available over time (for example, through audio, radar, camera), it is obvious that various forms of aggregation and abstraction are useful to keep the data manageable.

• Because digital shadows have a purpose and do not necessary know that purpose upfront, it might make sense to keep data in various forms of abstractions available. E.g., The original high-resolution camera picture versus only the number and kind of objects currently seen on that picture, or only the difference to a previous situation, etc.

Rationale for this Definition of a Digital Twin Cockpit (DTC)

• Above, we have argued that a digital twin has an important role during the operation of the original physical system. The digital twin knows the current state as well as history in form of digital shadows and thus naturally is the primary information source for any form of neighboring systems, but especially human users. The DT thus needs a comfortable user interface.

• The digital twin cockpit provides the graphical user interface for visualizations of its data organized in digital shadows and models and the interaction with services of the digital twin, and thus enables humans to access, adapt and add information, monitor, and partially control the physical system. (from [BMR+22])

• A cockpit is, by definition, a part of the digital twin and can be seen both as a special service provided by the digital twin and as an integrative front-end component for various specific services that the digital twin provides.

• A cockpit visualizes various forms of data, which includes, e.g., digital shadows, any form of data received from third-party systems, all kinds of data and commands entered by the humans using the cockpit, and models of the physical system or the operation processes of the physical system. This includes geometric visualizations, schematic, diagramatic and tabular visualizations and forms of virtual reality.

• Of course, dependent on the form and use cases of the original system, as well as the use cases of the digital twin, the cockpit may have various different forms. In particular, services may assist complex processes involving the physical system, the digital twin, and the human users interacting in various forms. A Process-Aware Digital Twin Cockpit (PADTC) is thus especially interesting.

• Traditional forms of DTC and especially PADTC may be based on screen and keybord, but virtual reality and especially augmented reality also seems a promising approach. In particular may a Metaverse be understood as a ecosystem populated with digital twins, i.e. avatars of humans and replicas of buildings and other physical systems.

Detailed Explanation for the Digital Twin Definition

A DT is not a model. However, DT and models share a lot of characteristics. A DT has a purpose with respect to the original (i.e., the system) and it contains a lot of knowledge about the system. A DT, therefore, contains one or a set of models of the physical system.

A DT is not identical (isomorphic) to the physical system. While twins in the real world have the same origin and share, therefore, a lot of characteristics, twins are also not identical in the real world.

• DT is digital: digitalization in itself means that something physical is represented by a non-physical, pure software-based entity. Product and DT can, therefore, not be confused with each other.
• Digitalization also means that the DT is an abstraction. A digital version of an analogous product or picture is always an abstraction, no matter how detailed it is.

A DT provides services. These services are active and thus realized by software. They are part of a digital system consisting of a state, e.g., a database, algorithms, and usually also a graphical user interface to interact with human operators. The services of the DT may thus be used by other digital systems or by humans.

The Digital Twin can change the behavior of the physical system. That means the DT can control the the original system, at least to the extent where this strategic, tactic or real-time control is feasible.

The DT contains a set of models. These models are typically either (1) derived from engineering models, (2) directly the engineering models, or (3) derived as abstractions from the data traces collected over time of operation.

The DT has a purpose with respect to the original system. This characteristic is shared with the definition of models. Quite a variety of purposes of the DT can be thought of.

• The DT can, for example, be used to analyze, optimize, simulate, and predict behavior throughout the complete lifecycle of a physical system.
• The DT can be used to understand the behavior of the system, as well as the context it is operating in, in which state it is during development, in which mode it is during operation, etc.

The DT contains sets of digital shadows. A digital shadow is itself a passive data trace or an abstraction of it. A DT may collect more data traces over time.

• While the DS is passive, the DT contains all relevant functionalities (algorithms), storage, and retrieval to actually perform the abstractions and aggregations.
• The DT provides services that use a set of functionalities to visualize and otherwise analyze the collected DS.

To execute its services, the DT connects the data traces with the engineering models such that the databases become meaningful.

• e.g., the models describe actual and virtual sensor points of the system and the data traces describe the values collected by these sensors.
• Sensors, in a broad sense, can be automatic (e.g., the temperature of the system), input by humans (descriptions, modes), or measurements by external, temporary sensors.
• The DT uses (real-time) data traces and (design-time) models for visualization and various forms of analysis, to enable learning, reasoning, dynamically recalibrating or self-adapting its and the systems behavior, as well as assistance for improved decision-making.

Kinds of Digital Twins: Development, Usage (Operation)

Depending on the purpose, there are different kinds of digital twins. The following list elaborates some main types of DTs without assuming this list is complete:

“Development Digital Twin” is a central part of the development process. It contains a coherent set of development artifacts, which describe the system under development.

• These development artifacts are typically models of various viewpoints and in various abstractions, describing the structure, behavior, interactions, decomposition forms, geometry, functionality (both mechanical and computational), requirements, design decisions, architecture, etc.
• The development DT may also contain assembly plans (mechanical) and build procedures (IT).
• The development DT may also contain information about the development process, which consists of tasks, planned and executed iterations, artifact states, milestones in traditional processes, scrums in agile processes, etc.
• A development DT could consist of informal documents with textual descriptions, but using a model-based development process is probably more efficient.

“Usage Digital Twin” is a set of services that helps the owner, respectively the user of a system, to understand the current state and the history as much as possible and potentially also to plan future actions during the operation phase of a system.

• E.g., a car DT mainly deals with information that is relevant to users, drivers, and potentially fleet owners, such as gas filling, next time to service, customization of the display, e.g., with additional services, managing the navigation system, etc.
• A production line DT deals with maintenance and production information for the current workers as well as the management.
• If the usage DT also influences the system itself, then one could also speak of a “Controlling Digital Twin”. To enable control, a feedback channel to the system is needed, allowing for adapting its behavior according to certain given restrictions.

“Diagnostic Digital Twin” is a set of services that helps maintenance to understand the state of operation, failures, and repair operations. This includes remote diagnostics.

• A car diagnostic DT, in all its features, is used during maintenance and could typically be equipped with additional tooling to execute detailed diagnostics and repair operations.
• Diagnostic DTs may also be of interest to the manufacturer.
• In a production line, usage and diagnostic DT may coincide (or even more variants of them may exist).

“Autonomous Collaboration DT” is an active set of services that connects itself with other DTs of this type to collaborate on achieving certain functionality.

• The Autonomous Collaboration DT acts like an autonomous agent, needs to understand its context in sufficient detail, and reacts to changing environment robustly. Example: collaborative autonomous driving.
• The Autonomous Collaboration DT also has the ability to control the underlying system. If a fleet (set) of systems shall act together and in a sufficiently synchronized and reliable way, then the fleet (set) of Autonomous Collaboration DT coordinates this reliably.

“Monitoring DT” is a set of services that collects relevant data traces and proofs correct behavior versus certain juristic and technical restrictions.

• A monitoring DT, e.g., traces whenever a rented car has not left the official rental area, a production engine wasn’t operated outside its parameters, etc.
• A monitoring DT may, e.g., be used by owners, insurances, etc.
• Airplanes, e.g., are equipped with (not yet connected) black boxes.

“Business DT” is used by the owner or manufacturer to understand the past, current, and future financial conditions of the operation of a system.

• This may include the capacity utilization of a fleet of rental cars or the degeneration and replacement conditions of spare parts.

“Production DT” is used by the manufacturer during the production or assembly of a product to understand its state, respectively, the states of all its components.

Remarks:

• The development DT has the characteristics of a “type” because it may have a lot of instances (real systems built). It, therefore, also does not have data traces, except potentially from simulations used during development.
• All other kinds of DTs are based on concrete instances of the product. They can share runtime data in the form of data traces, which are unique to the concrete product.
• Thus, the development DT and all other DTs significantly differ in use and offered services, even though it may be that an extraction/derivation of the development DT is needed in the other DTs.

Digital Twin and Cyber-Physical Systems (CPS)

A useful definition: Cyber-physical systems (CPS) are engineered systems where functionalities are emerging from the networked interaction of physical and computational processes. [BDS19]

The boundary between CPS and digital twin is blurred since a CPS already contains software.

The DT can be considered a logical unit. This means that the services of the DT may be executed by many computational units (Hardware, CPUs), can be distributed, virtualized, and increasingly often lives partially in a cloud. Parts of the logical DT may be very close or even in the physical system and, thus, include edge computing techniques. If there exist other software systems in parallel to the DT, such as SAP management components, the DT can communicate with those. The times when DT and the CPS exist should largely overlap. The DT may start its existence already at the production of the CPS and survive the CPS to still provide data about it.

Logically, there is only one digital twin. If there were several twins, they would not be twins but triplets or more.

• If two digital siblings tried to control one physical twin, that could become complicated.

Logically, each CPS has a digital twin on its own. But digital twins of several CPS may

• share data, e.g., for reasons of learning from each other
• exchange certain information for cooperation (which actually means they are composed)
• share the same implementing system (platform, software) or even the same engineering models because they originate from the same development project.

Further Remarks on Digital Twins

The DT is always the DT of an original. The definition mainly applies to the DTs of systems, which includes cars, production, medical devices, buildings, and even city quarters, but not processes, nor humans or things occurring in nature, although adaptions could be easily possible.

• E.g., the digital twin of a human could be of interest in society, medical, or also industrial context, e.g., describing capabilities, workload, etc.

A conceptually well-defined digital twin can be technically distributed over a set of nodes, including the system, local devices (edge computers), and the cloud.

• This induces engineering challenges but needs to be tackled in order to fully use available computation and communication infrastructures.

Because the services of a DT are intensively connected to the functional capabilities of the physical system, it may well be that the development process has to concentrate on the physical system and digital twin in parallel. The digital twin, therefore, is NOT only a spin-off product of the development of the physical system.

• We speak of a “product service system” as the integrated, holistic system consisting of the physical product and the associated services that are available through its digital twin.

Because the system may be configurable, can be parameterized or calibrated and new services may be coming over time, the DT might be highly “self-adaptive”.

“Models@Runtime”, which here means, the explicit management of models in a digital twin allows for connecting sources of data traces to the system’s models while the system and the DT is in operation (“running”).

“Models@Runtime” also provide a highly customizable and, therefore, adaptive mechanism. Adaptivity through explicit models provides another set of engineering challenges.

We distinguish three different main forms of adaptation:

1. Autonomous self-adaptation, e.g., induced by changes in the environment, optimizations identified, for example, through continuous measurements or by slow degradation of the system itself.
2. The user wishes to adapt the system behavior.
3. The manufacturer adapts the system behavior according to identified optimizations, fixing of bugs and failures, changes of juristical side conditions, or upgrades of functionality.

Managing “Models@Runtime” enforces additional infrastructure, such as appropriate meta-models or explicit system and self-monitoring.

Parts of the “Models@Runtime” may be physically embedded within the system to achieve appropriate performance and reliability. Others may be hosted externally (e.g., in the cloud).

Complex systems are decomposed.

Individual subsystems or components of the systems

1. may have an individual history,
2. are developed in the individual sub-projects, potentially even outsourced to suppliers,
3. may be reused from predefined sets of available components, or
4. may be replaced over time. Therefore, the DT should be “structurally composed” similarly and in accordance with the product.

In addition to the product that only knows its current state, the DT should know about all historical structural changes and replacements.

The DT, therefore, has to cope with several dimensions of variability:

1. replacements of subcomponents,
2. recalibration and change of parameters of operation of the system,
3. change of available services and service-variants, and
4. deviations of the engineered system from the produced system. These dimensions of variability all exist in addition to the typical engineering variability of different variants of systems.

Related publications:

Further links

• Digital Twins and Digital Shadows in Engineering, Operation and Production
• Digital Companion
• Essays, Comments, Definitions around Modeling
• Publications
• Topic sorted list of most interesting publications
• Books
• Website of the SE