In this article we will discuss some use cases for IoT Digital Twin representation and the benefits of having an accurate Digital Twin model.
Some background information about Digital Twins can be found at the following links:
What is Digital Twin technology?
5 reasons Digital Twins matter to your IoT deployment.
To better understand how we want our Digital Twins to operate, we need to put together a shopping list of what we want to accomplish when using the Digital Twin as a representation of an actual physical end-device.
Must have’s:
- Visibility and accurate generation of all expected sensor data and system data, sizes and rates, that will be produced by the end device.
- Visibility and accurate generation of all layers of protocol data( L2-L7), frames sizes and frames types, that will be used to send data from a network of end-device’s to the server.
- Visibility of all link-layer networks, from the end-device to the server.
- Visibility and accurate generation of all error information generated by the system, from end-device to server.
- Visibility and accurate generation of all security protocols.
From a developer’s standpoint, the above list is all-inclusive and necessary. For the IoT integrator, it may be considered overkill, but there are still benefits for having an accurate Digital Twin model for all levels of the product use chain.
Now, let’s break down the shopping list into a Digital Twin implementation model.
In order to develop our Digital Twin model of the end-device, we need to model all of the functional components of the actual end-device and we want to do so in a manner that supports modular and portable IP. This requirement will become clearer as the model is developed and used.
As you can see from the above diagram, the digital representation of the end-device, as it’s Digital Twin, can be modeled by using a stack with layers and interfaces. The stack consists of all software modules, including the supported networking protocols, sensor interfaces, OS, CPU, and HW interfaces. In this device model, all interfaces are abstracted to allow the software modules to be ported to the platform that will be executing the “Digital Twin”. The concept of making “portable IP modules” is not new and relies on the concept of developing a system while adhering to “porting technology”.
The above diagram on the left highlights in green what stack modules from the actual end-device that will be ported to the Digital Twin execution model. The diagram on the right highlights in red what code needs to be developed to simulate all required interfaces for the digital twin.
For most systems, the stack modules highlighted in green represent the majority of the system code.
With our above model, we can now be assured that our Digital Twin representation, will meet our shopping list of expectations with a high degree of accuracy, because most of the actual code logic that is running in the end-device will be ported and executed within our Digital Twin. This is a win-win scenario because everything we learn about our Digital Twin, as it is executing and being evaluated with various use case scenarios, can be applied (enhancements, bug fixes, .. etc) directly to the end-devices’ stack IP.
EMBEDnet’s latest product offering: “Protocol Emulator Tool Kit” (PETK) supports accurate Digital Twin creation and execution by providing a framework that accelerates the integration, configuration, execution and evaluation of modular and portable stack IP. Digital Twins can be created, replicated and configured to operate as a network of devices. Being able to quickly configure and execute unlimited end-device use case scenarios, with actual end-device stack IP, on a single host system, provides quite a few advantages. When it comes down to it, all of the time spent executing the Digital Twin within PETK is potentially adding value to the end product.
To learn more about PETK, request our white paper and visit our PETK product page.
