Ask a plant manager if they have a digital twin and the answer is almost always yes. Ask what it does, and the answer is almost always: it shows you what’s happening. Not what to do about it, not what will happen next, and certainly not anything that changes on its own. That’s not a digital twin in any meaningful engineering sense. It’s a 3D dashboard with good lighting.
This isn’t a knock on the underlying platforms. Siemens Xcelerator, the Rockwell/PTC partnership, Dassault’s 3DEXPERIENCE stack — these are genuinely capable toolchains, and vendor roadmaps through 2026 keep pushing further into simulation and optimization territory. The gap isn’t in the tools. It’s in what plants actually build with them, and in the fact that “digital twin” has become a label loose enough to cover everything from a Unity model with live historian tags to an actual physics-based simulation that can be driven in closed loop with your MES. If you’re the engineer who has to justify twin spend to a plant manager or a capital committee, you need a way to say precisely what tier you’re proposing — because the ROI math is completely different at each one.
The three tiers, plainly
Tier one: the visualization twin
This is a 3D or 2D representation of the line, fed by OPC UA tags or a historian pull (PI, Ionics, Canary, whatever your stack runs), refreshed on some polling interval — often a few seconds, sometimes near-real-time if you’ve paid for it. It shows machine states, throughput, downtime reason codes, maybe overlays OEE. It’s read-only. Nothing flows back. It is, functionally, a very good HMI screen with a nicer skin, and for a lot of plants that’s genuinely useful — control room situational awareness, executive walk-throughs, training. But it does not simulate anything and it cannot act on anything. Most deployed “digital twins” today stop here, and a fair number of vendor demos are built to make tier one look like tier three.
Tier two: the simulation twin
Here the model actually behaves like the process — it’s built on a simulation engine (discrete-event, physics-based, or a hybrid) that can run scenarios ahead of or parallel to reality: what happens to takt time if we add a shift, what happens to buffer levels if this changeover runs long, what’s the bottleneck if we swap suppliers on this material. Tier two twins are calibrated against historian data and validated against actual outcomes, which is real engineering work — building and maintaining a simulation model that doesn’t drift from reality is a nontrivial, ongoing effort, not a one-time configuration task. The output is still advisory. A planner or scheduler reads the simulation result and decides what to do. Nothing writes back automatically.
Tier three: the closed-loop twin
This is the twin that earns the name in the strict sense: it doesn’t just represent the process or simulate it, it participates in it. Outputs from the twin — a re-sequenced schedule, an adjusted changeover plan, a maintenance work order — flow back into MES, the scheduling engine, or the CMMS without a human re-keying them. This is where the ROI conversation actually changes shape, because you’re no longer paying for insight, you’re paying for automated action. It’s also where almost everything gets harder, because now you’re touching systems of record, not just systems of record’s exhaust data.
Why almost everyone stalls at tier one
It’s rarely a modeling problem. It’s an integration, governance, and trust problem, and it shows up in three predictable places.
Data contracts. A visualization twin can tolerate sloppy data — a missing tag just means a blank spot on a screen for a minute. A closed-loop twin cannot. If the twin is going to write a new sequence into your scheduling system, every upstream tag it depends on needs a defined contract: expected update frequency, units, valid ranges, and — critically — what happens when a sensor drops out or a PLC goes into a fault state. Most historian architectures were built for trending and reporting, not for feeding automated decisions, and that mismatch is where a lot of tier-two-to-three projects quietly die.
Latency budgets. A dashboard refreshing every 30 seconds is fine. A twin driving a changeover recommendation into MES needs to know, explicitly, how stale its inputs can be before the recommendation is unsafe to act on. That’s a real engineering conversation with your automation and IT/OT teams about network topology, edge compute placement, and whether you’re running MQTT Sparkplug B or OPC UA pub-sub versus a polling architecture — because the answer changes what response time is even achievable.
Write-permissions. This is the one plant IT and cybersecurity teams should be the loudest about, under frameworks like IEC 62443. A tier-three twin needs an explicit, auditable write path into MES or the historian’s control layer — who can it write as, what actions can it take unattended versus with human confirmation, and what’s the rollback if it’s wrong. Most MES platforms weren’t built assuming a simulation engine as a client with write access, so this is real configuration and governance work, not a checkbox in a vendor’s integration guide.
A checklist before you promise “live” to your plant manager
- Have you defined, in writing, which tier you’re actually building — and does the vendor proposal use the same definition you are?
- Do you have documented data contracts for every tag the twin depends on, including failure-mode behavior?
- Have you set a latency budget per decision the twin makes, not just an aspirational “real-time” label?
- Is there an explicit, least-privilege write path into MES/scheduling/CMMS, reviewed by OT security, with an audit trail?
- Is there a human-in-the-loop confirmation step for at least the first operating period, with a defined path to remove it?
- Who owns model drift — the simulation twin degrading in accuracy as the process changes — and how often is it recalibrated?
What actually justifies the spend
Tier one buys you visibility, and visibility has real but modest value — faster root-cause conversations, better onboarding, a genuinely nicer control room. Tier two buys you foresight, which is worth more if your planners actually use the simulation output to change decisions rather than treating it as a novelty. Tier three is the only tier where the twin removes labor and latency from a decision loop, and it’s the only tier where the ROI case can honestly include reduced changeover time, fewer scheduling conflicts, or maintenance triggered before failure rather than after. It’s also the tier that demands the most from your data architecture, your MES vendor relationship, and your security posture.
The honest advice for most plants: don’t sell tier three to leadership until you’ve actually built and proven tier two. A simulation model that’s been validated against real outcomes for a meaningful stretch is the trust foundation that makes anyone comfortable letting it write into a scheduling system unattended. Skipping straight to “closed loop” because a vendor roadmap made it sound achievable is how you end up with an expensive integration nobody trusts enough to actually run in automatic.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
