I Have a Simulator, Not Yet a Digital Twin

Right now I have a model of a pumping plant that works well as a simulator.

I use it as a training ground. My optimiser runs against it, tries thousands of scheduling scenarios, and learns how to run the pumps without ever touching the real site.

For that job, the model is good enough. It behaves like the plant. It does not have to be the plant.

That is the thing I have realised. A simulator only has to be representative. A digital twin has to be accurate about one specific plant, as it actually is right now. That is a much harder task, and I am still working out what it looks like in practice.

The first problem is the baseline.

My model is built from drawings, pump curves and datasheets. The real plant will not match those exactly. So before I can honestly call it a twin, I have to calibrate it against the real thing.

My plan is to use a search routine, particle swarm optimisation, to tune the model parameters until its outputs line up with the measured outputs from site. Same inputs in, same behaviour out.

That first calibration, at commissioning, is the big one. It is where most of the effort goes, and it is the step that turns a general model of a pumping station into a model of this pumping station.

Once the baseline is set it should hold, because the physical plant is not changing. Until someone changes it. Fit a bigger pump, swap a valve, re-pipe a section, and the baseline I carefully established is no longer true. Then I re-calibrate against the new reality.

Between those changes, though, the plant still drifts. Impellers wear. Pipes foul. Nothing dramatic, but enough that over time the twin and the plant quietly stop agreeing.

And here I run out of settled answers. How often do I re-calibrate for drift? What should trigger it? How do I tell ordinary drift from something that actually needs a person to look at it? I do not have clean answers to those yet. They are the questions the work itself is throwing up.

There is another question underneath all of it, about how much detail a twin actually needs.

Take the pipes. I can model a pipe run in detail, or I can model it as a single loss component, one number that captures how much it resists flow. The detailed version looks more like the real pipe. But it does not automatically match it any better.

Detail I cannot calibrate against a real measurement does not earn its place. It makes the model look more like the plant without making it agree with the plant. A simple loss component, tuned against real site data, can track reality more closely than an elaborate pipe model tuned against nothing.

The simpler component has another advantage. It solves faster. One loss coefficient instead of a detailed pipe run is less to compute, and when the optimiser is running thousands of scenarios against the model, or when I am re-calibrating, that speed matters. A twin I can solve quickly is a twin I can actually use in the loop.

So fidelity is not the same as detail. The right level of detail is set by the decision the twin has to support, and by what I can measure on site. Anything finer than that is model I cannot check and time I cannot spare.

Working through all of this has led me to a way of thinking about the whole thing.

A digital twin is not a different kind of object from a simulation. It is what a simulation becomes once you calibrate it against a real plant, and commit to keeping it calibrated.

I am still in the middle of working that out. But appreciating the difference has made it clearer what I am actually building, and what I am taking on to keep it accurate.