The Augmented Digital Twin

The movement toward connecting every device, machine, and sensor to the internet takes advantage of two key technologies: connectivity, which has become increasingly easier with advancements in Wi-Fi, cellular, and local wireless technologies; and web services like computing, storage, and networking, which have become a commodity resource that gives end users easy access to data from embedded devices.

Having a network connection to a device isn’t a new concept, but it raises a new challenge for companies and OEMs who have little experience with data: it’s relatively easy to connect a device — but what does that actually mean?

It’s compelling to regard IoT as an engineering triumph that transmits once-obscure data to the modern databases and interfaces of our connected world, and without these technologies, IoT wouldn’t be the industry it is today. But as the end users of IoT shift from early adopters to the mass market, and as hardware and connectivity become commodity assets, the value of IoT has to shift too. That shift has given birth to the concept of a digital twin.

A digital twin is a virtual representation of a physical device that lets you gain greater insight by combining measured physical parameters (vibration, temperature) with other digital information about the asset (manufacturing date, maintenance history). This combination enables a range of new insights about an asset — performance, health, and predictive insights about what may happen in the future. The concept of a digital twin moves manufacturers and operators closer to the ultimate goal of selling outcomes (results) instead of products (machines).

The IoT asset

Implied in the term “digital twin” is the existence of a sibling — an object, asset, or thing being transmitted and replicated into a digital representation. Imagine condition-monitoring sensors installed on a factory air compressor system: with the exception of signal strength or battery status, the state of the sensor itself is immaterial. The sensor exists to describe the condition of a specific subpart of the asset, like the temperature of a compressor line. The “thing” you actually care about isn’t the wireless-capable thermocouple or the temperature of the compressor line in particular, but the holistic integrity and health of the air-compressor system itself. That “thing” is the asset — the sibling that becomes the target of a digital twin.

Direct observation of an asset — walking past a compressor and noticing unusual noise, vibration, or heat — is often the most familiar way to understand its condition, but it doesn’t scale. Early condition-monitoring solutions mapped sensor signals to channels or memory addresses with physical displays that directly represented those values, removing the need for direct observation but leaving it up to the observer to infer or correlate measured values with asset state and maintenance records. Many first-generation IoT solutions simply overlaid that same local-monitoring pattern on top of internet protocols. It’s tempting to scale this by adding more sensor types and a wider range of captured data, but simply filling databases with streaming sensor data creates systems only data scientists can use. If that information is instead presented in a meaningful model, users can forget about the data and react to knowledge instead. That’s the purpose of a digital twin: transforming sensor and device data into tangible asset knowledge for business users, application users, and automated processes.

Model the asset, not the sensors

The digital twin provides its greatest value when it describes the asset, not the hardware — remember, hardware and sensors are nothing more than instruments and gauges that facilitate observation. Decoupling an asset from its connected hardware starts with asking the right questions about each data type:

• Temperature — What is the sensor attached to? What events cause the reading to change? What is affected by changes in temperature? (A temperature sensor on a livestock water tank measures water temperature, but the actual asset being protected could be the water supply system or the livestock herd itself.)
• Pressure — What material does the sensor measure, and in what kind of environment? (A pressure sensor on a tractor tire, combined with known tire size and correlated temperature data, can reveal the load weight and duty cycle of the tractor.)
• Accelerometer — Is the sensor activated by a human, a machine, or an outside force? Can changes in motion be correlated with known events? (An accelerometer on a smart lawn mower can detect changes in mowing patterns or alignment that indicate a maintenance need.)
• Voltage, current, power — What type of power supply is being monitored, and does it need replacement or maintenance? (Voltage and current sensors on a bank of batteries can reveal the health of the batteries or the charging system.)
• Lack of data (offline state) — What does an offline state indicate, and can gaps be interpolated? (Without identifying the underlying asset, an offline state is hard to interpret — it might mean a power failure, which itself is worth alerting a maintenance worker about.)

Leading IoT platforms enable this kind of asset modeling with a few complementary capabilities: product-definition and management features that reflect a connected device’s sensors and digital data without custom code or datastores; custom data and event routing that make the data meaningful to users and their monitored assets; and integration with external data sources that enrich the digital twin beyond what the asset alone can tell you.

Separate condition from control

A digital twin reflects the current state of an asset, but many IoT use cases also require command-and-control interaction with a connected device. Command-and-control requests should be kept separate from an asset model’s state — typically with distinct “observed” and “target” values for a data resource. Leading IoT platforms build this separation in directly, letting a digital twin define which data resources can accept commands while maintaining the correct state as commands are received, executed, and confirmed. When presenting a digital twin to users, it matters that the potential difference between the physical and virtual state is handled clearly — during a command sequence, showing both what the user wants and what the device currently has keeps people informed and able to react appropriately.

Leverage data to provide meaningful views

IoT brings the challenge of representing something that isn’t as simple as one physical connected thing mapped to one digitized thing — the same underlying data is important to different groups of people in different ways. Using the factory-sensor example again: most users don’t care about any single sensor, though an installer troubleshooting a signal issue or a dead battery might. A different set of users only cares about the sum of the sensors for the whole machine being monitored, and another set may only need to see data about the factory as a whole. It’s important to support the concept of a digital twin at different levels of grouping.

Tactics for building a meaningful view can range from simple UI layout and graphics to more complex derivative data and forecasting. Dashboard tools are an efficient way to visualize data but can be constraining when correlating or deriving values from multiple sensors; visualization libraries accelerate custom charts but require more development skill and the right hosting environment. Matching the right tool to the use case — proof of connectivity, trend analysis, enterprise data analytics, or a full consumer mobile app — is part of choosing the right platform capabilities for the job.

Oversample first, optimize second

As an IoT product develops from concept to completion, its digital twin should evolve too. Start with a liberal approach to measuring asset and environmental health. Once that data — and the meaningful insights it produces — has been collected and identified, optimize data streams, bandwidth, and sampling rates to remove unnecessary cost and complexity. An IoT platform that can collect and normalize disparate data sets, integrate enterprise web services, and expose event listeners to capture, process, and display the right data at the right time makes this evolution possible.

The digital twin maturity model

A digital twin’s maturity can be described along two axes: how much is known about an asset and its environment (scope), and how quickly the twin reflects and anticipates real-world events (reporting frequency).

Scope

• Partial — A minimal digital twin containing a small number of data sources, like temperature, pressure, and device state. Useful for monitoring a single key metric from a low-power or resource-constrained asset, or for proving out device-to-platform connectivity during early development. A partial twin can still support derivative data — for example, if pressure is down but temperature is up, and a correlation is identified, a corresponding inference about asset health can be made.
• Clone — Contains all meaningful and measurable data sources from an asset. Applicable when a connected asset isn’t power- or data-constrained, and useful during prototyping and data-characterization phases.
• Augmented — Enhances the connected asset’s data with derivative data, correlated data from federated sources, and/or intelligence from analytics and algorithms.

Reporting frequency

• Statistical sampling — Data updates at a fixed rate that ensures a statistically significant cohort of data within a desired timeframe (typically 1 minute to 1 day). Efficiency is prioritized over timeliness, with no reaction to threshold or state-change events.
• Condition monitoring — Data updates at a fixed rate frequent enough to enable meaningful alerting, or whenever an edge device detects a state or threshold change (typically 1 second to 1 hour).
• Real-time control — Data updates as frequently as technologically reasonable, with low latency prioritized over efficiency or cost — usually over a persistent socket connection with sub-second latency. A connected light bulb that needs to respond to commands and report its current power state in real time is a good example.

Best-in-class digital twins start with a basic set of sensors and relatively infrequent sampling to prove technical feasibility — at this stage, basic descriptive analytics (what is the asset’s current state, and what events of interest have occurred) are possible. As the technical feasibility of the digital twin is proven, additional sensors are often added and reporting frequency increased, providing better granularity into specific performance aspects and enabling diagnostic analytics (why did certain events occur). With a baseline of asset health and performance data, plus additional sources like maintenance history, account data, and parts data, the digital twin’s maturity can improve to an augmented status — at which point it becomes, in many ways, more valuable than the physical asset itself, unlocking predictive analytics (what will likely happen) and prescriptive analytics (what should be done to prevent failure or reduce downtime).

Summary

IoT unlocks the resources of cloud computing and the design patterns of application development. Leveraging those resources correctly evolves connected hardware from gauges and dashboards into augmented, virtual representations of physical assets that enable insights that weren’t previously possible — but it also comes with the risk of added complexity. Modeling and implementing the right digital twin, guided by a clear maturity model, multiplies the value and utility of that model while minimizing the risk, and helps you build a roadmap toward an optimized augmented digital twin that captures the true value of your data.