Walk into the control room of any mature process plant and ask a simple question: what is the current health of that heat exchanger? You will rarely get one answer.
The inspection engineer will point you to a risk-based inspection (RBI) study in one system. The rotating team will send you to a vibration and condition-monitoring platform for the associated pumps. The process engineer will pull up a simulation. The safety engineer will reference a separate register of trips and bypasses. Each answer is correct. None of them is complete. And nobody in the room owns the whole picture. Whereas maybe the person asking the question is the Operations head, since there is a report which states that it is the most critical asset in the unit.
This is not a failure of any single tool. It is the predictable result of thirty years of buying excellent tools which catered to one problem at a time. The next real gain in reliability will come from making these modules speak to one another and, harder still, from getting people to trust and use the result.
The Market We Actually Have
The asset performance management (APM) and integrity software market is neither young nor thin. Independent benchmarks routinely evaluate twenty or more serious vendors, the large industrial-automation players with end-to-end portfolios, the specialists with deep integrity and inspection pedigree, and a newer wave of AI-first analytics firms. Between them, they cover the recognised disciplines well: RBI to API 580/581, reliability-centred maintenance (RCM) and failure-mode analysis, root-cause analysis (RCA), preventive-maintenance optimisation, and increasingly machine-learning-driven anomaly detection on historian data.
Recently, I had a well-known company enquire about RCA software, and he said that they have already checked out about 4 vendors who are experts in the field. Knowing their systems already, I was wondering which department will own this new branch in addition to the multiple systems they already have. We all know the refineries of today perform on lean manpower, so much so that “lean” is dangerously leaning on third-party vendors who are again squeezed in the name of optimizing cost, which usually affects the quality of work done. But that’s I digress.
So the features exist. What remains scarce is coherence. Most estates run RBI in one product, rotating reliability in another, the enterprise asset management (EAM) system as the transactional backbone, a historian for real-time data, and a spreadsheet, always a spreadsheet, holding the criticality baseline that everything else quietly depends on. Each is a source of truth. Together they are several sources of the truth, which is another way of saying no source of truth at all.
The Digital Twin We Have Been Told About, Honestly Described
No conversation about convergence survives long without the phrase "digital twin." It is worth being precise, because the term is now applied so broadly that it has almost stopped meaning anything. What exists in the market today is several domain-specific twins, each faithful within its slice:
- The geometric or 3D twin: a laser-scanned, navigable model of the physical plant. It tells you where things are and lets you isolate a corrosion circuit visually. It knows geometry, not degradation. Can it be updated? Is a question that nobody asks. The 3D twin is only correct up to the day it was scanned. Every time the plant changes - a new tie-in, a replaced spool, a small-bore branch added - the model is out of date until someone updates it. So unless drawing updates are made a compulsory part of every field modification, the twin slowly drifts away from the real plant. You can feed in CAD drawings, both 2D and 3D. But the model is only useful for reliability if every item in it is linked to its tag number in the maintenance system — otherwise it is just a nice picture with no data behind it. This is where most 3D “twins” are in most places today.
- The corrosion twin: thickness readings, degradation rates, and remaining life against a minimum wall thickness. It knows metal loss, not the machine next to it. This usually requires manpower to “evergreen”, spend money to save money, which you can’t quantify; risk registers and criticality are potential losses nobody believes in, sadly. However, we see that with the new OSHA rules coming in with risk-based inspection mentioned, there is still hope.
- The process twin: first-principles simulation that predicts, for example, where salts will drop out in a crude-unit overhead and drive corrosion. It knows chemistry and operating conditions, not inspection history.
- The reliability or RAM twin: availability modelled from component reliability, series - parallel structures, and Monte-Carlo simulation. It knows system uptime, not wall thickness.
Each of these is genuinely useful. Each is sold, correctly, as a "digital twin." But they are not the same twin, and this is the point: they are almost never the same asset in the same place. The corrosion twin does not know that the pump feeding the vessel is a bad actor. The reliability model does not know that a safety instrumented function protecting the line is running on an expired proof test. The process twin cannot see that the inspection interval it is implicitly relying on lapsed eighteen months ago.
The prize is not a cleverer twin in any one of these domains. The prize is the amalgamation: a single asset picture that carries geometry, degradation, condition, process and safety together, so that the exchanger has one health answer that everyone in that control room is looking at.
Why One System Beats Several Good Ones
Put plainly, the advantage of convergence is that decisions stop falling into the gaps between systems.
Consider the failures that unified data prevents. An inspection that everyone assumed was current, but had quietly slipped, is invisible when the RBI system and the work-order system never reconcile. A bad actor identified by the rotating team never reaches the criticality review because the two live in different tools. A safety function whose proof test has lapsed no longer supports the probability-of-failure claim it was credited with, but only the safety register knows, and it never talks to the risk register. Each of these is a small integration gap. Each has, somewhere, been the first domino in an incident.
A converged system also lets an organisation compare unlike things honestly. When every risk is expressed on one axis, currency per year, probability of failure multiplied by monetised consequence, a pipeline dig and a compressor overhaul can finally be argued about with numbers rather than with whoever shouts loudest in the Thursday planning meeting. That single comparable axis is impossible when consequence lives in four different tools using four different scales.
There is a sustainability dividend, too, and it is not decorative. Every avoided failure is avoided flaring, avoided emergency mobilisation, avoided scrapped-but-serviceable equipment, and avoided unplanned production loss. Reliability done well is decarbonisation done quietly. A plant that inspects on evidence rather than on the calendar does less work, not more, and wastes less doing it. This is basically risk-based inspection in every field using every software you already own with maybe an AI layer over it.
Robust and Flexible: The Requirement Most Software Gets Half-Right
Here is the design tension at the heart of every good reliability platform, and it is worth stating bluntly: a system must be robust enough to embed every recognised methodology, yet flexible enough to bend to a company that knows its own plant better than any template does.
Robustness is the easier half. A serious platform should carry RCM, RBI, RCA, RAM, integrity operating windows, functional-safety records, and criticality assessment as first-class capabilities, each traceable to its standard API, ISO, IEC, ASME, SAE; so that an auditor can see not just the number but the basis for it.
Flexibility is where most tools quietly fail, because flexibility is where the local knowledge lives. Every plant has experts whose experience encodes things no generic library knows. A good system has to let that knowledge in. Some concrete examples of what "flexible" has to mean in practice:
- Small-bore and local pressure equipment must be nameable explicitly. A generic exchanger template will happily assess the shell and the channel and miss the small-bore vent, the local thermowell pocket, the dead leg on the bypass, precisely the features that are hard to see and disproportionately likely to leak. If the checklist cannot be told "on this exchanger, inspect these points," it will screen out exactly what the experienced inspector was worried about.
- Injection points, mix points and dead legs need to be first-class, not footnotes. Chemistry changes at an injection point, so the damage does; a circuit that lumps the injection point in with the main line will average away a real, localised threat.
- Sour service has to change the answer. An H₂S flag should shift the safety consequence and pull in different material and inspection rules automatically, not sit as an inert note in a comments field.
- Redundancy has to be modelled the way the plant actually runs. An automatic changeover and a manual one are not the same risk; a criticality method that cannot distinguish them will mis-rank half the rotating fleet.
- The consequence scale and its weights must be the client's own. One site weights production loss heavily; another, in a residential airshed, weights environment above everything. A platform that hard-codes the weights is telling the client its judgement matters less than the vendor's defaults.
- Bypasses and overrides on safety systems must be governed, not hidden. A defeated safety function is a temporary, authorised, time-limited state with compensating measures, or it is an accident waiting for a date. The system has to hold that as a governed record, not a sticky note on a screen.
The pattern across all of these is the same: the software supplies the discipline; the company supplies the judgement. A tool that only does the first is rigid. A tool that only does the second is a spreadsheet with better graphics. The rare good ones do both, and let the engineer argue with the number, the driver behind every score deliberately exposed, so a competent human can push back on it.
The Part Nobody Budgets For: Adoption
Now the uncomfortable truth, and the one I would ask every reader to sit with. The best software in the world, unadopted, is worse than a modest tool that people actually use. This is a line which I have been finding myself quoting in every meeting room I have been in. It costs money, it creates a false sense of coverage, and it quietly trains people to distrust the next initiative. Adoptability beats feature-rich software, ALWAYS.
The industry consistently under-invests in the human side of this. Procurement scores features. Implementation plans track configuration. Almost nobody writes a serious plan for the thing that actually determines the return: getting an engineer who has trusted her own spreadsheet for fifteen years to trust the system instead, and getting the technician on the floor a job pack in his language, not the analyst's.
Adoption is a soft-skills problem wearing a technical costume. It depends on things that never appear in a feature comparison: whether the tool explains why it reached a number rather than just presenting it; whether it makes an expert's tacit knowledge easier to record than to keep in her head; whether early users are brought in as authors of the configuration rather than recipients of it; whether the first thing the system does for a sceptic is confirm something the sceptic already knew, earning the right to later tell her something she didn't.
Put another way: a converged platform succeeds when it makes the experienced person more powerful, not more redundant. The moment it feels like a replacement for judgement, it will be quietly starved of the data it needs — and a reliability system starved of field input degrades into confident nonsense. The numbers look authoritative and mean nothing.
Where this leaves us
The reliability-software market does not need more features. It has them. The refineries and asset-heavy industries may not need more data collection systems, but need one that will consolidate what they already have. What it needs is convergence, a single asset truth that carries static, rotating, and safety together, built on a platform robust enough to hold every methodology and flexible enough to respect the local expert who knows which small-bore connection actually keeps him up at night. And it needs that platform to be adopted, which is a harder, more human, and far less glamorous problem than any algorithm.
A system that genuinely pulls in every available feed, the historian, the EAM, the inspection history, the safety register, the process model, and presents them as one governed picture would be a considerable step forward. Fragments of that vision already exist across the vendor landscape, and a small number of teams are actively trying to assemble the whole. The technology to do it is, largely, here. I am glad to be working towards a solution to this issue, but the project has only started, and industries are understanding this part too.
The question was never really whether we can build it. It is whether we can get people to use it. Answer that, and the rest is engineering.
About the Author
Praveen M N is a functional and technical consultant working on asset strategy and reliability transformation in the asset-heavy industries. He began as an integrity engineer at MRPL, where hands-on inspection and asset-integrity work shaped his conviction that reliability software succeeds or fails on practical adoption, not feature lists. He currently works on unified APM systems and collaborates with established integrity-software providers. He writes on where reliability engineering and software meet.
Mr. Praveen M N
Sr. Manager | ImageGrafix India | India
