Underlying Concepts

Properly defining some of the key underlying concepts will reduce the amount of confusion when discussing digital twins. As it turns out, some common concepts can be used as defining characteristics.

A lot of technology is labelled as a digital twin nowadays. And even when actual digital twins are pointed out, they come in many guises, because different areas of society have varying digital twin requirements and expectations. We can however distinguish a number of common concepts that we can use as defining characteristics of digital twins.

First and foremost, digital twins mirror the current or future physical world and therefore should at the very least consist of physical assets (objects or people) with interactions in processes that are both modelled. Furthermore, those assets should be identifiable through a unique ID, or we would be at a loss on how to monitor interactions in processes or how to model the expected outcomes of those processes. That monitoring can be performed in real-time (instant, e.g. streaming data), near real-time (slight delay, e.g. transaction monitoring) or even in batch (longer delays), depending on the use case. Finally, the system should support data exchanges between digital twins, so larger systems can be built from smaller modules. If any of these concepts are missing in a software system, we should not label it a digital twin.

Digital twin systems provide added capabilities to traditional monitoring systems, to either support a human in making better decisions or to replace the human altogether (De Leeuw 1974). Replacing the human can be expected in situations where split-second decisions are required or in extremely complex scenarios that have been modelled upfront to avoid cognitive overload.

Digital twins can deliver added value due to the different types of analytics (see the Analytics staircase] that can be implemented, including descriptive, predictive, prescriptive and transformational analytics. The required level depends on the use case and its scope, need, and level of information.

As digital twins need to support the exchange of data, we should expect suppliers of components and whole products to provide virtual representations of their own assets. These are the first two out of five hierarchical levels that jointly define physical assets as used in the process layer. These, in turn, feed into the (multi-)system layer. For the process of developing and maintaining digital twins to be manageable, each item in every layer should comply with sector-specific interoperability standards. Current research suggests that with interoperability-by-design, we’ll be able to automate parts of digital twin development and maintenance in the near future.

Together with the infinity loop introduced in Our Vision, these are the common concepts used throughout this report.

  • Component / Product, aka equipment and physical assets in the figure – a virtual representation dealing with one (part of an) asset as a component that’s managed as a separate operating unit. An example of a component could be a single pump in a sewer system. The twin contains a digital copy of the asset, receives data from the asset, and eventually changes the behaviour of the component based on intelligent models contained within. A typical component level would be the valve in such a pump.

  • Process – the virtual representation oversees a set of assets that work together in a (physical) process. The twin receives data both on the individual assets and on the end-to-end process. This data is put into models that propose actions to optimise the process or even directly issue new set-points for specific assets.

  • System – the virtual representation covers a set of processes that together create a system with a clearly defined purpose, e.g. an entire manufacturing system.

  • Multi-system – the virtual representation of multiple systems collaborating to achieve goals that transcend departmental or organisational boundaries, e.g. (air) traffic control, and supply chain.