By Robert Smith 
I’ve spent the last several years building the connective tissue between control rooms, machine learning pipelines, and modern process simulation software. SCADA historians, OPC-UA tags, and neural nets all have to agree on what’s happening inside a reactor or a compressor train. That’s the unglamorous middle layer I live in.
So when people ask me whether digital twins are “real,” or just a rebranded flowsheet model with better marketing, I get the skepticism. I had it too, for a long time. Process simulation software has existed since the 1970s. A lot of what people call a digital twin today is just an old steady-state model wearing a new badge.
But something has genuinely shifted in the last two or three years. It isn’t hype. Three things arrived at once. Cheap, continuous IoT telemetry now flows from the plant floor. AI surrogate models run fast enough for a control loop, not just an overnight batch job. And software agents can now decide what to simulate, when to run it, and what to do with the result. No engineer has to babysit every run anymore. That combination is what’s actually changing process simulation software. It’s worth walking through carefully. Vendor language tends to oversell what’s happening, and it underplays why it actually matters.
What “digital twin” meant before, and why it fell short
Classic process simulation software answers design questions. Think of the Aspen Plus and HYSYS lineage, or the gPROMS and Ansys world. Given these feed conditions and this equipment, what does steady state look like? That’s a useful question when you’re sizing a column or checking a mass balance. Those tools still handle it well. But they were never built for one specific job: tracking a live, drifting, aging piece of equipment minute by minute and warning you before it fails.
I saw this gap constantly in my own work. A first-principles model of a heat exchanger is accurate the day you commission it. Eighteen months later, fouling builds up. A turnaround partially cleans the tube bundle. Ambient conditions shift with the seasons. That same model quietly stops matching reality. It’s not obviously wrong. It’s just wrong enough that predictions drift away from the plant, until a shutdown exposes the gap. Hand-recalibrating first-principles models doesn’t scale past a handful of assets. You end up with a beautiful simulation of a plant that no longer exists.
That’s the actual problem digital twins solve, when engineers build them properly. The goal isn’t “simulate the process.” It’s “keep a model synchronized with reality, continuously, using the data streams the control system already has.” That reframing is the whole story. It’s why the connection to SCADA and IoT data isn’t a nice-to-have feature. It’s the entire point.
The SCADA and IoT data problem nobody wants to talk about
Every conference talk about digital twins shows the same clean architecture diagram: sensors on the left, a cloud icon in the middle, a beautiful 3D twin on the right. Nobody shows the six months in between. That’s where you discover half your tag names changed during a 2019 DCS migration. Your historian samples pressure every ten seconds, but temperature only every two minutes, for no documented reason. And “flow_1” means three different things on three different units, depending on which contractor configured that particular skid.
Getting real-time SCADA and IoT data into a usable state is, honestly, most of the labor in these projects. Modeling doesn’t eat the calendar. Data reconciliation does. So does timestamp alignment, unit conversion checks, and sensor-fault detection that stops a bad transmitter from teaching your surrogate model something false. On a typical predictive maintenance pilot, I’d estimate engineers spend 60 to 70 percent of total effort on data plumbing. That’s before anyone trains a single AI model. Anyone who tells you otherwise either works with an unusually clean plant, or hasn’t shipped one yet.
Why the real-time piece changes what’s possible
Once that data is trustworthy, it changes what process simulation software can be. An engineer no longer has to manually update a model’s parameters every quarter. The twin pulls live pressure, temperature, vibration, and flow data straight from the historian or an OPC-UA gateway. It uses that data to continuously re-anchor the simulation. That’s the “real-time” part of real-time digital twins. It’s a genuinely different capability than what the industry had ten years ago.
Why AI surrogates, and not just faster computers
Here’s the part that surprises people outside the field. The AI in “AI surrogate model” usually isn’t doing anything conceptually exotic. Engineers train most surrogates on the outputs of a rigorous first-principles simulation. You run the expensive model thousands of times across a range of operating conditions. Then you train a neural network, or a gradient-boosted model, to approximate that input-output mapping almost instantly. The surrogate doesn’t replace the physics. It compresses years of simulation runs into a model that answers in milliseconds instead of minutes.
Why does that matter for predictive maintenance specifically? Because prediction means evaluating “what happens next” across many possible futures, fast and often. A rigorous simulation that takes four minutes to converge works fine for engineering studies. It’s useless if you want to re-evaluate a pump’s remaining useful life every time a new vibration reading arrives. A surrogate that answers in 40 milliseconds can run continuously instead. It feeds a rolling degradation estimate back into whatever system is watching that asset.
There’s a second, quieter benefit. Surrogate models trained partly on real operating data, not just simulated data, start to capture behavior the original first-principles model never included. Nobody wrote equations for it in the first place. Bearing wear patterns tied to a specific lubrication regime show up in the data this way. So does the way a specific compressor drifts under a specific humidity profile. That plant-specific texture was never in the textbook model. This is where process simulation software genuinely stops being generic. It starts reflecting the actual, idiosyncratic machine on your floor.
Where agents actually come into it
My own role has shifted with this, and I don’t think I’m unusual. Five years ago, an “AI engineer” working alongside process simulation software mostly trained anomaly-detection models and handed dashboards to operations. Now a meaningful chunk of the job is orchestration. I decide which events should trigger a simulation, and which model should answer which class of question. How confidence scores reach a human is my call too, along with what an agent can and can’t touch on its own. It’s less pure modeling now, and more systems design. It’s closer to building a careful, well-instrumented decision pipeline than to fitting one impressive model. That’s a different skill set than most data science programs teach. It’s one reason teams adopting this pattern hire differently than they did even three years ago.
Most 2024-era discussions of digital twins missed this piece entirely, because agentic AI wasn’t yet a practical category. An “agent” here isn’t a chatbot bolted onto a dashboard. It’s a system that watches a stream of plant data. It decides on its own that an asset’s behavior warrants a fresh simulation run. It chooses which model or surrogate to invoke, and interprets the result against maintenance thresholds. Then it either flags a human, or, in more mature deployments, adjusts setpoints within pre-approved bounds.
What this looks like day to day
Concretely, it works like this. A monitoring layer watches vibration and temperature trends on a set of rotating equipment. A trend crosses a soft threshold, not yet an alarm, just a pattern worth checking. The agent pulls the relevant tags. It runs them through the AI surrogate to estimate remaining useful life. If the surrogate’s confidence is low, the agent cross-checks that estimate against a rigorous simulation. It then writes a structured recommendation into the maintenance system, with supporting data attached. No engineer had to notice the trend, investigate it, and build the case by hand. The agent did the busywork. The human still makes the call on anything consequential.
That division of labor is the real innovation here. It’s why I push back when people call this “AI replacing engineers.” What it actually replaces is the manual triage step. That’s the part where a competent person spends two hours confirming something a well-instrumented system could confirm in ninety seconds. I’ve watched reliability engineers go from checking a dozen dashboards each morning to reviewing a short, prioritized list an agent already built overnight. That’s not a smaller job. It’s the same expertise, applied to fewer false starts.
A predictive maintenance pattern I’ve seen work
The clearest version of this I’ve worked on combined a rotating equipment fleet, several years of historian data, and a surrogate model. We retrained that model monthly against fresh operating data. We didn’t try to model everything at once. That’s a trap teams fall into, trying to build one grand unified twin of an entire plant before proving the pattern anywhere. We picked 14 assets instead, chosen for the best combination of failure history and instrumentation quality, and built the closed loop around just those.
Within the first full maintenance cycle, the flagged-versus-actual failure correlation held up well. The reliability team started scheduling work around the recommendations, instead of around the fixed calendar interval they’d used for a decade. That’s the real milestone in these projects. It isn’t the model’s accuracy on paper. It’s the moment a skeptical maintenance planner changes a schedule because of what the system told them. Accuracy matters, but it isn’t enough on its own. Trust is something you earn, asset by asset. It usually takes a few cycles of the system being right before anyone acts on its output without double-checking manually.
The dynamic modeling piece matters here too. Static surrogate predictions, like “this bearing has roughly 40 days left,” help. But dynamic models simulate how a fault progresses under different operating scenarios. That lets planners ask a better question. If we keep running this unit at current load versus dropping it 15 percent until the next planned outage, how does the failure timeline change? A point prediction alone can’t answer that. Tying the AI surrogate back to the underlying dynamic simulation is what earns the extra complexity.
What this means for the software itself
Vendors across this space are repositioning their process simulation software around this same shift. AspenTech, Siemens, Honeywell, Emerson, Ansys, and a wave of smaller specialists are all doing it, at different speeds and with different levels of substance behind the marketing. Nearly all of them add the same three things. First, a live data connector layer for OT systems. Second, a surrogate-modeling toolkit trainable on simulation output plus real operating data. Third, increasingly, some form of orchestration or “copilot” layer that automates parts of the run-interpret-recommend cycle.
Here’s what I’d caution buyers on. Ask specifically how the surrogate models get retrained over time, and who owns that. A model trained once at commissioning and never touched again degrades exactly like the first-principles models it replaced. It just degrades more quietly, because everyone assumes “AI” means self-updating. Some platforms handle continuous retraining well. Others ship a static model and call it done. That distinction matters more than almost any other feature comparison in a vendor evaluation.
It’s also worth being honest that not every process needs this. A batch process with infrequent changeovers and generous maintenance margins may get more value from a well-maintained static model and a good CMMS. A full real-time digital twin with agentic orchestration isn’t always the better bet. The complexity earns its keep where assets are expensive to fail, instrumentation is already decent, and unplanned downtime clearly costs more than the build. Matching the tool to the asset’s actual economics is still an engineering judgment call. A vendor’s ROI calculator shouldn’t make that call for you.
The risks nobody puts in the brochure
Most process simulation software vendors are still catching up on this front. Tying a digital twin directly into SCADA data streams expands the attack surface of systems that were historically air-gapped, or close to it. Letting an agent act on that data expands it further. Researchers studying digital twin architectures layered on industrial SCADA have flagged exactly this risk. A twin that mirrors live control data becomes a richer target. If compromised, it becomes a more convincing vector for feeding false data back into operations. Treat the data pipeline with the same security discipline you’d apply to the control network itself. Don’t treat it as an IT afterthought bolted on later. Segment read access. Authenticate every write path an agent might use. Log every automated action. None of that is optional.
There’s also a modeling risk teams tend to underweight. Surrogate models only perform as well as the operating envelope they trained on. Push a process into conditions outside that envelope, like a genuinely novel upset or an equipment configuration that’s never occurred before, and a surrogate can return a confident, smooth, completely wrong answer. This is why the better implementations keep a rigorous physics-based model in the loop as a check. That check matters most for scenarios flagged as low-confidence or out-of-distribution. Don’t trust the fast surrogate blindly every time. Speed only helps when you pair it with a way to notice when it isn’t trustworthy.
Where I’d start, if you’re evaluating this
If you’re weighing whether to bring this into your own operation, start narrower than feels ambitious. Pick a small set of assets with real failure history and reasonably good instrumentation already in place. You’re validating a pattern here, not deploying a plant-wide platform on day one.
Get the data pipeline solid before you touch any modeling. A mediocre model on clean data beats a great model on dirty data, every time. Keep a human in the approval loop for anything the agent recommends. Do that until you’ve built a real track record. Only then should you consider expanding what the system can do on its own. Treat the security architecture as part of the design from the start, not a review gate at the end.
Process simulation software isn’t becoming obsolete in any of this. The underlying physics still has to be right. First-principles models remain the foundation the surrogates build on. What’s changing is the loop around that software. Data now flows in continuously instead of loading in batches. Models update themselves instead of waiting for the next engineering study. Agents handle the watching and triaging that used to require someone checking dashboards on a schedule. That’s a real shift in how the discipline works day to day, even though the underlying mathematics of process engineering hasn’t changed at all.
Frequently Asked Questions
Digital twins, simulation, and surrogate models
Is a digital twin just a more advanced simulation? Not exactly. A simulation answers a question about a fixed set of conditions you define. A digital twin tracks a specific, real asset continuously. It uses live data to stay synchronized with how that asset actually behaves as it ages. Source: SimOps — Digital Twin vs. Simulation: What’s the Difference?
Can AI surrogate models replace first-principles process models entirely? Generally no, and the better implementations don’t try. Engineers usually train surrogates from first-principles simulation output plus real operating data. They keep rigorous models in the loop as a check, for conditions outside the surrogate’s trained range. Source: TGM Lightweight Solutions — AI in Engineering 2026
Do I need machine learning expertise in-house to use AI surrogate models? You need it somewhere in the project, whether on staff or through a vendor. But most teams face a bigger lift in data engineering than in the modeling itself. Getting historian and SCADA data clean and reliable is usually the harder part. Source: Digital Engineering 24/7 — AI-Powered Digital Twins Raise Hopes for Better Predictive Maintenance
Getting started and managing risk
How is SCADA data actually connected to a digital twin? Usually through OPC-UA gateways, historian APIs, or MQTT brokers. These stream tag data into whatever platform hosts the twin. The connection has to handle latency, gaps, and sensor faults gracefully. Source: Control.com — Digital Twinning and its Use in SCADA Systems
What’s the security risk of connecting a digital twin to live control data? The twin becomes a new access point into systems that were often isolated by design. If someone compromises it, they can potentially feed false data back toward operations. Source: PMC — Digital Twin-Driven Intrusion Detection for Industrial SCADA
What’s a reasonable first project if my plant has never done this before? Most practitioners recommend starting small. Pick a well-instrumented asset group with clear failure history, rather than attempting a plant-wide rollout. Source: Oxmaint — Digital Twins for Maintenance: 2026 Implementation Guide
References
-
- Control.com — “Digital Twinning and its Use in SCADA Systems.” https://control.com/technical-articles/digital-twinning-and-its-use-in-scada-systems/
- Digital Engineering 24/7 — “AI-Powered Digital Twins Raise Hopes for Better Predictive Maintenance.” https://www.digitalengineering247.com/article/ai-powered-digital-twins-raise-hopes-for-better-predictive-maintenance/digital-thread
- Ansys — “Digital Twin Simulation-Based Software.” https://www.ansys.com/products/digital-twin
- AspenTech — Industrial AI and Process Engineering Software. https://www.aspentech.com/en
- ARC Advisory Group — “AspenTech Brings a New Dimension to Asset Optimization and Reliability.” https://www.arcweb.com/blog/aspentech-brings-new-dimension-asset-optimization-and-reliability
- PMC / National Library of Medicine — “Digital Twin-Driven Intrusion Detection for Industrial SCADA: A Cyber-Physical Case Study.” https://pmc.ncbi.nlm.nih.gov/articles/PMC12390215/
- IoT Business News — “Digital Twins in IoT: From Real-Time Data to Simulation and Optimization.” https://iotbusinessnews.com/2026/04/24/digital-twins-in-iot-from-real-time-data-to-simulation-and-optimization/
- TGM Lightweight Solutions — “AI in Engineering 2026: How Simulation, Digital Twins & Surrogate Models Are Redefining CAE.” https://www.tgm.solutions/en/top-technologies-in-engineering/ai-in-engineering-2026-how-simulation-digital-twins-surrogate-models-are-redefining-cae/
- Oxmaint — “Digital Twins for Maintenance: 2026 Implementation Guide.” https://oxmaint.com/article/digital-twins-for-maintenance-guide
- SimOps — “Digital Twin vs. Simulation: What’s the Difference?” https://www.simops.com/post/digital-twin-vs-simulation-what-s-the-difference