How often are digital twins updated and why?
As we develop thinking, tools, and resources relating to digital twins, a lot of discussion is taking place regarding their scope, scale, latency and accuracy. Many digital twin definitions, such as the definition within the Gemini Principles, define a digital twin as:
digital twin
realistic digital representation of something physical
But what does it mean to be “realistic”?
The International Organization for Standardization (ISO) defines realistic as:
realistic
perceived by the user to faithfully represent data, information, objects, relationships and/or concepts in the natural world
This definition aligns well with the Oxford English Dictionary, which states that for something to be realistic it must represent something in a way that is accurate and true to life. Therefore, for something to be a digital twin, it needs to faithfully represent something physical. This however presents a problem.
Physical “things” are dynamic. To capture this dynamism, there needs to be a relationship between both the physical thing and its digital representation. Typically via detection technologies such as sensors. These readings, however, are not instantaneous:
- There is a latency between the intervention which triggered the physical change and the detection of that change. For example, the time taken for a pipe to break and a decrease in pressure being detected.
- There is a latency between the detection and its input into the digital representation. For example, sensor data may need to be manually uploaded, or data may need to be configured for use.
Both latencies result in a digital representation that, temporarily, isn’t faithful. For this period of latency the digital twin has been desynchronized and is no longer realistic.

Logically, you may have concluded that the ideal scenario is to remove these latencies and utilize real (near-real) time data. However, I want to present an alternative approach.
Depending on the purpose, each digital twin may have different acceptable latency periods. For example, consider a digital twin which monitors the flow of components within a system. This type of digital twin might be used by:
- Utility companies to monitor energy flow;
- Retailers to monitor stock flow;
- Healthcare professionals to monitor bodily flows; or
- Building owners to monitor occupancy flow.
While each of these example are fundamentally the same (monitoring how things move within a system). Each of them will have a different acceptable latency period. The utility and healthcare use case may require near-real time data (per second?), the building owner uses case may be satisfied with a higher latency period (per minute?), while the retailer may be satisfied with an even higher latency period (per hour?). As outlined within the Gemini Principles, what’s important is that a digital twin represents something physical “at a level of accuracy suited to its purpose”.
So, when considering how often a digital twin should be updated it is important to consider what is the acceptable period of latency that’ll allow the digital twin to continue fulfilling its purpose. While some purposes will require near real-time data, many will not. Reducing the frequency that a digital twin is updated may provide cost/time benefits without affecting value.
If you would like to learn more about techUK’s work in this area, or learn about our new Digital Twins Working Group (DTWG), then please feel free to get in touch with Tom Henderson ([email protected]) today or follow our @techUK handle on Twitter & LinkedIn! You can also visit techUK's #DigitalTwinFuture campaign here!
