Digital twins that show you what the plant is doing right now

What this actually solves

There is one number behind almost every serious digital twin purchase, and it is downtime. An hour of a stopped production line is a figure the plant manager already knows to the rupee, and it is large. The promise of a twin is that the plant stops surprising them — that a machine drifting towards a failure announces itself while there is still time to schedule the repair into a planned window rather than absorbing it as an unplanned stop at the worst hour of the month.

The second thing it solves is a comprehension problem. The data usually exists somewhere. It arrives as a spreadsheet at the end of the shift, or lives in a historian that only a handful of people know how to query. Both tell you what happened. Neither tells the person walking the floor what is happening. Rows of numbers do not assemble into a picture in anyone's head. A three-dimensional view of the plant with each asset coloured by its current state does, in one glance, which is why the twin is bought by operations rather than by IT.

Third, and increasingly the one that unlocks the budget — planning and energy. Simulating a new line before it is installed, or seeing which part of the process is quietly consuming the most power, are decisions worth more than the visualisation that revealed them.

It is worth being blunt about the shape of this work. It is data engineering and industrial integration before it is anything else. The 3D is the face of the data, not its body — the body is the pipeline, the storage and the tag mapping underneath, and a proposal that is mostly about how the model will look is describing the face and leaving out the body.

How the work runs

1. Scope against a decision, not an asset list. Which decisions should this change, who makes them, and what they need to see to make them differently. Then the assets in scope, the data that already exists, who owns it, and how it is currently reached. This phase ends with a written definition of what is being built and, just as importantly, what is not. Two to four weeks.
2. Establish the data path. Reading from the control system over OPC UA or Modbus, through a gateway that buffers locally so a network outage delays data rather than losing it, onward over MQTT to a time-series database built for this shape of data. Then the unglamorous part — verifying which tags tell the truth. A drifting sensor, a tag rewired during a shutdown and never renamed, a reading in the wrong unit — these are found by comparing against the plant, and nothing else finds them. One to two months.
3. Prepare the 3D. From CAD where it exists, from survey or scanning where it does not, reduced to something a browser can hold at an interactive frame rate while keeping the landmarks people navigate by. Large sites may use a geospatial approach rather than a single model. One to two months.
4. Bind the model to the data. The step that makes it a twin — an explicit, documented mapping between each part of the model and the sensor tags that describe it, with units, valid ranges and what an absent reading means. This binding table is a real deliverable and is the thing that most often does not exist in twins built by someone else. Three to six weeks.
5. Build the views and the alerts. The live view, trends over time, and alerting with thresholds set by the people who understand the process rather than by whoever wrote the code. Alerts are tuned deliberately, because a twin that cries wolf in its first fortnight is switched off in its second. Three to six weeks.
6. Commission, hand over and agree what comes next. Running alongside existing practice while it is checked against reality, then training, documentation of the binding and the extension process, and a written roadmap for the historical and predictive stages once there is enough data to justify them. Three to six weeks.

What moves the price

The range is $10,000–$150,000 over 3–9 months, and it is wide because the projects genuinely are.

How many assets, and how alike they are. Twenty identical machines cost far less per machine than five different ones, because the tag structure, the model and the bindings are reused. Variety, not count, is what drives the number.

Whether the data is already digital. A plant with a modern control system and an accessible historian starts with the hardest input already in place. One where readings are taken by hand needs instrumentation before any software is worth writing, and that work belongs to a different trade with a different schedule.

How far up the ladder you want to go. Live visibility, historical trending, simulation and prediction are four distinct levels, each resting on the one below. Buying the first and adding the others once the data supports them is both cheaper and far more likely to work than commissioning all four at once.

What usually goes wrong

A dashboard is sold under the name of a twin. The words are exciting and the scope quietly becomes some charts and a 3D picture. Six months later you ask where the prediction is, and nobody can point to where it was ever promised or funded. If what is being built is a live dashboard, it should be called that and priced as that — and it is often the right thing to build first.

The data is assumed to exist in a usable form. The project is planned as software, and then discovers that readings are still taken by hand, that tags are named after machines that were replaced, and that the historian's retention window is shorter than the plan assumes. Every one of those is findable in week one by asking, and each one moves the schedule by months if it is found in month four instead.

Nobody owns the tag names. Bindings are made against tag identifiers that any engineer can rename during a shutdown. The next time that happens the twin is confidently displaying the temperature of a machine that is no longer there, and confidence in the whole system goes with it. A naming authority and a change process are part of the delivery, not administrative decoration.