Digital Twins Explained: How Virtual Models Connect to Real-World Systems

A factory manager may want to know why a motor is vibrating. An energy operator may want to test a storage schedule before changing a grid asset. An aircraft engineer may want to compare maintenance scenarios for one specific airframe rather than for the average of a fleet. In each case a digital model can help, but a drawing or simulation becomes far more useful when it stays connected to the system it represents.

A digital twin is a digital representation of a physical or operational system that is kept up to date with data from its counterpart and used to understand, predict, or decide. It is not necessarily a photorealistic 3D model, and a 3D model is not automatically a twin. This article explains what the term means, where it came from, how the data loop works, where twins are used, and why most of the hard work is validation rather than visualization.

What a digital twin is, according to the people who define it

The most careful definition in recent years comes from the National Academies of Sciences, Engineering, and Medicine. In a 2024 consensus report sponsored by the Department of Defense, the Department of Energy, the National Institutes of Health, and the National Science Foundation, a committee chaired by Karen Willcox proposed that a digital twin is "a set of virtual information constructs that mimics the structure, context, and behavior of a natural, engineered, or social system (or system-of-systems), is dynamically updated with data from its physical twin, has a predictive capability, and informs decisions that realize value." The same wording was quoted in a 2024 federal request for information, which also repeated the report's central point: "The bidirectional interaction between the virtual and the physical is central to the digital twin."

Four ideas sit inside that sentence. The model mimics a particular system, so it needs an identity. It is updated with data, so it needs a connection. It has predictive capability, so it needs a model that can be checked. And it informs decisions, so it needs a purpose. If any of the four is missing, the thing may still be a useful piece of software, but calling it a twin overstates what it does.

The report's own summary is blunt on the point that matters most for newcomers: "A digital twin is more than just simulation and modeling," in the words of Finding 2-1 in the National Academies report. A simulation explores what a model would do under chosen inputs. A twin adds a live or periodic data link to a real counterpart and a feedback path into decisions.

The National Institute of Standards and Technology (NIST) uses a shorter, manufacturing-focused version. Its digital twins program page describes twins as "synchronized virtual models that help manufacturers represent, diagnose, predict, and optimize their operations." The two definitions agree on the essentials: the model is tied to something real, and it is meant to change what people do.

Direct answer: A digital twin is a model of a specific real asset, process, environment or system that is connected to its counterpart through data and used throughout its life to monitor, diagnose, simulate, predict, or plan. A dashboard, CAD file, or static simulation may be part of a twin but does not become one by being digital. Whether the twin deserves trust depends on sensors, model assumptions, calibration, update frequency, security, and continual validation.

Where the idea came from

Engineers have long built models of machines, and mission control rooms have long kept ground replicas of spacecraft. The idea that the replica should be a data-driven model tied to one particular vehicle took shape in aerospace. In a conference paper presented in April 2012 at a special session on the digital twin in Honolulu, NASA Langley's Edward Glaessgen and the Air Force Office of Scientific Research's David Stargel argued that future NASA and U.S. Air Force vehicles would need to be lighter while carrying higher loads, enduring harsher conditions, and flying longer service lives. They said that certification and fleet-management methods built on statistical material data, physical testing, and assumed similarity between tests and real operations would likely fall short. Their proposed "paradigm shift" was a digital twin that combines ultra-high-fidelity simulation with a vehicle's onboard health management system, maintenance history, and fleet data so that it mirrors the life of its flying counterpart. The paper is archived on the NASA Technical Reports Server as AIAA Paper 2012-1818.

Who first used the phrase is contested, and accounts differ on the dates and on who named it. The concept grew out of product lifecycle management and aerospace sustainment, which is why both product engineers and fleet maintainers still use the word in slightly different ways. Mission-control simulators, which engineers have long used to rehearse fixes for spacecraft, are better read as precursors to the idea than as early twins, because they had no automated data link to the vehicle.

The spectrum from model to shadow to twin

Many projects described as digital twins sit at different points on a spectrum. A widely cited 2018 literature review by Kritzinger and colleagues in the journal IFAC-PapersOnLine (DOI 10.1016/j.ifacol.2018.08.474) separated three levels of integration: a digital model, a digital shadow, and a digital twin. The distinction is about how data moves between the physical and digital sides.

Level	Data from physical to digital	Data from digital to physical	Example
Digital model	Manual, if any	Manual, if any	CAD geometry, a finite-element model, a wiring diagram
Digital shadow	Automatic, from sensors or logs	Manual, through a person reading results	A dashboard that mirrors a machine's state and runs analytics
Digital twin	Automatic	Automatic or approved feedback into control or planning	A model that adjusts a schedule or setpoint within limits

The terminology is not perfectly standardized across industries, and the National Academies report stresses that the bidirectional interaction between the virtual and the physical is central to a twin. In practice, many systems sold as twins are shadows, and many valuable systems are models. That is fine as long as the claim matches what exists. A static model can be highly valuable without receiving live data, and it often forms the foundation on which a twin is later built.

The interactive end of the spectrum raises the stakes. Once a recommendation can reach a controller, an error can have a physical consequence, so safety review, authorization, and rollback have to be designed in. A shadow that is wrong produces a bad chart. A twin that is wrong and connected to equipment can produce a damaged machine.

What has to exist before a model counts as a twin

Identity

The digital object has to correspond to a particular physical counterpart. A generic motor model is not a twin of motor 17 in a named facility. Identity links the model to a serial number, location, configuration, repair history, and software version. Without it, a twin can quietly analyze the wrong object after a part is swapped or a line is reconfigured.

Connection

The twin needs a data relationship with the counterpart. It may receive temperature, vibration, energy use, position, maintenance events, operator observations, or external conditions such as weather. The connection can be continuous, periodic, or event-driven. "Live" is not a specification. A twin that updates every 15 minutes may be perfect for a building and useless for a robot arm.

State and history

A twin represents current or estimated state and preserves enough history to interpret change. A sensor reading without a timestamp, calibration record, and context is hard to use. History also supports root-cause analysis, and it is the raw material for checking whether the model was right.

Model and purpose

A twin can use physics, statistics, machine learning, rules, or a combination. Each model has a stated purpose, such as visualization, anomaly detection, forecasting, scenario analysis, maintenance planning, or control. A model that is valid for one purpose may be unsuitable for another. A model tuned to detect a fault early may be poor at predicting the exact day of failure.

Put simply, fidelity and resolution should match the decision, not the other way around. A twin that models every bolt to answer a question about daily energy use is expensive in the wrong place.

The data loop, stage by stage

A typical twin follows a loop: observe the physical system, transmit data, clean and contextualize the stream, update the digital state, run a model, present evidence or a recommendation, and optionally send an approved action back. Each stage has its own failure modes.

Think of the loop as a ship's navigation team. Sensors are the lookouts, the data pipeline is the radio room, the state estimate is the position on the chart, and the model is the plan for the next leg. A lookout who misreads a landmark, a garbled radio message, or a chart that has not been updated can each put the ship in the wrong place, and the captain sees only the final dot on the map.

Sensors can drift or fail. Networks can delay or drop messages. A parser can change units from degrees Celsius to Fahrenheit without warning. A model can extrapolate beyond the conditions it was calibrated for. An operator can misread uncertainty. A control command can be valid in simulation and unsafe in the real environment. Good twins therefore record confidence, timestamp, source, quality, and action status alongside every value.

A worked example with invented numbers

Consider a hypothetical cooling pump in a plant. The following figures are illustrative, not measurements from a real facility. The pump has a bearing temperature sensor sampled once per second and a vibration sensor that reports a root-mean-square (RMS) value every minute. The twin holds a physics model of heat generation and cooling in the bearing, plus a statistical baseline built from three months of normal operation.

One afternoon the bearing temperature rises 6 degrees Celsius above what the physics model predicts for the current load and ambient temperature, while vibration RMS stays within 5 percent of baseline. A shadow would plot the temperature and leave interpretation to a person. A twin goes a step further: it checks whether the deviation is explained by a known cause (a hotter day, a higher flow rate), notes that a neighboring pump with the same configuration shows no deviation, and flags a likely sensor or lubrication issue with a confidence value. The human maintainer then inspects the pump, and the result of that inspection (sensor fault or real wear) is written back as a labeled event that improves the next prediction.

Nothing in that sequence required a 3D model, artificial intelligence, or a cloud platform. It required an identity (this pump), a connection (two sensors), a model with a stated purpose (detect abnormal heating), and a feedback path (an inspection record). That is the minimum that makes the word "twin" defensible.

Sensors and state estimation

Sensors rarely measure every variable of interest. A battery-management twin may observe voltage, current, and surface temperature while estimating internal state of charge and health. A building twin may observe energy use and carbon dioxide levels while inferring occupancy. A production twin may observe output and vibration while estimating tool wear.

State estimation combines measured data with a model and an account of uncertainty. Filters such as the Kalman filter, a family of methods that blend a model's prediction with a noisy measurement and weight each by how much it is trusted, are common building blocks. The analogy is dead reckoning combined with a periodic GPS fix: the model carries the estimate forward between measurements, and each new measurement corrects the drift. A good system shows when an estimate rests on strong observations and when it is mostly extrapolation. A missing sensor should never silently become a confident value.

Calibration, placement, and sampling rate matter more than sensor count. More sensors are not automatically better if they produce inconsistent data, increase the attack surface, or create a maintenance burden. Measurement design should follow the decision the twin is meant to support, and the Internet of Things infrastructure that carries the data has to be designed with the same discipline. Some twins also rely on 3D sensing; our explainer on how LiDAR works shows how laser ranging produces the point clouds that feed building and terrain models.

Latency is its own design variable. A twin that supports a control loop in a robot cell needs data in milliseconds and a bounded delay. A twin that supports a quarterly maintenance plan can tolerate hours. That difference decides whether processing happens at the edge, close to the machine, or in a data center, a trade-off explored in our piece on edge computing and federated learning.

Simulation, prediction, and the limits of "what if"

A twin can run "what-if" scenarios: change a maintenance schedule, vary the weather, adjust a production parameter, or apply a load. The result is conditional on the model, the inputs, and the assumptions. It is not a guaranteed forecast.

Physics-based models are interpretable because they encode known laws such as heat transfer or structural mechanics, but they can be expensive to run or incomplete when the physics is messy. Machine-learning models capture patterns from data and run fast once trained, but they can fail when conditions move outside the training range. Hybrid approaches combine them, for example by letting a learned component correct the residual error of a physics model. Our article on physics-informed neural networks describes one way of building laws into a learning system. Hybrids also create interfaces where units, assumptions, and uncertainty have to be checked.

A scenario result should name which inputs were changed, which were held constant, the time horizon, the model version, and the uncertainty range or known limitation. A colorful simulation is not evidence that the real system will behave identically.

Where digital twins are used

Manufacturing

Manufacturing twins may connect product design, machine settings, process data, quality inspection, maintenance, and supply information. They support virtual commissioning (testing control logic against a virtual line before the physical line exists), bottleneck analysis, predictive maintenance, and traceability.

A twin can help distinguish a defect caused by raw-material variation from one caused by machine alignment or temperature. It can also reveal that the data pipeline itself changed. The value depends on linking data across the product lifecycle rather than building an isolated visualization.

Standards are part of the story. ISO 23247, "Digital Twin Framework for Manufacturing," was published in 2021. NIST states on its program page that the lack of standards for vocabulary, design, interoperability, trustworthiness, and verification and validation is a main barrier to adoption, especially for smaller manufacturers. NIST has also proposed adding a verification, validation, and uncertainty quantification framework as Part 7 of ISO 23247 and is implementing Part 5, which covers the digital thread. Industrial environments add safety and operational technology concerns: a recommendation that changes a controller must pass authorization, change management, and fail-safe review.

Earth systems

The largest twin projects model planets rather than machines. Destination Earth, an initiative of the European Commission implemented by the European Centre for Medium-Range Weather Forecasts (ECMWF), the European Space Agency, and the European Organisation for the Exploitation of Meteorological Satellites, held its Phase II launch on June 10, 2024 at the LUMI supercomputer center in Kajaani, Finland. ECMWF says more than 90 partner institutions are involved.

Its two initial twins show how differently a twin can be scoped. The Climate Change Adaptation Digital Twin aims to produce multi-decadal climate projections from global to local scales, at 5 to 10 km global resolution with hourly output. The Weather-induced Extremes Digital Twin targets extreme weather and its impacts two to four days ahead, with a 4.4 km global component and a regional component at 500 to 750 meters. These are the implementing organizations' own descriptions of the project, not independent evaluations of how well the twins perform.

This is also a case where the "twin" label has a looser meaning than in a factory. The planet cannot be instrumented like a pump, and a climate model does not steer the climate. The data link is continuous assimilation of observations into a model, and the feedback is decisions by planners and emergency services, not control signals.

Energy systems and infrastructure

Energy twins can represent generation, storage, buildings, substations, or whole networks. They may combine weather, load, asset condition, and market or operational signals. A planning twin can test scenarios without sending commands. An operational twin may support live decisions about dispatch or maintenance. Our article on how AI optimizes renewable energy grids covers the forecasting side of this work.

Our grid-scale battery storage article explains why storage behavior depends on chemistry, power, duration, degradation, and system context. A twin of a storage asset has to represent those constraints rather than treating a battery as a single capacity number. Critical infrastructure twins also need resilience: if the twin is unavailable, the physical system must still operate safely.

Buildings and cities

Building twins combine geometry, heating and cooling systems, occupancy, energy use, air quality, and maintenance. The smart buildings and AI article describes how machine learning reduces heating and cooling energy use, which is a typical building-twin task. City-scale systems may integrate traffic, utilities, weather, and land-use information. Projects of this kind raise governance questions because the data can describe people's movements and routines.

A city model should not imply that all residents are represented equally or that a prediction about a neighborhood is a fact about every person. Aggregation can protect privacy but may hide distributional effects. A model that optimizes traffic may move congestion rather than eliminate it.

Aerospace and spacecraft

Aerospace remains the home turf of the idea. Fleet twins track the usage history of individual airframes or engines and compare each to simulation, which is what the 2012 NASA and Air Force paper proposed for structures and materials. Spacecraft add a twist: the vehicle cannot be reached for repair, and communication delays prevent real-time control from the ground. That is why onboard autonomy matters, as described in our article on AI and autonomous spacecraft navigation.

Healthcare boundaries

Digital twins in health research may model physiology, treatment scenarios, or hospital operations. The National Academies committee reported that, based on what it heard during its information-gathering sessions, the publicity around digital twins currently outweighs the evidence base of success. That caution applies with extra force in medicine. A model connected to a patient is not automatically a validated clinical decision tool. Measurement quality, biological assumptions, the population on which the model was validated, and regulatory status all matter.

This article does not provide medical advice. A health-related twin should be treated as research or decision support unless it has been evaluated and authorized for a specific clinical use.

An architecture checklist

The table below lists the layers a mature twin may contain, the evidence that a layer works, and what goes wrong when it is missing.

Twin element	Main function	Evidence to validate	Failure if missing
Identity registry	Links model to counterpart	Asset IDs, configuration, and lifecycle record	Wrong object is analyzed
Data acquisition	Observes state and events	Calibration, timestamps, and quality flags	Garbage or stale inputs
Data context	Adds units, location, and meaning	Ontology and metadata checks	Incompatible values are combined
State model	Estimates current condition	Ground truth and uncertainty	False precision
Simulation	Tests scenarios	Backtests and domain validation	Plausible but wrong scenarios
Interface	Supports human interpretation	Usability and uncertainty tests	Operators overtrust visuals
Action layer	Sends recommendation or control	Authorization, safety, and rollback	Physical side effects
Governance	Controls access and change	Logs, reviews, and ownership	Unaccountable system behavior

A twin can deliver value without every layer, but the scope and claims should match what exists. A monitoring-only twin can skip the action layer. It cannot skip identity or data quality.

Verification, validation, and uncertainty quantification

The National Academies report treats verification, validation, and uncertainty quantification, abbreviated VVUQ, as essential to responsible twin development. The three terms answer different questions.

Verification asks whether the model was built right: does the code solve the equations it claims to solve, without bugs? Validation asks whether it is the right model: do its predictions match reality for the intended use? Uncertainty quantification asks how sure the model is: what range of outcomes is consistent with the data, the parameters, and the noise? A weather forecast that says "40 percent chance of rain" is an uncertainty statement, and a twin should be able to produce statements of the same kind.

Calibration is not validation

Calibration adjusts model parameters so the model matches observations. A model can fit historical data very well and still fail in a new operating regime, in the way a student who memorized last year's exam can ace the practice test and fail the real one. Calibration records should state the data period, operating conditions, parameters, and objective.

Validation tests the model on data or conditions not used for calibration, and the test has to reflect the decision. A twin used for rare-failure detection may need long historical periods and careful handling of imbalance, because failures are far outnumbered by normal operation. A twin used for control needs safety tests under abnormal conditions.

Validation never finishes

The report's Conclusion 2-2 says that digital twins require VVUQ to be a continual process, adapting as the physical system, the models, the data, and the decision task change. That fits what happens in practice. Equipment ages, software updates change behavior, sensors are replaced, production recipes shift, and weather patterns vary. A twin that was accurate at commissioning can drift without anyone noticing.

Alerts should therefore distinguish three things that look alike on a chart: model drift (the model is getting worse), sensor failure (the data are wrong), and real physical change (the system itself is different). Treating them as the same event is the most common reason a twin loses the trust of the people who use it.

Communicating uncertainty clearly to end users is part of decision support. In plain terms, a number with no error bar invites overconfidence.

Interoperability and the digital thread

A twin rarely lives alone. It may exchange data with enterprise systems, maintenance platforms, product-lifecycle tools, industrial controllers, building-management systems, and cloud services. That requires shared identifiers, units, time semantics, schemas, access policies, and versioning.

A digital thread links information across design, manufacturing, operation, and disposal. The thread is valuable only when the identity and meaning of data survive each transfer. Copying values between incompatible systems can create a detailed but misleading twin, in the same way that a translated document can keep every word and lose the meaning. Open standards help, but "open" does not guarantee semantic compatibility. Test real workflows and document the mappings.

Security and safety

A twin increases the number of systems that hold information about an asset and may create new paths toward operational technology. Protect APIs, identities, devices, data stores, model packages, and control interfaces. Apply network segmentation and least privilege, and treat sensor data and external commands as inputs that need validation. Our overview of cybersecurity threats in 2026 is a useful companion for the threat landscape around connected industrial systems.

A non-operational twin may still reveal facility layout, maintenance schedules, or vulnerabilities. The confidentiality of the model can matter even when it cannot directly control equipment.

For interactive twins, define fail-safe behavior, human approvals, command limits, rate limits, rollback, and manual operation up front. A model should never be allowed to turn an uncertain prediction into unbounded control. When a twin supports many models and agents in production, AI observability practices, such as logging inputs, outputs, and drift, apply directly.

Cost, lifecycle, and when a twin is the wrong tool

A twin requires ongoing data engineering, sensor maintenance, model updates, cloud or edge infrastructure, security review, and domain ownership. The initial visualization may be easy. Keeping identity, data quality, and calibration correct over years is harder, and it is where many projects stall.

A useful business case compares the decision improvement with the lifecycle cost. Predictive maintenance is not automatically valuable if inspection is already cheap, failures are rare, or the intervention itself creates more downtime than it prevents. A pilot should define the decision, the baseline, the success measure, and a stop condition before any sensors are bought.

Situation	Better fit	Why
Stable system, no live decision needed	Static engineering model	Live data add cost without changing any decision
Task is record retrieval or reporting	Conventional database	A model adds nothing the query does not already give
Goal is to display measured values	Simple dashboard (a shadow)	More transparent than a complex model
Decision depends on unseen internal state or on testing scenarios safely	Digital twin	Estimation and what-if analysis change the decision
Physical testing is expensive or unsafe	Twin plus targeted physical validation	Reduces, but does not replace, real tests

The twin label should not be used to justify unnecessary integration. Ask whether a live model changes a decision, reduces uncertainty, or enables a safer experiment. If not, a smaller system is easier to maintain.

Common misconceptions

"A twin is a 3D model." Geometry is one possible component. Many useful twins have no 3D view at all, and many impressive 3D scenes have no data connection.

"Twins always run in real time." Update frequency should match the decision. Some twins update continuously, others hourly, others after each event or each shift.

"Twins require artificial intelligence." Some use machine learning, but a twin built on physics and rules is still a twin. AI adds capability and adds validation burden.

"A twin predicts the future." It estimates outcomes under stated assumptions, with uncertainty. Prediction quality depends on sensors, labels, model validation, operating conditions, and how often the event being predicted actually happens.

"A twin replaces physical testing." It reduces some experiments and enables scenarios that are costly or unsafe to run for real. Physical validation remains the check on the model.

Limitations

Digital twins are models, not the physical world. Sensors can be incomplete, stale, biased, or compromised. Calibration can overfit historical data. Simulation can hide assumptions. A machine-learning component can drift. A polished interface can create false confidence. A connected twin can expand privacy, cybersecurity, and availability risks.

Claims of "real-time," "predictive," or "autonomous" should be scoped to a specific implementation. The term has no single universal architecture or accuracy guarantee, and the National Academies committee itself cautioned that publicity currently outruns evidence. Twins in healthcare, public infrastructure, and industrial control require domain-specific validation and governance. This article is an educational systems overview, not a safety certification or procurement recommendation.

The takeaway

The useful way to think about a digital twin is as a relationship rather than a product. A model becomes a twin when it is tied to one real system by data, when that tie runs in both directions at least through human decisions, and when someone keeps checking that the model still deserves trust. The visual layer is the least important part and the easiest to build.

That is why the National Academies treats verification, validation, and uncertainty quantification as a continual requirement and why NIST focuses on standards for vocabulary, interoperability, and trustworthiness. A twin with a clear purpose, honest error bars, and a validation routine is worth building. A twin that is mostly a rendering is a dashboard with better marketing.

Frequently asked questions

Q: What is a digital twin? A: It is a digital representation of a physical, engineered, or social system that is updated with data from its real counterpart, can make predictions, and informs decisions. The National Academies definition adds that the interaction between the virtual and the physical runs in both directions.

Q: Is a 3D model a digital twin? A: Not by itself. A 3D model can be one component, but a twin also needs a defined counterpart, a data connection, state or lifecycle context, and a purpose. A static 3D model is a digital model, not a twin.

Q: What is the difference between a digital twin and a simulation? A: A simulation explores a model under chosen inputs. A twin is connected to a real counterpart and uses current or historical data, with a feedback path into decisions. A twin may run simulations, but not every simulation is a twin.

Q: What is a digital shadow? A: In the classification of Kritzinger and colleagues, a digital shadow receives data automatically from the physical system but sends results back only through people. A dashboard that mirrors a machine and runs analytics is a typical shadow.

Q: Do digital twins need artificial intelligence? A: No. A twin can use physics, rules, statistics, machine learning, or a hybrid. AI is one option, and it adds validation work because learned models can fail outside their training conditions.

Q: How do you know whether a digital twin is accurate? A: Through verification, validation, and uncertainty quantification. That means checking the code, testing predictions against data not used for calibration, reporting the uncertainty, and repeating the process as the system changes. The National Academies calls this a continual process.

Q: Can a digital twin control a machine? A: Some interactive twins send control signals or approved recommendations. Safety review, authorization, command limits, human oversight, and manual fallback are essential because an error can have a physical consequence.

Sources

• National Academies of Sciences, Engineering, and Medicine (2024), Foundational Research Gaps and Future Directions for Digital Twins: definition, Finding 2-1, VVUQ conclusions.
• U.S. Government Publishing Office (2024), Federal Register notice, June 18, 2024: quoted National Academies definition.
• NIST, Digital Twins for Advanced Manufacturing: definition, ISO 23247 status, standards gaps.
• Glaessgen and Stargel (2012), The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles, NASA Technical Reports Server.
• ECMWF (2024), EU's Destination Earth Phase II is inaugurated: phase launch, twins, resolutions.
• Kritzinger et al. (2018), Digital Twin in manufacturing: A categorical literature review and classification, IFAC-PapersOnLine, DOI 10.1016/j.ifacol.2018.08.474.

This article is educational and does not certify a digital-twin implementation or industrial-control system.