How To Best Support Digital Twins

In this article, we first review the definition of a digital twin. Then we argue that a detail-on-demand visualization system should be an integral part of the software system used for gaining insight from digital twins.

Introduction

Wikipedia defines a digital twin as “a digital representation of an intended or actual real-world physical product, system, or process (a physical twin) that serves as the effectively indistinguishable digital counterpart of it for practical purposes, such as simulation, integration, monitoring, and maintenance.”

The concept is popular in a factory floor setting, where a client would construct a physical model of the factory. Then, he could use the model to visualize the state of the factory floor where alerts and state variables could be displayed. If he wanted to try alternative scheduling, configuration, or state variables, he could run a simulation on the model to see alternate results. Testing is another excellent application.

A digital twin could be useful in many other environments beyond factories.  In a building, for example, one could look at alternate heating strategies. In an urban road network, a digital twin would be useful for exploring alternate settings for traffic lights. And one could use a digital twin for exploring alternate air traffic control strategies for a busy airport.  In this article, we use a factory floor as an example.

Requirements for a Digital Twin

This section lists four requirements that display software for digital twin applications should satisfy.

Requirement 1: Display of information on the screen using a 2D or 3D spatial model  

A digital twin is inevitably spatial in nature. Hence, the screen should be able to render the model either in 2D (flat world) or in 3D (reality). As 3D is much more expensive computationally than 2D, I expect products to offer some of the features of 3D but much less expensive computation. One must be able to decorate the spatial model with user information. That comes from monitoring or simulation software. For example, Airbnb decorates a Google map with locations of available properties.

Requirement 2:  The ability to pan

A large digital twin will not fit on the screen in its entirety. Instead, the ability to pan around a bigger model, with relevant spatial information being rendered on the screen, is needed.  Otherwise, one will be unable to scale digital twins to large sizes.

Requirement 3: The ability to zoom

I claim a digital twin is inevitably hierarchical. For example, a component of a machine could have a digital twin. A group of components make up the machine and could have a digital twin.  In a factory, many machines represent the next level of a hierarchy. Finally, there can be many factories in a company’s portfolio.  As a result, a natural hierarchy would be:

    Enterprise

|

    Factory

|

    Machine

|

    Component

The simplest application of a digital twin is for monitoring. In this case, a traditional dashboard would present summary data on the state of the enterprise. Figure 1 shows an example dashboard from a real application in Brazil, where the tags are in Portuguese.

However, much information is lost in this presentation. For example, if there was a power surge or outage in a small area, that information is not available in Figure 1. In other words, Figure 1 loses context.  

 An Example Summary Dashboard

Figure 1

Instead, the enterprise with this application wanted the display in Figure 1 augmented with the information shown in Figures 2-4. Here, he starts with an overview of the 58 factories in his enterprise.  In this display, he can quickly see the overall health of his factories. There are three significant issues, and he can drill down to get specific information. Additional details on the red factory can be obtained in Figure 3 with another click. Finally, Figure 4 shows the voltage waveform over time in this factory, and we notice a spike that probably caused the issues.

The Big Picture

     Figure 2

As a result, in a few clicks, a user can navigate around a hierarchical digital twin.  This zoom capability is a great way to deal with hierarchical models.

 The Details

Figure 3

The Actual Data

Figure 4 

Notice in Figures 2-4 that the display is a map (Figure 2), a floor plan (Figure 3), and a time series plot (Figure 4). A crucial requirement is:

Requirement 4: The ability to render multiple kinds of data onto the screen

I claim that these four requirements are the minimum required to support digital twins. There may be other requirements, such as the ability to support real-time changes to the display.  Moreover, the response time to user gestures must be less than 0.5 seconds, or real users will get very frustrated.

Supporting all four requirements is crucial to success, and Hopara is the only commercial product I know of that supports all four requirements.  For more information on Hopara, please visit www.hopara.io.

About the Author

Michael Stonebraker is a pioneer of database research and technology. He joined the University of California, Berkeley, as an assistant professor in 1971 and taught in the computer science and EECS departments for 29 years. While at Berkeley, Stonebraker developed prototypes for the INGRES relational data management system, the object-relational DBMS, POSTGRES, and the federated system, Mariposa. He is the founder of three successful Silicon Valley startups whose objective was commercializing these prototypes.

Stonebraker is the author of scores of research papers on database technology, operating systems, and the architecture of system software services. He was awarded the ACM System Software Award in 1992 (for INGRES) and the Turing Award in 2015. Stonebraker was elected to the National Academy of Engineering and is presently an adjunct professor of computer science at MIT’s Computer Science and AI Laboratory (CSAIL).