A Comprehensive Overview of Digital Twin Model Capabilities

Digital Twin Models and Telemetry Properties

Original publication date: February 20, 2020
Original post: Digital Twin Models and Telemetry Properties

A digital twin model is used to define a class, or type, of entity/thing. In other words, you define all aspects of a type of thing just once, rather than defining it over and over again for each individual thing. Each instance of a digital twin derived from a digital twin model will inherit its attributes. The digital twin model tells the event processing engine in your Internet of Things platform what to expect by providing “telemetry properties” that includes the data labels, data types, and units of measure for the incoming data to assist with pattern matching. No matter what level of analytics or machine learning you’re using, you won’t be able to derive any actionable insights without knowing the details of the data that’s arriving from your IoT endpoints.

The digital twin model is indispensable.

Digital Twin Models and Virtual Properties

Original publication date: February 21, 2020
Original post: Digital Twin Models and Virtual Properties

While “virtual properties” don’t have a 1:1 relationship with the “telemetry properties” (sensors) I described in my post [above], 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.

Digital Twin Models and Static Properties

Original publication date: February 24, 2020
Original post: Digital Twin Models and Static Properties

In my last two posts about defining Digital Twin models for your IoT system, I described “telemetry properties” that map 1:1 with device sensors and their associated data types and units of measure. I also described “virtual properties” that are a sort of “soft sensor” whose value is derived through a calculation from sensor values and other data sources.

Today I’m adding “static properties” to your Digital Twin model, which are values that typically don’t change. If I use a car as an example, static properties could be things like the length of the car, the number of cylinders, displacement of the engine, and the volume of room in the trunk. Static properties are necessary to have a more complete view of the actual entity (car in this case) and to reference data for analytics when defining the Digital Twin model that instances of Digital Twins will be derived from.

Digital Twin Models and Command Properties

Original publication date: February 25, 2020
Original post: Digital Twin Models and Command Properties

Actuators can typically be electric, hydraulic, pneumatic, or mechanical. You’re basically turning a control signal or command into an action on a machine. The “command properties” you define can include parameters such as names, data types, and units of measurement to assist a command-and-control signal in properly triggering the actuator.

For instance, an electric motor may allow you to remotely set its revolutions per minute (RPM) to control the speed. You would need to define the name of this actuation command as specified by the manufacturer of the motor. It might be “speed.” You’ll also need the data type of the value to send, which in this case might be an “integer.” Lastly, you can guess that the unit of measurement is “RPM.”

All these Digital Twin command properties defined in the model for a particular class of device are here to help your Internet of Things platform do its job to provide value.

Digital Twin Models and Rules

Original publication date: February 26, 2020
Original post: Digital Twin Models and Rules

Once you’ve added telemetry, virtual, static, or command properties, it’s time to make use of this #metadata with rules.

The first steps in deriving value from streaming telemetry data revolve around pattern matching, key performance indicators (KPIs), & filtering. You therefore need to specify one or more rules to be associated with each “telemetry property” you’ve defined in your digital twin model. This is accomplished through the use of simple operators such as equals, not equals, greater than, greater than or equal to, less than, & less than or equal to.

Let’s say you’ve defined a “telemetry property” for the “left front tire pressure” of a car digital twin model with an “integer” data type and “PSI” unit of measure. To create a “green” KPI between 30 & 35 PSI, you would define a rule looking for values that are >= 30 & <= 35. Using simple IFTTT algorithms, the event processing engine of your Edge or Core IoT platform would apply those rules to incoming data & trigger an action for values outside that range.

The Digital Twin Instance

Original publication date: February 27, 2020
Original post: The Digital Twin Instance

If you’ve worked with any of the Internet of Things platforms, you probably registered an IoT endpoint or device to make its identity known to the system. In the smallest way possible, this is what it means to create an instance of your digital twin that is entangled with a physical entity.

Like most things in the digital world, you start with identity. You give your digital twin a name & perhaps a brief description. The IoT platform you’re working with will assign a unique identifier used to access & identify the digital twin and its physical counterpart throughout its life cycle. Next, some type of security token or X.509 certificate will be bound to the unique identifier of the digital twin in order to facilitate authentication & authorization. It’s possible that you might assign a date in the future when the security token or certificate is no longer valid. You should also have the option to enable or disable the twin if you need to blacklist incoming data from a compromised physical entity. Lastly, you bind it to the digital twin model that it’s derived from.

The Digital Thread

Original publication date: February 28, 2020
Original post: The Digital Thread

Beyond the IoT telemetry the digital twin captures from the physical entity, other significant events are captured via an ever-growing digital thread.

I’ll use an automobile to illustrate how this works. While it’s critical to have a car’s current and historical telemetry data captured & analyzed, there are other events that occur throughout the car’s life that result in a digital thread adding those events to the twin’s permanent record. Taking a car to the shop for an oil change, an accident report and repair, and performing routine service on the car all represent events that are manually added to the digital thread. You could also add pictures, 3D CAD models, and other important information via this mechanism. Just imagine capturing a digital thread event where a particular type of car suffered a water pump failure at 60,000 miles. Sharing this information with all other cars of the same type would be invaluable.

In the end, this is how we tell the birth-to-retirement story of the physical entity represented by its digital twin.

Digital Twins & Subsystems

Original publication date: March 2, 2020
Original post: Digital Twins & Subsystems

If the system you intend to monitor is simple enough, then a single digital twin instance may suffice. On the other hand, if what you’re monitoring is comprised of multiple, complex subsystems, you may have to go a bit further.

For instance, an automobile is actually a system made up of many subsystems including the engine, braking, transmission, electrical, & fuel subsystems just to name a few. Depending on complexity, it stands to reason that some of those subsystems deserve to be digital twins with telemetry, virtual, static & command properties of their own. Not only would these subsystem digital twins have a parent/child relationship with the overall car, they would have causal relationships with each other. If the engine doesn’t run when you start your car, the cause could be the battery, starter or alternator in the electrical subsystem.

Defined causal relationships between the engine & properties of the electrical subsystem would alert you to the correct cause. This helps you get prescriptive analytics.

Digital Twins and Groups

Original publication date: March 3, 2020
Original post: Digital Twins and Groups

They often operate in larger systems of systems with relationships & interactions with other entities. If I were to collect several industrial robots that work together, I might create a “group” called “assembly line.” Unfortunately, using a simple group construct would do this collection of robots a disservice. The assembly line group should actually be a digital twin itself where its telemetry, virtual, static, & command properties have defined causal relationships with all the robots that comprise this assembly line.

There’s a parent/child relationship between the assembly line twin and all the robot twins. Furthermore, there are peer relationships between all the child robots. This literally brings the assembly line to life, allowing you to monitor it via your IoT platform and analytics.

Collections of assembly line digital twins can then come together to create a “composite digital twin” called a factory.