Tag Archives: Models

Twin Towser

Digital Twin Models and Virtual Properties

Another interesting aspect of a Digital Twin Model is the use of virtual, or calculated properties to derive additional IoT value.

While “virtual properties” don’t have a 1:1 relationship with the “telemetry properties” (sensors) I described in my previous post, that are actually sending data from a device, they’re super-valuable. The value assigned to a virtual property is typically derived from a mathematical combination of values from one or more telemetry properties and possibly other reference data. For instance, calculating miles per hour (speed) of a car is a good example of a virtual property where a combination of telemetry properties like the rotating drive shaft and magnetic sensors use simple analytics to tell you how fast you’re going.

While not always necessary, virtual properties deliver additional value and insights.

Petronas Twin Towers

Digital Twin Models and Telemetry Properties

Your Digital Twin Model and its telemetry properties are an essential part of the IoT data flow from device to analytics.

Data Points

Telemetry properties are the dynamic properties of a digital twin model containing values that can change often. For every data point sent from a sensor, tag, or other data source representing a physical twin, a corresponding telemetry property must be defined for the digital twin model. It starts with a human-readable, friendly name that aligns with the data point that makes sense for people and analytics. Something like temperature or humidity for example. In the event that the data points or tags use something unintelligible like T1 or H2, you must also define an unfriendly name that will be translated to the friendly equivalent.

Next up, you must assign a data type and unit of measure to the telemetry property. The data type could be a string, a whole number like an integer, a Boolean (true/false), or floating point number. The unit of measure could be acceleration or pounds per square inch (PSI) of air pressure in a car tire. Assigning data types and units of measure enable conditional logic operations to be performed.

All the telemetry property elements that comprise a digital twin model are inherited by appropriate digital twin instances and tell the software agents in your platform what to expect from incoming data. This facilitates pattern matching.

Data Format

Last but not least, the format that contains all the data points transmitted from the physical twin must be defined. Whether the data is streamed across as JSON, XML, Binary, CSV, Avro, Protobuf, or MessagePack, the platform ingesting the data must know how to parse it.


For every telemetry property you define, there’s a good chance you know in advance what a good or proper data value should be. For instance, when you define the RightFrontTire telemetry property of your car with an integer data type and PSI unit of measure, you might know that 35 is the recommended pressure for your tire. You can therefore define key performance indicators (KPIs) ranges for each of the properties. Green is good. Yellow is a warning. Red is dangerous. A range from 34 to 36 might be green whereas a range from 31 to 33 or 37 to 39 might be yellow. Anything higher or lower than those ranges could be red. The software agents in your platform will look at the incoming data points and compare those values to the KPIs defined for the corresponding telemetry properties and fire the appropriate event for green, yellow, or red to deliver an insight or take an action. The use of KPIs tied to each telemetry property is optional and represents the simplest form of analytics. Those of you in manufacturing will note this is similar to defining thresholds and limits for machine operations.

Prescriptive Analytics

If you choose to define KPIs for your digital twin model properties, you also have the option to define what should be done for respective green, yellow, and red events. This is called prescriptive analytics and clarifies one or more actions to take. Using the tire pressure example, no action is taken for a green event, whereas a yellow event would tell the driver of the car to add or remove a small amount of air from the tire. A dangerous red event would tell the driver to stop their car immediately and change the tire. Since you can define a list of prescriptive actions to take for each KPI event, an additional action to take for the red event might instruct the driver to call a tow truck if the car doesn’t have a spare tire.

More to Come

Follow along with me as I take you on a deep dive of all the elements that come together to make a digital twin. Click links below to catch up with other articles in the series:

  • Digital Twins Defined
  • Digital Twin Prototypes and Models
  • Static Properties of a Digital Twin Model