Digital Twin Real-Time Data: Does a Twin Really Need It? A Fact-Check

Last Updated: October 4, 2026

Walk any trade-show floor and you will hear the same pitch: a digital twin is only a twin if it streams live sensor data, and anything slower is “just a model.” It is a tidy, quotable rule, and it quietly bankrupts projects. Teams that adopt it build streaming infrastructure for every asset, discover that most of their decisions are made weekly, and end up operating an expensive, brittle pipeline whose latency nobody uses. The question deserves a precise answer, so this article tests the claim against the standards, the literature and the physics of data movement.

The short version: digital twin real-time data is a design parameter, not a definition. The standards that define a twin tie it to a synchronization rate that is “appropriate” or “fit for purpose,” and neither says “continuous” or “instant.” But the opposite slogan, “real-time never matters,” is just as wrong. For a closed control loop, stale data is a defect. What you leave with is a method: convert each decision into a freshness budget, pick the cheapest latency class that meets it, and know exactly where the budget is spent.

What this covers: what the standards actually say, the maturity ladder from digital model to autonomous twin, three latency classes with real definitions, a data-age equation you can compute, the ISO 23247 data flows, a decision tree, the costs of over-engineering, and a checklist.

What Changed for October 2026

This is a ground-up rewrite of the June 2026 fact-check. The verdict is unchanged; the evidence is deeper and several loose points are corrected.

The definition is now anchored in two standards, not one. The earlier post leaned on ISO 23247 alone. ISO/IEC 30173:2023 (digital twin concepts and terminology) defines a digital twin as a “digital representation of a target entity with data connections that enable convergence between the physical and digital states at an appropriate rate of synchronisation.” The phrase appropriate rate is the strongest single quotation against the myth.
ISO 23247 grew. ISO’s catalog lists Part 5 (digital thread for digital twin) as published in June 2026, and our coverage reports Part 6 (digital twin composition) shortly after. Both bear on synchronization, and we cover the implications below. Treat them as new: there is no independent implementation track record yet.
Latency classes replace the vague “tiers.” The earlier four-tier spectrum mixed how often data arrives with what the twin does with it. This version separates freshness (batch, near-real-time, real-time) from capability (model, shadow, twin, autonomous), because the two axes move independently.
A computable data-age model replaces hand-waving about “tolerable latency.” You can plug your own sampling interval, queueing and processing time into it.
Cost and failure arithmetic is now explicit and clearly labelled illustrative.

Context and Background: Where the Myth Comes From

The “must be live” claim is not stupid. It is a half-truth that survived because it describes the most visible and best-marketed corner of the field. Understanding where it came from makes it easier to take apart.

The concept predates the word. Michael Grieves presented the underlying model at the University of Michigan in 2002 while forming a Product Lifecycle Management center, and he called it the Mirrored Spaces Model in 2005 and the Information Mirroring Model in 2006. The term “digital twin” itself is credited to NASA’s John Vickers around 2010, as reported in common histories of the field (see the digital twin overview on Wikipedia). Grieves framed the idea as a lifecycle construct: a virtual prototype can exist before any physical product does, and it keeps a managed correspondence with the product through manufacture, operation and retirement. A design-stage twin has no live asset to stream from, so “real-time” could not have been part of the original idea.

Three later forces welded “real-time” onto the word. First, cheap industrial IoT: once sensors, gateways and brokers became commodity, streaming became feasible, and feasible things get marketed. Second, the vendor incentive: defining the category as live conveniently excludes cheaper batch-oriented competitors. Third, maturity models, which correctly place real-time monitoring and autonomous control on higher rungs, were misread as admission criteria rather than a progression. For the broader lifecycle picture, our complete overview of IoT, digital twins and PLM walks the construct from design to retirement.

There is also a genuine and useful distinction hiding in the confusion: a twin differs from a generic simulation because it is bound to a specific, identified asset. People grasp that the binding matters and wrongly conclude that the binding must be fast. The binding is a requirement. Its speed is a parameter.

Finally, there is vocabulary drift. In everyday use “real-time” means “recent” or “fast.” In control engineering it has a strict meaning: a system is real-time if it meets deadlines, where missing a deadline is a failure. A dashboard that refreshes in two seconds is fast but not real-time in the engineering sense, because nothing breaks if a refresh arrives late. Much of the argument in this field is two camps using one word for two ideas, and we will keep the engineering meaning below.

The Reference Claim and What the Standards Actually Say

The claim under test: “A digital twin must maintain a continuous, real-time connection to its physical counterpart; otherwise it is only a model or a simulation.” There are three places to check it.

ISO/IEC 30173:2023. The joint ISO/IEC concepts-and-terminology standard defines a digital twin as a digital representation of a target entity with data connections that enable convergence between the physical and digital states at an appropriate rate of synchronisation (wording as quoted by the BSI-derived summary on Designing Buildings). Three things stand out. The twin represents a target entity, so the binding to a specific thing is mandatory. The connection must enable convergence of physical and digital states, which describes an outcome, not a transport. And the rate is appropriate, a word that by definition depends on purpose.

ISO 23247 (manufacturing). Part 1 of the series, “Overview and general principles,” was published in October 2021 by ISO/TC 184/SC 4 (ISO 23247-1 catalog entry). It is commonly quoted as defining a digital twin as a “fit-for-purpose digital representation of an observable manufacturing element with synchronization between the element and its digital representation.” Fit for purpose ties fidelity and update cadence to the use case; synchronization is required but its tempo is unspecified. We could not access the paywalled text, so we rely on the widely quoted wording and flag it in our review log.

The academic classification. Kritzinger and colleagues, in “Digital Twin in manufacturing: A categorical literature review and classification” (IFAC-PapersOnLine 51(11), 2018, pp. 1016-1022), split the field by data flow automation, not by speed. A digital model has manual data flow in both directions. A digital shadow has automatic flow from physical to digital and manual flow back. A digital twin has automatic flow in both directions. Notice what this says: the dividing line is automation and bidirectionality, with nothing about milliseconds. An automated hourly feed with an automated hourly write-back qualifies under this taxonomy as a twin; a sub-second one-way stream is only a shadow.

That last point is the one that most upsets the slogan. By the most-cited academic classification, direction of flow matters more than latency. A very fast, read-only dashboard is a shadow. A slower, closed-loop system is a twin. Speed and twin-ness are orthogonal.

A caution about the other direction. Kritzinger’s strict definition is not universal, and many practitioners call a bidirectional-flow requirement too narrow, since plenty of valuable monitoring twins are one-way. We do not need to resolve the terminology fight to reach a decision: whichever definition you prefer, none of them contains a latency threshold.

For a broader tour of these standards and the Digital Twin Consortium’s framing, see our overview of ISO 23247, ISO/IEC 30173 and DTC standards.

Two Axes, Not One Ladder: Maturity Versus Latency

Most explainers draw a single ladder from “static model” to “autonomous twin” and imply that you climb it by adding speed. That conflates two independent axes, and separating them dissolves most of the confusion.

Axis one: capability, what the twin does. Roughly: a descriptive model (it represents the asset), a shadow (it mirrors state automatically), a diagnostic twin (it explains deviations), a predictive twin (it forecasts), a prescriptive twin (it recommends actions), and an autonomous twin (it acts without a human). This is the maturity ladder that vendors and analysts publish in many variants. We treat the exact rung names as conventional rather than standardized.

Axis two: freshness, how old the data is when it is used. Batch, near-real-time, real-time, as defined in the next section.

The axes interact only through the decision. A predictive-maintenance twin for a rotating pump lives happily at high capability and modest freshness: it forecasts remaining useful life from trends over days, so minute-old data is plenty. A collision-avoidance twin for a robot cell sits at moderate capability but demands extreme freshness, because the physics gives it a few milliseconds. A strategic capacity twin can be highly capable, simulating thousands of scenarios, while consuming month-old aggregates. Capability and freshness are chosen independently, and the price of freshness is paid per decision, not per twin.

Figure 1: Start from the decision and ask how old the data may be. The answer selects the latency class and the kind of twin that class supports.

Figure 1 is the whole article in one picture. The tempting design starts at the left-hand sensors and asks “how fast can we go?” The correct design starts at the left-hand decision and asks “how stale can the data be before this decision gets worse?” The first question has no natural stopping point, so budgets balloon. The second has a numerical answer.

Three Latency Classes, Defined Properly

Terms like “real-time” and “near-real-time” are used so loosely that they carry no information. Here are working definitions that are tied to consequences, which is what makes them testable.

Batch: freshness measured in hours to weeks

Data moves on a schedule or on events: a nightly extract-transform-load job, a file drop after an inspection, a manual import after a commissioning test. The twin’s state is a snapshot with a known timestamp. Batch is the right class for planning, benchmarking, compliance, design validation and any decision made on a cycle slower than the data’s own variability. A fleet energy-benchmarking twin that recomputes each night from the previous day’s meter reads is batch, and rightly so, since the action it supports (a weekly report, a monthly retrofit decision) cannot use anything fresher.

Batch is not synonymous with “low quality.” Batch pipelines can reconcile, deduplicate, validate and enrich data in ways streaming cannot cheaply match. A batch twin’s data is often more trustworthy than a live feed because late and out-of-order records have been settled before the twin consumes them. For how this looks when a historian feeds a twin, see our OPC UA historian to digital twin ingestion architecture.

Near-real-time: freshness measured in seconds to a few minutes

Data flows continuously through a broker or stream processor and the twin updates incrementally. A human or a slow automated process acts on the result. This is where most “live” monitoring and predictive-maintenance twins actually sit: vibration and temperature features arrive every few seconds, an anomaly model scores them, and an alert reaches a technician who needs minutes, not milliseconds, to respond. A missed update costs a slightly later alert, not a failure. Typical building blocks include MQTT with Sparkplug B at the edge, a stream platform in the middle and a time-series store behind it, as in our industrial IoT time-series platform architecture.

Real-time: freshness bounded by a hard deadline

Here lateness is a fault. The loop senses, decides and acts within a bounded time, and the bound is part of the safety or stability argument. Examples include servo and motion control, active vibration damping, protective relaying and robotic collision avoidance. Industrial fieldbuses and Time-Sensitive Networking exist precisely to bound latency and jitter deterministically; see our comparison of PROFINET, EtherCAT and OPC UA FX over TSN. A critical architectural point follows: a loop with a hard deadline almost never runs through the cloud or even through a general-purpose twin platform. It runs in the controller at the edge. The twin may parameterize or supervise the loop, but the loop itself lives where determinism is possible.

That last point is the most underappreciated fact in this debate, so it earns repeating. In a well-designed system the real-time control loop and the digital twin are different software with different clocks. The control loop meets deadlines of microseconds to milliseconds. The twin ingests state at a relaxed rate, runs models that take far longer than a control cycle, and returns slower-moving recommendations, setpoints or schedules. Asking whether “the twin” needs real-time data frequently mixes up these two layers.

Class	Typical freshness	What happens when data is late	Typical transport	Typical decisions
Batch	Hours to weeks	Nothing breaks; report is delayed	File, ETL, API pull	Planning, audit, benchmarking
Near-real-time	Seconds to minutes	Alert or insight arrives later	MQTT, OPC UA PubSub, stream	Monitoring, predictive maintenance
Real-time	Microseconds to milliseconds	A fault or safety event	Fieldbus, TSN, in-controller	Motion control, protection

The ranges are conventional engineering bands, not values from a standard. Treat the boundaries as soft; the consequence column is what defines each class.

The Data-Age Budget: A Computable Test for “Is It Fast Enough?”

The direct answer to “how real-time must it be” is a number you can calculate. Define data age as the time between the physical event and the moment the twin’s output is used to decide something. Data age is not one delay; it is a sum of waits, and the sampling interval usually dominates.

For a signal sampled every T seconds, an event happens at a uniformly random moment within an interval and is captured at the next sample. On average the sampling wait is T/2, and in the worst case it is T. Add the gateway batching delay, network and broker transit, ingestion and parsing, model evaluation, and finally the action path. Mean data age is therefore approximately:

age = T/2 + gateway_batch + transit + queue + ingest + model + action_path

Figure 4 shows where each term arises. The useful insight is that you pay for every term, but you can only afford to ignore the ones that are small relative to the decision’s freshness requirement.

Figure 4: Data age accumulates across the path. Sampling interval and batching usually dominate, which is why faster transport alone rarely fixes a freshness problem.

A worked example, with illustrative numbers

The numbers below are illustrative, chosen to show the arithmetic rather than to describe any real plant. Suppose a twin supports a decision to schedule bearing replacement, and the decision is made once per shift (eight hours). The physical degradation process takes days to progress from detectable to critical. The decision’s tolerance for stale data is dominated by degradation speed, not by the shift: if the fault needs roughly 48 hours to become critical and you want at least a 10x margin to react, the data may be up to about 4.8 hours old. A 15-minute batch cadence delivers 20x that margin. Streaming at one sample per second would add nothing the decision could use.

Now the opposite case. A twin parameterizes a servo-driven pick-and-place cell, and the control loop must hold a position error inside a tolerance while the load changes within, say, 20 ms. A data age of several hundred milliseconds, perfectly fine for monitoring, is useless here because the disturbance is over before the data arrives. The answer is not a faster twin platform; it is a controller-resident loop with the twin acting on a slower layer. The same twin software gets two different freshness verdicts because the decisions differ.

Two rules fall out of this arithmetic.

Required freshness is roughly the decision’s reaction time divided by a safety margin, bounded by the physical process’s own dynamics. If the asset’s state changes slowly, sampling it faster only measures the same value repeatedly. A tank with a time constant of ten minutes gains nothing from 100 Hz sampling. This is the intuition behind the Nyquist-Shannon sampling theorem: you need to sample at more than twice the highest frequency component that matters, and not meaningfully faster.
Freshness has a staircase cost curve. Moving from daily to hourly costs a little more. Moving from minutes to seconds requires streaming infrastructure. Moving from seconds to milliseconds requires deterministic networking and edge compute, a different engineering discipline, not a larger instance size. Each step is a discrete architectural change, which is why it pays to buy the step you need and stop.

What the cost staircase looks like, illustrative

Take a hypothetical fleet of 2,000 pumps with 20 signals each. At one sample per second, that is 40,000 points per second. At an assumed 100 bytes per point on the wire including envelope and timestamp (an assumption; real encodings range widely), that is about 4 MB per second, or roughly 345 GB per day before compression. Sample the same 20 signals once per minute and the stream drops to about 667 points per second, around 5.8 GB per day, a 60x reduction. Edge-side aggregation (min, max, mean, RMS and a handful of spectral features per minute) can capture the diagnostic content of the fast signal at close to the lower volume. The point is not the exact figures but the shape: bandwidth, broker sizing, storage, and the on-call burden all scale roughly with sample rate, while the decision value usually saturates early.

How ISO 23247 Frames the Data Flow

If synchronization is the requirement, where does it live in an architecture? ISO 23247 gives a reference architecture for manufacturing digital twins with a small number of domains, and reading it with latency in mind is instructive. The series’ reference architecture (Part 2) arranges the system into an observable manufacturing domain (the physical element), a data collection and device control domain, a digital twin core domain, and a user domain.

Figure 2: The four-domain reference structure. State data flows inward through data collection; insight flows to users; control intent flows back through device control. Latency requirements differ per arrow.

Two things matter for our question. First, the architecture has separate arrows for observation, user interaction and control, and nothing says they share a cadence. Data collection can be periodic while a user query is on demand and a control write-back is event-driven. A twin can be near-real-time on the way in and batch on the way out, or the reverse.

Second, the synchronization function sits in the core domain, between collection and the twin’s models. That placement says what synchronization is: a managed reconciliation of physical state and virtual state, with a defined policy. The policy is what the standard cares about, and policies include “every update,” “every hour,” “on change beyond a threshold,” or “at lifecycle gates.”

The newer parts of the series sharpen this. According to ISO’s catalog entry, Part 5, “Digital thread for digital twin,” was published in June 2026 and covers principles, methodologies and use-case examples across design, planning, production and testing (ISO 23247-5 catalog entry). Our dedicated coverage explains why a digital thread is about traceable lineage of data across the lifecycle rather than about speed; see the ISO 23247-5 digital thread reference architecture. Likewise, our ISO 23247-6 composition article describes how multiple twins combine as integrated, unified or federated systems. In a federated arrangement across companies, the loose coupling between participants is deliberate, and a contractual, slower and coarser exchange is the design, not a shortcoming. Because these parts are new, we flag them as having no independent field track record yet.

Synchronization policies in practice

It helps to name the policies that satisfy “synchronization” so teams choose one on purpose.

Scheduled sync. Pull or push on a clock. Cheap, predictable, easy to audit. Right for fleet reporting.
Event-driven sync. Update when something happens: a work order closes, an inspection completes, a configuration changes. Right for as-maintained and as-built twins.
Change-triggered streaming (report by exception). Publish only when a value moves past a deadband. This is how well-designed industrial publishers behave, and it compresses volume dramatically for slow signals. Sparkplug B’s birth-and-death certificate model supports this kind of state awareness.
Continuous streaming. Publish every sample. Justified when downstream models truly use the full bandwidth.
Deterministic loop coupling. Cyclic exchange with bounded jitter. Justified only for control.

Each policy implies a different failure mode, a different cost and a different answer to “what does the twin believe when the link drops?” That last question is more important than the headline cadence, and we return to it in the failure-modes section.

Figure 3: Three questions choose the latency class. Only a decision that acts on current state, without a human, inside a sub-second consequence window, requires a real-time loop.

When Real-Time Is Necessary, and When It Is a Myth

Figure 3 encodes a three-question test. It is deliberately blunt, and its power is that it forces a team to attach the word “real-time” to a specific decision.

Question 1: does the decision depend on the asset’s current state? Design-stage twins, commissioning twins, capacity studies and compliance documentation fail this test. They inform decisions about the asset as designed, as built or in aggregate. Live data adds cost and nothing else. A twin built to validate a production line before go-live, using as-built measurements, is a perfectly good twin with zero streaming. So is a quarterly reliability model.

Question 2: is a human in the loop? If a person reviews before acting, the human’s reaction time sets the floor, typically seconds to hours. Anything faster than the reviewer can use is waste. This is why most dashboards and alerting twins live comfortably at near-real-time. When humans are involved, “real-time” has a ceiling of roughly human response, and engineering effort beyond that ceiling does not improve outcomes.

Question 3: is the consequence window shorter than about a second? Only when an automated actuator acts and the cost of a late action is a fault does real-time become necessary. Even then, the correct architecture puts the loop at the edge, and the twin supervises it.

Cases where real-time is genuinely necessary

Closed-loop motion and process control. Deadlines come from the physics and the control design.
Safety functions. Protective and safety-rated logic has strict response-time requirements defined by functional-safety standards, and is implemented in certified controllers, not in analytics platforms.
Grid and power electronics balancing. Frequency response and protection operate on sub-second timescales.
Teleoperation and haptic feedback. Perceived latency constraints are tight because a human is the closed-loop element.
High-rate machine vision gating. Rejecting a part on a moving line has a physical window.

Cases where “real-time” is mostly a myth

Predictive maintenance on slow-degrading assets. The failure physics is hours to months.
Energy and sustainability reporting. Metering resolution is typically minutes to hours, and decisions are monthly.
Asset-lifecycle and PLM twins. Their value is traceability across revisions, not speed.
Capacity, layout and scenario planning. These run on aggregated history by definition.
Digital twins for training and as-built documentation.

A useful sanity check is to ask the vendor or the team: “If this feed were fifteen minutes late, which decision would get worse, by how much, and what would it cost?” If nobody can name one, you do not need the feed at that speed.

The hybrid pattern that usually wins

Most industrial twins end up as a hybrid with three data paths, which is also the pragmatic reading of the standards. A hot path runs at the edge and handles control and protection with deterministic latency; the twin does not sit in it. A warm path streams selected, aggregated or change-triggered data to the twin for monitoring, diagnosis and short-horizon prediction at seconds-to-minutes freshness. A cold path moves full-fidelity history and engineering data in batches for model training, simulation, calibration and audit. A single platform serves all three, and the cadence is a per-signal and per-decision setting. Our unified namespace architecture article shows how the warm path can be organized so that consumers subscribe to current state without point-to-point integrations, and the NATS JetStream vs Kafka comparison covers the broker choice behind it.

The role of model fidelity and calibration

One more argument against the myth comes from what actually limits twin quality. Many twins fail not because their data is old but because their models drift. A physics-based thermal model whose parameters were calibrated at commissioning slowly diverges as fouling, wear and ambient change accumulate. Feeding it fresher sensor data does not fix a miscalibrated model; periodic recalibration against reconciled history does. In such systems the most valuable synchronization is a slow loop that updates model parameters weekly or monthly, while the fast loop merely updates state. Treating all synchronization as one speed knob misses the distinction between state estimation (fast, noisy) and parameter identification (slow, careful). The TwinOps lifecycle architecture treats this as a release-management problem: versioned models, tested calibrations and controlled promotion.

Trade-offs, Gotchas, and What Goes Wrong

Treating real-time as mandatory is not harmless overcaution. It creates costs, and it also hides failure modes that batch designs do not have.

Infrastructure cost scales with sample rate, value does not. The illustrative arithmetic above shows a 60x volume difference between per-second and per-minute sampling of the same signals. Broker partitions, storage tiers, retention policies and network links all follow volume. For decisions that saturate early, the extra spend buys nothing.

Fragility grows with moving parts. A streaming pipeline can suffer broker backpressure, consumer lag, dropped sessions, clock skew between edge devices and servers, duplicate delivery and out-of-order events. Each needs detection and a runbook. A batch twin that loads a reconciled file simply has fewer ways to be wrong at 3 a.m.

Out-of-order and late data corrupt live state silently. A stream-fed twin must decide what to do with an event that arrives after a newer one. Without event-time handling and watermarks, state flips backwards. Batch pipelines settle ordering before the twin sees the data.

Stale-but-confident is the dangerous failure. The worst behaviour of any twin is displaying a last-known value as if it were current after the link has failed. Every twin, at any cadence, should carry a timestamp and quality flag per value and render “unknown” or “stale since” rather than a frozen number. This is a bigger risk for twins sold as live than for twins honest about their cadence, because users trust the label.

Clock discipline is part of the data. Data age is meaningless if device clocks disagree. Edge devices need time sync appropriate to the class (NTP is typically adequate for seconds-level monitoring; tighter classes need PTP or hardware timestamps).

Alert fatigue. Streaming everything with naive thresholds yields a flood of low-value alarms. More frequent data does not create more insight without filtering and context.

The twin in the safety path. Anti-pattern: wiring an analytics-platform twin into a safety or deterministic loop because the vendor demo made it look easy. Certified controllers exist for this. Keep the twin supervisory.

Under-engineering is real too. A batch twin cannot catch a fast-developing fault. The honest limit of the thesis here: if you choose batch for a decision that actually has a short consequence window, you have made the opposite mistake. The data-age budget protects against both errors because it forces you to write the consequence window down.

Labels versus reality. Many products labelled “real-time” are near-real-time at best, with batching intervals of seconds hidden in gateways. If the budget matters to you, measure end-to-end data age with a probe signal (a timestamped heartbeat injected at the source) rather than trusting the spec sheet.

Practical Recommendations

Design cadence deliberately, from the decision backward to the feed. Begin by listing every decision the twin will support, who or what makes it, and how often. For each, write the consequence of acting on data of age X, then find the largest X that is still acceptable and divide by a margin of at least five to ten. The tightest decision sets the class for that signal, but not for the twin: signals feeding slower decisions can stay on slower paths.

Prefer report-by-exception and edge aggregation over raw streaming. Capture features at the edge (statistics per window, threshold crossings, spectral peaks) and keep raw waveforms in a local buffer that can be pulled on demand when an anomaly fires. That gives near-real-time insight at near-batch cost.

Make time a first-class field. Every record needs an event timestamp, an ingestion timestamp and a quality code. Compute data age continuously and expose it on the dashboard.

Plan the failure behaviour before the happy path: what does the twin show during an outage, how does it backfill afterwards, and who is told. Finally, let the twin earn speed. Start with the cheapest class that satisfies today’s decisions, instrument data age, and move individual signals up the staircase only when a named decision justifies the next step.

Checklist

[ ] List decisions, decision-makers and decision frequency before choosing any transport.
[ ] Write the consequence of stale data per decision; derive the maximum acceptable data age.
[ ] Apply the three-question test: current state, human in loop, sub-second window.
[ ] Keep hard-deadline loops in edge controllers; keep the twin supervisory.
[ ] Separate state synchronization (fast, light) from model recalibration (slow, careful).
[ ] Use deadbands and edge aggregation before raw streaming.
[ ] Timestamp everything; show staleness; never display frozen values as live.
[ ] Measure end-to-end data age with a heartbeat probe; do not trust spec sheets.
[ ] Re-evaluate per signal as new decisions arrive; budget the next staircase step explicitly.
[ ] Treat vendor claims of ISO 23247 conformance, especially for the new Parts 5 and 6, as unverified until a conformance scheme exists.

Frequently Asked Questions

Does a digital twin need real-time data?

No. Standards define a twin by a maintained connection to a specific physical entity at an appropriate or fit-for-purpose synchronization rate, not by a speed. ISO/IEC 30173 says “appropriate rate of synchronisation,” and ISO 23247 requires synchronization without a latency figure. Plenty of production twins run on nightly batches or event-driven updates. Real-time data becomes necessary only when an automated decision acts on current state inside a very short consequence window, such as closed-loop motion control.

What is the difference between a digital twin and a digital shadow?

In the Kritzinger et al. 2018 classification, the difference is data-flow automation, not speed. A digital shadow receives automatic updates from the physical asset but changes in the model do not flow back automatically. A digital twin has automatic flow in both directions. A fast read-only dashboard is therefore a shadow, while a slower system that automatically writes setpoints back qualifies as a twin under that taxonomy. Other authors use looser definitions, so check which one a vendor means.

What is the difference between real-time and near-real-time for a digital twin?

Real-time means a hard deadline: a late result is a fault, as in servo control or protection, with latencies from microseconds to milliseconds. Near-real-time means data flows continuously with delay of seconds to a few minutes, and lateness only delays an alert or an insight. Most monitoring and predictive-maintenance twins are near-real-time. A dashboard refreshing every second is fast, but it is not real-time in the engineering sense unless missing an update causes failure.

How do I decide how often my digital twin should update?

Work backward from decisions. For each decision, estimate how stale the data can be before the outcome worsens, then apply a safety margin of at least five to ten times. Take into account the physical process: a slowly changing quantity gains nothing from fast sampling. The tightest decision sets the class for its own signals only. Start with the cheapest class that satisfies today’s needs, measure end-to-end data age, and upgrade a signal only when a named decision requires it.

Is a digital twin different from a simulation if it is not live?

Yes. The distinguishing feature is the bound, maintained connection to a specific identified physical asset, not the speed of that connection. A simulation explores scenarios on a model that is not tied to one asset’s actual state. A twin, even a batch-updated one, is calibrated against and synchronized with a particular asset over its life. A twin refreshed after each inspection still reflects that asset’s real history, which a generic simulation does not.

Does streaming data make a digital twin more accurate?

Not necessarily. Accuracy depends on model fidelity, calibration, sensor quality and data hygiene as much as on freshness. Fresher data helps only if the decision is sensitive to age and the model is good enough to use it. A miscalibrated model fed live data is confidently wrong. Many twins gain more from periodic recalibration against reconciled batch history than from higher sampling rates, and batch data is often cleaner because late and duplicate records are settled before use.

References

ISO 23247-1:2021, Automation systems and integration – Digital twin framework for manufacturing – Part 1: Overview and general principles. ISO/TC 184/SC 4. https://www.iso.org/standard/75066.html
ISO 23247-5:2026, Part 5: Digital thread for digital twin. https://www.iso.org/standard/87425.html
ISO/IEC 30173:2023, Digital twin – Concepts and terminology. Definition as quoted in https://www.designingbuildings.co.uk/wiki/Has_ISO_answered_the_question_%22What_is_a_digital_twin%E2%80%9D%3F
Kritzinger, W., Karner, M., Traar, G., Henjes, J., Sihn, W. (2018). Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51(11), 1016-1022. DOI 10.1016/j.ifacol.2018.08.474
Digital twin integration level (summary of Kritzinger classification). https://en.wikipedia.org/wiki/Digital_twin_integration_level
Digital twin history (Grieves 2002 to 2006 models; Vickers 2010). https://en.wikipedia.org/wiki/Digital_twin
Shannon, C. E. (1949). Communication in the presence of noise. Proceedings of the IRE 37(1), 10-21.

By Riju – about

Does a Digital Twin Need Real-Time Data? A Fact-Check