Telemetry represents the data flowing from a physical twin to a #digitaltwin along with the associated properties that define the 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.
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.
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: