A digital twin rollout is decided by a short sequence of choices rather than by a platform purchase: which asset gets modelled first, what the model may say about relationships between assets, which conduit the readings leave through, and who answers for the description staying true after the pilot. This article walks that order.
Quick Overview
What you’ll learn:
- How to pick the first asset so the pilot says something about scale
- The platform vocabulary, and why relationships are the paying part
- The conduit question a twin forces you to answer before data moves
- The accountability that has to be named for the model to survive
Who this article is for:
- Maintenance and controls engineers scoping a plant rollout
- Production line owners deciding how wide a pilot should be
- Teams accountable for the data path between the floor and the analytics layer
Reading time: 7 minutes
Which Asset Goes First
The instinct is to model the asset that causes the most trouble. That is the wrong pick: the troublesome asset is usually the oldest, with the fewest instrumented points and the most bespoke control logic. Modelling it is the hardest job in the plant and says almost nothing about whether the approach scales to other stations.
A better first asset is boring and repeated. A conveyor drive found across the plant, or a pump family with a shared bill of materials, gives what the awkward press cannot: the next instance costs a fraction of the first, the only evidence the method scales. If it costs the same, the rollout has a modelling problem — better found on a conveyor than late in a programme.
That also fixes the pilot’s acceptance test: not that the dashboard renders, but that the next instance was described from the first without rewriting the model.
What the Model May Say
Platforms differ in vocabulary while agreeing on substance. learn.microsoft.com describes a twin model as a DTDL interface carrying properties, relationships, components and telemetry, with instances assembling into a twin graph. aws.amazon.com speaks of entities, components and a scene built on existing data sources. Behind both sits one claim: the model layer is the product and the visual layer is a view of it.
The part that pays is the relationship. A property gives the bearing temperature. A relationship records that the bearing belongs to a drive, the drive to a conveyor and the conveyor to a packing cell — so a rising temperature becomes a question about that cell’s availability rather than a line on a chart. Without relationships a twin is an instrumented spreadsheet, which most plants already have.
So the modelling effort belongs with somebody who knows the plant topology, not only with whoever can write the schema — and the schema needs versioning from day one, because the first structural change otherwise breaks instances already deployed.
Which Conduit the Data Leaves Through
Separate questions hide here, and conflating them causes most of the rework.
One of them is semantics. OPC UA, specified in the IEC 62541 series, is the industrial default, and its introductory part on webstore.iec.ch states that the specification covers an information model and an address space, not only a wire protocol. The difference shows up the moment a second machine arrives from a different vendor: one controller exposes a tag called MTR_SPD, the next calls the same quantity drive.speed_rpm, and a third reports it as percent of nominal. No transport layer reconciles those. A signal catalogue does — one row per quantity, with its unit, its valid range and the person who answers for it — and it costs days to write before a platform is chosen, against a mapping exercise repeated per machine forever after.
The other question is the path itself. The operational technology security guide on csrc.nist.gov frames a plant as zones joined by conduits, with the Purdue reference model keeping process control apart from the supervisory layer and business systems. Readings must cross those boundaries for a twin to exist, which puts the project inside the network design rather than on top of it. Treat the conduit as a deliverable with a name, a maintainer and a register of what traverses it, agreed with plant security before the first reading moves.
Imagine a temperature trace that has been perfectly flat for weeks. Was the process unusually stable, or did the sensor fail and its last good value get repeated downstream? Nothing in the twin answers that unless the gateway attached a quality indicator as each reading passed. The same component decides what happens during a network outage — readings discarded, or held and replayed with their original timestamps — which determines whether a gap in the history means an outage or a shutdown. Both behaviours are configuration, cheap to specify up front and unrecoverable afterwards.
Who Answers for the Description
Pilots end; descriptions decay. Between those facts sits the role most rollout documents omit — whoever is accountable for the model still matching the asset after a sensor swap, a cabinet upgrade or a recipe change.
Follow a single event to see why. A vibration sensor fails and is replaced with a different model reporting in different units. The engineer who fits it is the only person who knows. The coordinator on the operational technology side can confirm whether the new device publishes through the agreed conduit. The line owner decides whether the model’s thresholds still mean anything given the new characteristics. Absent a written obligation to tell each other, the twin keeps charting against the old definition and nobody finds out. That is the accountability a rollout document must name — plus, early on, an integrator who writes the naming and unit convention down so the next swap needs no meeting.
One question, asked half a year after go-live, tests whether this was done: when a sensor was last replaced, who updated the model, and how do you know. If nobody can answer, the twin has become a historical document.
Read Also
- Industrial IoT: a complete guide to IoT in manufacturing — the layer a twin draws from
- IoT connectivity in the factory: network architecture and protocols — the transport side
- IT/OT/ICS cybersecurity: a comprehensive guide for industry — the conduit side
Build Your Skills
This topic is developed in the Virtual twin: the foundations of the technology of the future and Industrial IoT for manufacturing professionals courses. The first covers the model and its life cycle; the second the layer it draws data from. Contact us to match the scope to your plant.
Frequently Asked Questions (FAQ)
How does a twin differ from machine condition monitoring?
Ask a maintenance planner’s question: can this repair wait until the weekend? Condition monitoring reports the device’s state and stops, so the answer is a judgement call. A twin holds dependencies between assets as explicit relationships — part of the model, per learn.microsoft.com — so the question becomes a lookup: what sits downstream, and what does the plant lose if it stops mid-week.
Where should a plant with no experience of such projects begin?
With an asset family rather than an asset, and a signal catalogue rather than a platform trial. Pick something that repeats, write down each quantity with its unit, range and owner, then describe one instance. The pilot has told you something only when a further instance is described from the first without reopening the model.
Does a twin mean sending every reading to the cloud?
No, and the reason is a trade-off worth making consciously. Full-rate vibration or current signatures consume bandwidth and storage out of proportion to what a model reads from them, while aggregating at the edge discards the resolution that makes fault signatures visible. Decide per signal class, document the choice, and keep raw capture available on demand where diagnosis genuinely needs it.
Who keeps the model current once the project ends?
The line or asset owner, with review triggered by physical change rather than a calendar date. Calendar reviews drift; a rule tying review to the events that make a description false catches them as they happen. Write the rule and the name into the rollout document, since an unassigned review is not performed.