The engineering value of a digital twin comes from something deeper than any single screen.
A machine model displayed on a screen is not automatically a digital twin.
Neither is a dashboard showing live sensor data.
Neither is an offline simulation simply because it represents a real piece of equipment.
All three can become parts of a digital-twin system, but the engineering value of a digital twin comes from maintaining a useful relationship between a physical system, its digital representation, and the information required to keep that representation relevant to a real decision.
That distinction matters because "digital twin" has become one of the most broadly used terms in Industry 4.0.
ISO/IEC 30173:2023 establishes formal concepts and terminology for digital twins, including digital-twin system context, lifecycle processes, functional views and stakeholders. In manufacturing, the ISO 23247 series provides a framework specifically for digital twins of manufacturing systems.
NIST's advanced-manufacturing work describes digital twins as synchronized virtual models that can help manufacturers represent, diagnose, predict and optimize physical operations. It also emphasizes that implementing them reliably requires much more than visualization: relevant data, interoperability, model credibility, verification, validation and uncertainty all matter.
That leads to the engineering question that matters more than the terminology:
“What does a digital twin need to know about the physical system, and what decision becomes better because the twin exists?”
A digital twin should begin with an engineering problem
A common mistake is to start with:
“We want a digital twin.”
Then begin collecting every available signal.
A better starting point is:
“What engineering problem are we trying to solve?”
Examples include:
- Predicting spindle thermal error
- Monitoring bearing condition
- Optimizing production flow
- Evaluating machine loading
- Predicting maintenance requirements
- Testing process changes before physical implementation
- Estimating energy consumption
Those problems require different models and different data.
A digital twin intended to support thermal compensation may need:
- Temperature measurements
- Spindle operating conditions
- Cooling state
- A thermal model
A digital twin intended to monitor bearing health may need:
- Vibration
- Speed
- Load
- Maintenance history
- Degradation models
The phrase digital twin therefore describes a system concept.
It does not prescribe one universal model or dataset.
NIST similarly emphasizes identifying digital-twin requirements and formulating the problem before collecting relevant data and developing models.
How a manufacturing digital twin works
A useful simplified architecture is:
Physical system ↕ data and interfaces ↕ digital representation → analysis and engineering decision
The physical side might contain:
- Machine
- Tooling
- Actuators
- Sensors
- Controller
- Manufacturing process
The interface transfers the information required by the digital representation.
The digital side may contain:
- Geometry
- Operating state
- Physical models
- Data-driven models
- Production history
- Maintenance history
- Simulations
The result may then support:
- Monitoring
- Prediction
- Diagnosis
- Optimization
- Control
- Maintenance decisions
The important feature is the relationship between these parts.
NIST's work around ISO 23247 emphasizes a manufacturing framework precisely because digital twins require defined relationships, interfaces and information exchange rather than isolated customized software components.
A 3D model is not enough
A CAD model can be extremely valuable.
It may capture:
- Geometry
- Dimensions
- Component relationships
- Assembly structure
But imagine a CNC spindle model.
The CAD model may represent the spindle perfectly geometrically while knowing nothing about:
- Current rotational speed
- Bearing temperature
- Vibration
- Operating load
- Maintenance history
It is a digital representation.
It is not yet providing a synchronized representation of the operating system.
This distinction helps prevent the term digital twin from being reduced to visualization.
A monitoring dashboard is not enough either
Now consider the opposite case.
A dashboard receives:
- Spindle speed
- Vibration
- Temperature
- Motor current
It displays them in real time.
That system has an active data connection to the physical machine.
But it may contain no meaningful representation of the machine beyond the displayed measurements.
It tells the engineer:
“Temperature is 72°C.”
It may not tell the engineer:
- Whether that temperature is expected at the current load
- What component behaviour it implies
- What future condition is predicted
- Which intervention would improve performance
Again, the dashboard is valuable.
It may even be all the system needs.
But live data alone does not automatically justify calling the system a digital twin.
The model can take several forms
A digital twin does not have to be one massive simulation.
Its digital representation can combine several model types.
Physics-based models
These use engineering relationships describing the physical system.
Examples include:
- Thermal models
- Structural models
- Kinematic models
- Dynamic models
- Fluid-flow models
Data-driven models
These learn patterns from historical or current data.
Examples include:
- Anomaly detection
- Fault classifiers
- Remaining-life models
- Regression models
Rule-based models
Engineering rules may represent:
- Limits
- Alarms
- Operating logic
- Maintenance criteria
Geometric models
CAD or other spatial models can represent:
- Components
- Configuration
- Dimensions
- Machine layout
Many useful twins combine several of these.
The correct combination depends on the engineering purpose.
What data does a manufacturing digital twin actually need?
One of the most expensive mistakes is assuming:
“More data equals a better twin.”
The twin needs the information required to maintain a useful representation for its intended decision.
That may involve several categories.
Asset and configuration data
The twin should know what physical system it represents.
Useful information might include:
- Equipment identification
- Model or configuration
- Component hierarchy
- Tooling
- Controller configuration
- Installed options
This becomes especially important when supposedly identical machines are configured differently.
Engineering-definition data
Depending on the application, the digital representation may require:
- CAD geometry
- Dimensions
- Materials
- Mass properties
- Tolerances
- Process plans
A manufacturing digital twin used for toolpath verification requires different engineering-definition information from one designed only for energy monitoring.
Controller and machine-state data
Modern equipment can already contain useful information in its controller.
Possible variables include:
- Spindle speed
- Feed rate
- Motor load
- Axis position
- Cycle state
- Program state
- Alarms
Before adding external sensors, the engineer should therefore ask:
“What information does the machine already know?”
That is the same principle that applies to IIoT retrofits.
External sensors should fill meaningful information gaps rather than duplicate existing data without a purpose.
Sensor data
When existing controller information is insufficient, additional sensors may measure:
- Vibration
- Temperature
- Pressure
- Current
- Force
- Flow
- Displacement
- Acoustic signals
But measurement should follow the physical phenomenon.
If the objective is monitoring bearing degradation, the useful signal depends on how the expected degradation manifests itself.
Adding ten unrelated sensors does not automatically improve the twin.
Process and quality data
A manufacturing twin may also need context such as:
- Cycle time
- Workpiece
- Material
- Tool state
- Production rate
- Process parameters
- Part quality
- Scrap or rework
This information helps separate machine change from normal process change.
For example, increased vibration during a heavier cutting operation may not indicate machine degradation.
Without process context, the digital representation can misinterpret what it observes.
Maintenance and lifecycle data
For maintenance-oriented twins, useful information may include:
- Inspection history
- Component replacements
- Failure events
- Lubrication
- Alarm records
- Repair history
Suppose vibration suddenly drops after a bearing replacement.
Without the maintenance event, a data-driven system may interpret the shift incorrectly.
Lifecycle context keeps the digital representation aligned with the physical asset as that asset changes.
The best twin does not necessarily have the most data
Imagine two systems.
System A collects 500 variables but nobody has clearly defined which decision they support.
System B collects vibration, speed, load and bearing temperature, because those variables correspond to a defined condition-monitoring objective.
System B may be the more useful engineering system.
The question should therefore be:
“What minimum information is sufficient to support the required decision with acceptable confidence?”
That approach also reduces:
- Storage
- Integration
- Sensor costs
- Maintenance
- Cybersecurity exposure
Does a digital twin need real-time data?
Not necessarily in the sense often implied by marketing.
The required synchronization rate depends on the engineering process.
Motion-control application
Machine position may require very fast updates.
Thermal model
Temperature may evolve much more slowly.
Predictive maintenance
Condition information might be processed periodically or event by event.
Long-term maintenance planning
Daily or even less frequent synchronization could be sufficient.
The important requirement is not:
“Maximum possible update frequency.”
It is:
“Adequate synchronization for the decision timescale.”
Collecting data faster than the physical phenomenon changes may add cost without adding useful information.
Model fidelity should match the decision
Another common assumption is that the most detailed digital representation is automatically the best.
It is not.
Consider a machine-temperature problem.
A detailed finite-element thermal model may represent:
- Geometry
- Materials
- Heat sources
- Convection
- Transient behaviour
That could be appropriate for some applications.
But if the only decision is whether the machine has reached a stable warm-up condition, a simpler model may provide sufficient information.
Greater model fidelity brings costs:
- More data
- Greater computational demand
- Calibration
- Development
- Validation
- Maintenance
The right question is:
“What is the simplest model capable of supporting this decision reliably?”
Digital twin versus conventional simulation
Offline simulation answers questions such as:
“What should this system do under these assumed conditions?”
A digital twin additionally maintains some relationship with a specific physical system.
That relationship allows the digital representation to incorporate actual information about:
- Current state
- Configuration
- History
- Operating conditions
The distinction matters.
A generic CNC thermal simulation can investigate how a machine type behaves.
A twin of a particular machine would need information that keeps the digital representation relevant to that physical machine.
Digital twin versus monitoring system
A monitoring system primarily tells us:
“What is happening?”
A more capable digital twin may support:
- What should be happening?
- Why might this be happening?
- What could happen next?
- What happens if we change something?
- Which action is preferable?
That added decision capability often comes from combining measured information with models.
But again, if the maintenance decision only needs a reliable threshold alarm, building a complete twin may be unnecessary.
Validation is not optional
A highly detailed digital model can still be wrong.
That makes validation one of the most important digital-twin engineering problems.
NIST's current advanced-manufacturing programme specifically emphasizes Verification, Validation and Uncertainty Quantification—VVUQ—for digital-twin data, models and results.
Useful questions include:
- Does the model reproduce the relevant physical behaviour?
- Across which operating conditions?
- How large is the error?
- Which assumptions dominate the result?
- Where does the model stop being trustworthy?
- What uncertainty exists in its prediction?
A twin developed for one operating envelope should not automatically be trusted outside it.
A concise principle is:
“A digital twin without validation is a digital representation with unknown credibility.”
The twin itself can become outdated
Suppose the physical machine changes.
A bearing is replaced. A sensor is moved. The controller firmware changes. A different tooling configuration becomes standard. The operating process changes.
The physical machine is no longer exactly the system represented when the twin was calibrated.
This means digital twins have a maintenance problem of their own.
The digital side may require:
- Configuration updates
- Model recalibration
- New sensor mapping
- Retraining
- Revalidation
NIST identifies developing, validating and maintaining digital-twin models as part of the implementation lifecycle.
This is easy to overlook when calculating project cost.
Digital twins for predictive maintenance
Maintenance is one of the most intuitive applications.
A maintenance twin might combine:
Physical machine → condition measurements → operating context → degradation model → prediction → maintenance decision
For a CNC spindle, the twin could potentially combine:
- Spindle operating state
- Vibration
- Temperature
- Load
- Maintenance history
- Modelled condition
The exact implementation depends on the failure mechanism and decision.
Importantly:
“A machine-learning model alone is not necessarily a digital twin.”
It can be one model inside the twin.
Similarly, a sensor network is not the twin.
It provides part of the physical-system information.
The engineering value comes from the complete relationship.
Digital twins for process optimization
Another application is asking:
“What happens if we change the process before physically changing it?”
A manufacturing twin might support investigation of:
- Production sequence
- Machine settings
- Cycle times
- Energy consumption
- Process bottlenecks
This is particularly attractive where physical experimentation is expensive, disruptive, unsafe or time-consuming.
In such cases, the twin can provide a controlled digital environment for evaluating alternatives.
But the recommendation is only useful if the digital behaviour remains sufficiently close to the relevant physical behaviour.
Again, validation becomes central.
When is a digital twin worth building?
A digital twin becomes increasingly attractive when several conditions exist.
The asset or process is valuable
If downtime is expensive, improved decisions have greater value.
The problem is repeated
A model used once may not justify a sophisticated synchronized system.
A twin used continuously across the asset lifecycle has more opportunity to repay its implementation cost.
Physical experimentation is expensive
If testing scenarios directly would interrupt production or damage equipment, digital experimentation can be valuable.
Useful data exist
The system needs sufficient information to maintain the required representation.
The problem benefits from modelling
If observing the machine directly already gives the answer, additional modelling may add little.
The twin changes decisions
This may be the strongest test.
If nobody will act differently because of the twin's output, the engineering value is questionable.
When a simpler system is better
Suppose a low-cost pump has one primary maintenance concern.
A temperature sensor and simple threshold reliably indicate the condition requiring inspection.
Building a 3D model, continuous cloud synchronization, AI analytics, a lifecycle database and predictive simulation would probably be excessive.
The engineer should not ask:
“Can we build a digital twin?”
The question is:
“What is the simplest system that reliably supports the required decision?”
Sometimes that answer is:
- Conventional simulation
- A sensor threshold
- A monitoring dashboard
- Periodic condition monitoring
- PLC alarm logic
A digital twin should earn its complexity.
The economics extend beyond initial development
Implementation cost can include:
- Sensors
- Data acquisition
- Software
- Integration
- Networking
- Modelling
- Validation
- Computing infrastructure
- Specialist engineering time
Then come lifecycle costs:
- Data maintenance
- Cybersecurity
- Model updates
- Calibration
- Revalidation
- Software updates
NIST notes that ad hoc customized digital-twin implementations can create high development costs, longer implementation time and poor reuse or interoperability—one reason standardization has become so important.
Therefore return on investment should be measured across the twin's useful lifetime.
The Digital Twin Value Test
Before building a manufacturing digital twin, ask eight questions.
1. What physical system are we representing?
Define the boundary.
Is it a bearing, spindle, CNC machine, production cell or entire line?
Trying to twin everything immediately often creates unnecessary complexity.
2. What engineering decision should improve?
Examples: maintenance timing, process parameter selection, energy optimization, thermal compensation.
No clear decision usually means no clear twin requirement.
3. What data are actually required?
Start from physical phenomena and decision requirements.
Do not begin by collecting everything.
4. What model fidelity is necessary?
Choose enough complexity to support the decision. Not maximum complexity.
5. How will the physical and digital systems remain aligned?
Define update mechanism, timing and configuration management.
6. How will we validate it?
Determine how predicted digital behaviour will be compared with physical evidence.
7. Who maintains the twin?
A twin requires ownership after initial development.
Someone must manage data, model, configuration and validation.
8. Does expected value justify lifecycle cost?
Compare improved decisions against development, infrastructure, validation and maintenance.
If these questions do not have convincing answers, a simpler solution may be better.
My perspective from connected engineering systems
My own work has already involved parts of this broader physical-digital relationship through combinations of engineering systems, software, sensor or condition information, simulation and predictive-maintenance development.
I would not describe those systems as complete industrial digital twins merely because they contain some of the components.
That distinction is useful.
A monitoring system can be valuable without being called a digital twin. A predictive model can be useful without being a digital twin. A simulation can be useful without being a digital twin.
What makes the digital-twin concept interesting is the integration of those capabilities around a particular physical system and engineering decision.
That is also why digital twins are better viewed as systems-engineering projects than as software features.
Key takeaway
A manufacturing digital twin should not begin with a 3D model.
It should begin with a question:
“What engineering decision are we trying to improve?”
From there: define the physical system, identify the necessary information, choose an appropriate model, build the physical-digital interface, validate the representation, and maintain it as the machine changes.
Then evaluate whether the resulting decisions justify the complexity.
Digital twins can be powerful tools for manufacturing.
But the goal should never be to build a digital twin simply because Industry 4.0 says we should have one.
“Build the simplest trustworthy digital system that solves the engineering problem. If that genuinely requires a digital twin, then build the twin.”
References and further reading
- ISO/IEC 30173:2023 — Digital twin — Concepts and terminology. Establishes formal digital-twin terminology, system context, lifecycle concepts and functional views.
- NIST — Digital Twins for Advanced Manufacturing. Current manufacturing programme focused on data, models, interoperability, VVUQ, trustworthiness and implementation methodology.
- Shao & Helu — Framework for a Digital Twin in Manufacturing. Early NIST manufacturing work identifying core digital-twin characteristics and context-dependent implementation requirements.
- Shao, Frechette & Srinivasan — Analysis of ISO 23247. Explains the ISO manufacturing digital-twin framework and its application across manufacturing sectors.
- NIST — Manufacturing Digital Twin Standards. Reviews implementation challenges, manufacturing use cases and digital-twin standardization.
- NIST — Digital Twins for Advanced Manufacturing: The Standardized Approach. Discusses interoperability, reliability, validity, security, trust and the risks of fragmented ad hoc implementation.
