Telemetry Properties of a Digital Twin Model

Telemetry represents the data flowing from a physical twin to a #digitaltwin along with the associated properties that define the data points.

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.

KPIs

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

Let's stay connected at?Rob Tiffany Digital