To create an historical record of what happens to an instance of a #DigitalTwin throughout its entire lifecycle, you represent this with something called a #DigitalThread.
It’s time to create a #DigitalTwin Instance of a physical entity that is derived from a Digital Twin Model.
As part of my series on #DigitalTwins, I’ve discussed the creation of a Digital Twin Model which defines a type, or class of physical entity from which instances of digital twins are derived. Once you’ve added telemetry, virtual, static, or command properties, it’s time to make use of this #metadata with rules.
In the event your #IoT platform needs to work with industrial control systems where it’s necessary to send messages to trigger actuators, you’ll define one or more “command properties” in your #DigitalTwin model.
The static properties enumerated by a #DigitalTwin model represents #IoT #data that typically doesn’t change.
Another interesting aspect of a #DigitalTwin Model is the use of virtual, or calculated properties to derive additional #IoT value.
Your #DigitalTwin Model and its telemetry properties are an essential part of the #IoT #data flow from device to #analytics.
The Washington IoT Council put on our annual event, “IoT Successes and Challenges: Commercial and Industrial Uses.”