Daniel Tremer
CEO & Managing Partner
A digital twin is not a 3D animation of a plant. It is a data model that runs alongside the plant — and that is exactly where most projects come apart: not at the simulation, but at the telemetry underneath.
What a twin really is
Tenders usually say “digital twin”, but what is meant is one of three very different things: a geometry model, a simulation, or a running image of the operating state. Only the third deserves the name. A twin that does not run in sync with the readings of the real plant is a model — useful, but a model.
The difference is not hair-splitting but a question of architecture. A geometry model is computed and is then finished. A twin has a state, and that state goes out of date the moment it is written. Everything else follows from that.
The data foundation
Before anything is simulated, the telemetry has to be right. In the projects we have worked on since 2022, the problems almost always sat in the same layer:
-
Timestamps without a time zone. Two plants, two controllers, two readings of
timestamp— and an analysis that counts one hour twice in October. - Signals without a unit. A value of 3.2 is only a measurement once it says somewhere what it is a measurement of.
- Gaps that arrive as zeros. The most expensive fault of all, because it looks like a reading.
None of these problems is demanding. All three are expensive when they only show up in the model instead of at the interface.
- Raw31 %
- Unit52 %
- Time zone68 %
- Sampling84 %
- Model97 %
Rule of thumb
If the state of a plant cannot be reconstructed from the raw data stream, no twin will reconstruct it either. A model can interpret data, but it cannot invent it.
The question of latency
After data quality, the second question is the one about permissible lag. It is rarely asked and still decides half the architecture, because cost and currency stand directly against each other here.
Three modes, three architectures
| Mode | Lag | Suited to |
|---|---|---|
| Batch | 1–24 h | Reports, billing, trends |
| Micro-batch | 1–5 min | Condition monitoring, alarms |
| Streaming | < 1 s | Control, grid stability |
Most use cases advertised as “real time” are in truth micro-batch. That is not bad news: the architecture becomes an order of magnitude simpler, and cheaper by roughly the same factor.
We manage solutions, not only projects. And we build code instead of PowerPoints.
Three things from practice
- Measure first, then model. Two weeks of data capture before the first model save more time on average than they cost.
- Version the twin like code. A model without history cannot be checked against reality, because nobody knows which model was running on the day in question.
- A metric that hurts. Not “dashboard availability”, but the deviation between forecast and measurement, daily, visible to everyone.
Conclusion
The twin is the visible part, the data foundation the expensive one. Turn the order around and you get a very beautiful visualisation of data nobody trusts. Keep to it and after a few months you have something that is actually used in operation — usually far less spectacular than it looked in the tender.