Sensors, Twins, and Machines That Tell You What They Need
A digital twin is only ever as truthful as the sensors feeding it. Instrument first, model second- the order is not negotiable.
Digital twins are usually introduced with an ambitious picture: a complete virtual replica of a facility, updating live, capable of answering any question you pose to it.
That version exists, and it is the wrong place to start. It is expensive, slow to reach, and depends entirely on something far less exciting- an instrumentation layer that actually reports the truth. Model a machine you cannot measure and you have built an animation, not a twin.
Start with one machine and one question
The successful pattern is narrow. Pick one asset that matters- a machine whose failure stops a line, a cold room whose temperature has consequences, a pump whose downtime is measurable in a currency someone cares about. Then pick one question about it.
Is it running? Is it running hotter than last month? How long is it idle between jobs?
One asset, one question, real data. This produces something useful in weeks, and- more importantly — it teaches you what your environment is genuinely like. You will discover that the connectivity in that corner of the building is unreliable, that the machine reports a value in units nobody documented, that the reading spikes every time a different machine starts. Those lessons cannot be acquired in a planning document, and every one of them would have derailed a facility-wide rollout.
The gap between data and information
Sensors produce enormous volumes of numbers. Numbers are not insight, and the distance between them is where most IoT projects stall.
A temperature reading every second, for a year, from forty sensors, is a storage bill. The same data with a defined baseline, thresholds that reflect real operating conditions, and alerting that fires on trend rather than instant value, is a maintenance programme.
That translation is the actual engineering. It requires someone who understands the process- not just the platform. The most common failure is a dashboard that displays everything and answers nothing, presented to an operations team who quietly return to their own spreadsheet.
Why processing at the edge stops being optional
Once the sensor count grows, sending everything to a central system becomes untenable- bandwidth, cost, and latency all push back. And some decisions cannot wait for a round trip: safety interlocks, quality rejections on a moving line, anything that must act within milliseconds.
Edge AI puts the model where the data is created. The device makes the immediate decision locally and sends the summary upstream rather than the raw stream. Bandwidth falls by orders of magnitude, the system keeps working when the connection doesn't, and the response time stops depending on the network.
This carries a real trade-off- updating models across a fleet of edge devices is a genuine operational discipline, closer to fleet management than software deployment. Plan for it, because it is the part that arrives after the pilot succeeds.
Blockchain, AR, and the question to ask
The same discipline applies to the rest of the emerging category. Blockchain and smart contracts solve a specific problem: multiple parties who need a shared record and do not fully trust each other to maintain it. Where one organisation controls the data, a database is simpler, faster, and cheaper. AR and MR are genuinely transformative for maintenance, training, and spatial work- and underwhelming when applied to something a document already handles.
The question is always the same, and it is worth asking out loud before anything is procured: what becomes possible that was not possible before? If the honest answer is "the same thing, differently", it is a demonstration rather than a project. If the answer is specific, it is worth building.
