iTwins and IoT — Data Matters
In the previous post we introduced a generic approach for integrating IoT in iTwins. In this post, we will go over how exactly this is accomplished. Particularly, how do we get IoT data into a digital twin?
The first question is how do we get ANY data into a digital twin? There are a few different approaches for bringing data into an iTwin. Let’s start by exploring them.
Digital Twin Data — The Three Ways
- Synchronization: The first is getting design data into an iTwin. The iTwin Platform offers the ability to synchronize design files from desktop applications (such as MicroStation, Revit, Navisworks, and many others) directly into an iTwin. This is accomplished using specialized data mapping applications called connectors. The idea behind this process is that the same design data can be continually synchronized into the iTwin (as new changes are made to local design files).
- Augmentation: Now there might be other data sources besides design files that contain project data. It could be Excel, JSON, or even SQL databases. How can an iTwin access this data? Just as there are connectors for synchronizing design files, new specialized connectors can be written to incorporate new data sources into an iTwin. This process is called augmentation.
- Federation: Finally, the real value of a digital twin comes from connecting to cloud data sources. This process is relatively simple. It involves configuring the iTwin application with the cloud endpoints required for the project. For example, in the case of an IoT solution, we federate the application with live (or historic) sensor data.
IoT Data
Speaking of which, we are now ready to talk about IoT data. Which of the above approaches would we use to add IoT data to a digital twin? That depends on the data!
There are two main types of data involved in an IoT project.
- Metadata: Information about the sensors. This could be device IDs, locations, measurement units, and so forth.
- Telemetry: Real-time sensor data streaming in from the cloud.
For telemetry, since the data lives on cloud services (such as Azure or AWS), federation is the only realistic option. But for metadata, the data may or may not live in the cloud, which means any of the above three approaches can be applied. It really depends on where the metadata is stored.
Metadata
- Synchronization: Is the metadata part of the engineering design or not? If the sensors are added to the design model using the original design application, then the simple answer is synchronization. We simply synchronize design changes once sensor data is added to the original model.
- Augmentation: What if the metadata is not part of the original design? In that case, augmentation can come in handy. Let’s say the data is stored in a different data source (such as Excel spreadsheet, JSON file, or a SQL server database). We can simply run a specialized connector that reads data from these sources and augments it into the iTwin.
- Federation: What if the metadata is stored in a cloud data source? In that case, we simply pull the data directly from the cloud endpoint.
In the IoT demo app (covered in the previous post), the metadata was stored in an Excel spreadsheet. We used a specialized connector to augment it to the iTwin. The following image shows how the device metadata was defined in the spreadsheet format.
Once we had this metadata in the iTwin…we were ready to fetch telemetry.
Telemetry
In order to receive device telemetry, we configured the iTwin app with multiple connections, both Azure and AWS. We used device IDs coming in from the IoT connections to map the telemetry onto the devices. Devices were displayed as markers on the iTwin as mentioned in previous post.
When the IoT connection was turned on, the respective devices switched to Connected mode, and the iTwin app started listening for telemetry.
This connection interface is quite flexible and developers can bring in their IoT connections and just plug into the interface. Most of the heavy lifting for managing connections is already handled by the architecture of this approach.
This is how IoT telemetry data is federated in iTwin. In this case, from multiple connections! (Learn more about data federation in the iTwin Accreditation course.)
The Sky is the Limit
The beauty of this approach is that the connections are not just limited to IoT services. We can further embellish the iTwin with other data sources that are relevant to the project. In fact, bringing disparate data together in a meaningful way is what makes a digital twin really shine.
For instance — in the Smart Wind Farm project, we pulled in live sensor data, historic data from time series, and future predictions using a machine learning algorithm. We also brought in geospatial data for geographic visualization of our digital twin.
In this way, an iTwin can be extended to continue generating fresh value for any infrastructure project.
Conclusion
We have now talked about data synchronization, federation, and augmentation. And how these approaches can be used collectively to bring IoT data into iTwins.
Please let us know if you have any questions about IoT integration in iTwins by starting a discussion or filing an issue on GitHub.
- To get started with your iTwin journey check out the developer page at iTwin Platform.
- To get started with iTwin IoT integration check out this repository.
- To check out connector samples that the IoT connector is based on. https://github.com/iTwin/connector-samples
