In my previous article, I covered the Data Structure aspect of the Digital Twin.
Today, I would like to extend that topic further and provide more practical insights.
For the purpose of our discussion, I propose to think about the Digital Twin as the Data Proxy. What do I mean by the Data Proxy? That is an abstract way of accessing various types of data.
Let’s take the current state of the monitored equipment as an example.
We started by distinguishing the WORKING and IDLE states to provide business value as quickly as possible. However, displaying the current state alone does not deliver a significant benefit. What is really interesting is how that state changed over time.
This brings me back to the Data Proxy topic. We can leverage Digital Twin to record relevant information about a monitored entity using “some kind of storage”.
That “some kind of storage” underlines the value proposition of using the Digital Twin as the Data Proxy. Utilizing that concept, we can abstract the underlying complexity of numerous storage options from the users and applications.
From the user’s perspective, the IoT solution tracks and records current state changes with appropriate timestamps.
Under the hood, our system leverages the Time-Series Database to implement that functionality.
Let’s switch our focus to the CONFIGURATION property. The equipment’s configuration also changes over time, but there is a significant difference. While the current state can have one of a few defined values, the configuration is typically a complex data structure. As a result, the Time-Series Database is probably not the ideal solution for storing configuration settings.
For that specific use case, I suggest using an Object Database.
Once again, the end user (or the end user’s application) does not care about the storage type. The IoT platform’s technical solution is relevant from the vendor’s perspective. An inaccurately designed system limits potential business use cases, is hard to maintain, and introduces significant operational expenses.
The concept of Data Proxy allows for further extension; for example, we can use an external SQL Database to store information about the RAW MATERIALS.
The Digital Twin is a virtual representation of a physical or logical entity. We use Data Structure to describe the characteristics of that entity (aka metadata). Depending on the nature of a specific attribute and the way we want to utilize it, we choose the appropriate technical implementation to store relevant data. Using Digital Twin as the Data Proxy helps to hide the underlying complexity from the rest of our system.
I hope this simplified explanation shows the often-overlooked potential of the Digital Twin concept.
