On screen, conveyors move smoothly, machines gleam and every pipe seems to be in place. On the shop floor, a valve has been replaced, a sensor is drifting and production is running with a new recipe. The replica is immaculate, yet it depicts a factory that no longer quite exists. That is the trap of the industrial digital twin: funding an attractive representation, then neglecting what keeps it useful. Looking ahead to September 2026, the challenge is not to perfect the scenery, but to ensure it is constantly checked against reality.
The twin begins where the model ends
A model describes a piece of equipment. A simulator explores its behavior under certain conditions. A digital twin connects a representation to an identified asset or process through regularly refreshed data. The boundary varies by application, but one criterion remains: the representation must support understanding or decision-making based on a sufficiently faithful picture of conditions on the ground.
This fidelity does not always require 3D. To anticipate fouling in a heat exchanger, a few temperature, pressure and flow readings, combined with a thermal model, may matter more than a detailed reproduction of the installation. Conversely, geometry becomes essential when checking a robot’s reach or preparing maintenance work. The right level of realism depends on the decision to be made.
Initiatives already underway illustrate this diversity. BMW and NVIDIA announced a collaboration on virtual factory planning as early as 2021. Siemens and NVIDIA announced a partnership in 2022 combining industrial software and simulation technologies. These projects demonstrate the potential of virtual environments, without proving that every factory needs the same setup.
The first task: understanding what the sensors are telling you
A sensor does not deliver the truth: it produces a measurement, with a degree of uncertainty, under given conditions. A poorly positioned probe, an overlooked calibration or an out-of-sync clock can make sophisticated analysis misleading. Before discussing artificial intelligence, it is therefore essential to check units, operating ranges, calibration dates and consistency between signals.
Take a pump. An increase in vibration may signal wear, but it may also reflect a change in operating conditions or a loose mounting. Without rotational speed, load and maintenance history, the model risks confusing context with failure. Adding more sensors does not automatically solve the problem: it may simply multiply information that is difficult to interpret.
Data quality must be visible to the user. An old value should not appear to be a fresh measurement; an estimate should not be confused with an observation. A confidence indicator, a last-received timestamp and a flag for missing data can sometimes be worth more than a smooth animation. A credible twin also knows how to show what it does not know.
Update at the right pace, not at the pace of marketing
“Real time” is often presented as a universal goal. That frames the issue incorrectly. A control loop requires tightly controlled latency; an analysis of energy-use drift may tolerate minute-level aggregations; a capacity simulation may sometimes rely on daily data. The right question is: how old can information become before it distorts the decision?
The answer determines the architecture. Some processing stays close to the machines to minimize delays and keep operating during network outages. Other processing can be centralized to compare multiple sites. Interruptions, duplicates and late-arriving events must all be anticipated. A historical record reconstructed after an outage must not be presented as an instantaneous observation.
Updates also concern the factory’s structure. When a motor changes, its identifier, characteristics and relationships with other equipment must be updated accordingly. Otherwise, recent data feeds an outdated model. This is one of the least conspicuous forms of obsolescence: everything seems connected, but the mappings have become incorrect.
Connecting systems is not enough to make them understand one another
Data exchange standards, including OPC UA, facilitate the flow of industrial information. Work on the Asset Administration Shell aims to structure an interoperable digital representation of assets. These efforts address a concrete need: avoiding the need to rebuild every connection by hand. But transferring data does not guarantee that everyone gives it the same meaning.
A “motor temperature” may refer to the housing, a bearing or a winding. The same piece of equipment may have different names in supervisory systems, maintenance management systems and production software. Stable identifiers, a shared vocabulary and explicit responsibility for these mappings are therefore essential. This unglamorous work determines whether it is possible to switch suppliers without rebuilding everything.
Value is measured after the alert
Imagine that the twin detects abnormal energy consumption on a production line. Who receives the alert? The energy manager, maintenance staff or the shift supervisor? Who checks whether it corresponds to an unusual production run? Without answers, the dashboard becomes just another screen. With a clear process, the analysis can trigger an inspection and then document its outcome.
Integration with maintenance and operations management tools therefore matters as much as the model itself. It does not necessarily mean automating the response. For a sensitive adjustment, human approval and safety limits remain necessary. Feedback from the shop floor must then enrich the system: a relevant alert, a confirmed fault, an unnecessary intervention or a cause different from the one initially considered.
A pilot project benefits from starting with a narrowly defined question: reducing downtime for a family of pumps, understanding scrap from a particular operation or limiting a peak in consumption. Its results must be compared against a baseline, accounting for changes in production. Savings calculated through simulation are not yet equivalent to observed savings.
Plan for the twin’s upkeep from the moment of purchase
The budget cannot end at commissioning. It must cover calibration, connectors, cybersecurity, model revisions and the time of operational teams. A change in raw materials can degrade a statistical model; a mechanical modification can invalidate its physical assumptions. Periodic checks must compare predictions with observations, with thresholds that trigger a review.
The contract should also specify data ownership, data exportability and the ability to retrieve models. Access to the industrial network must remain controlled, especially if the system can transmit commands. Finally, it is better to retire a twin that serves no purpose than to defend its initial investment indefinitely. Its survival should depend on the service it provides, not the prestige of its presentation.
What next? Looking ahead to September 2026, AI could make it easier to find information, identify anomalies or query models in natural language. This potential removes none of the need for verification: a persuasive interface may even conceal unreliable data. The best-prepared industrial companies will probably be those that treat their twin as a living product, with a designated owner, a recurring budget and identified users. Less a miniature factory to admire than a working tool to maintain.
