Asset Integrity Management Software — Built Around the Inspection Data
Most AIM platforms started as historians, EAM suites or IoT platforms and had integrity bolted on. This one started with the UT reading.
Asset integrity management software exists to answer three questions: what condition is this equipment in, what is the risk of continuing to run it, and how long can it stay in service. Answering them honestly requires measured inspection data at the component level — thickness readings tied to specific CMLs, indications tied to specific welds, damage mechanisms tied to specific process conditions. Platforms built outward from process historians or maintenance systems tend to model everything except that. Atlantis starts there.
The three questions the software has to answer
- Condition — what does measured wall thickness, indication history and damage-mechanism susceptibility say about this component today, at CML resolution rather than equipment-tag resolution.
- Risk — what is the probability and consequence of failure under API 580/581, computed from that measured condition rather than from a generic default corrosion rate.
- Remaining life — what does API 579-1/ASME FFS-1 Level 1 or Level 2 say about continued service, and what is the defensible next-inspection date under API 510, API 570 or API 653.
How the data gets in and stays trustworthy
Inspection data arrives from UT thickness surveys, PAUT and TOFD scans, radiography, MFL and inline inspection runs, corrosion mapping, and visual inspection reports — in whatever format the instrument produced. Each reading is bound to a CML or TML with a persistent identity, so a 2019 reading and a 2026 reading on the same location are genuinely comparable and corrosion rates are computed from a real time series rather than from an assumed default.
Damage mechanisms are assigned per API RP 571 against the actual process service — sulfidation, naphthenic acid corrosion, HTHA per API 941, wet H2S cracking, chloride stress-corrosion cracking, corrosion under insulation, MIC, erosion-corrosion — so the inspection plan targets the mechanism that is actually credible for that circuit instead of applying a uniform scan coverage everywhere.
Every record carries provenance: which procedure revision was in force, which technician performed the work and what their certification state was at that moment, and whether the instrument was in calibration. That is the bundle a regulator, insurer or client audit asks for, and assembling it after the fact is the single most expensive routine task integrity teams face.
RBI and fitness-for-service on measured data
Risk-based inspection under API 580/581 is only as good as its condition input. When probability of failure is driven by a default corrosion rate, RBI degenerates into a re-labelled calendar. Feeding it measured thickness trends per CML changes which equipment is actually flagged, and typically moves inspection effort away from equipment that has been proven stable for a decade toward circuits that are genuinely degrading.
Fitness-for-service assessments per API 579-1/ASME FFS-1 run inside the same environment — Part 4 general metal loss, Part 5 local metal loss, Part 9 crack-like flaws — using the thickness grid already stored against the component. Results render on the 3D model as pass/fail zones, and the assessment inputs, method and revision are retained so the decision can be reconstructed years later.
Honest comparison with the platforms you are also evaluating
| Platform | Origin | Choose it when | What integrity teams find missing |
|---|---|---|---|
| AVEVA PI System / OSIsoft | Process historian | Time-series process data is the primary problem and you already run PI across the estate. | Inspection data at CML resolution, FFS workflow and inspection-evidence provenance are not native. |
| Bentley iTwin | Engineering / BIM | Capital projects and as-built engineering models dominate the use case. | Damage-mechanism modelling and RBI scoring from measured NDT data. |
| Cognite Data Fusion | Industrial data platform | You have a large data-engineering team and want to contextualise many source systems. | Out-of-the-box integrity workflow — it is a platform to build on, not an integrity application. |
| IBM Maximo APM / Hexagon EAM | Maintenance & EAM | Work management and reliability across a large owned estate is the priority. | Thickness trending per CML, API 579 assessment and inspection-technique provenance. |
| GE Vernova APM (Predix/Meridium lineage) | OEM asset performance | Rotating equipment and power-generation assets, especially GE-manufactured fleets. | Fixed-equipment corrosion management driven by inspection data rather than sensor telemetry. |
| Atlantis Digital Twin | NDT and inspection | Fixed equipment — vessels, piping, tanks, exchangers, structures — where the integrity case rests on inspection data. | Not the right tool for OEM rotating-machine telemetry models or enterprise-wide maintenance work management; integrate rather than replace. |
Deployment and data ownership
A first unit typically goes live in ten to fourteen weeks: geometry capture or import, CML register reconciliation, historical thickness import, damage-mechanism assignment, then RBI and FFS configuration. Geometry can come from LiDAR or photogrammetry capture, from drone survey, or from existing BIM, CAD and isometrics — there is no requirement to re-scan a plant that already has good as-builts.
Data ownership is explicit. Full REST API, documented schema and bulk export are available throughout, and the export includes the inspection history and assessment records, not just a rendering. Integrity data has a multi-decade life; it should never be hostage to a platform decision made in one budget cycle.
Frequently Asked Questions
What is asset integrity management software?
It is the system that holds the technical case for continued safe operation of fixed equipment: condition data from inspection, the damage mechanisms credible for each circuit, risk ranking under API 580/581, fitness-for-service assessment under API 579-1/ASME FFS-1, and the resulting inspection plan and due dates under API 510, API 570 and API 653. Done properly it is the evidence base an inspector, regulator, insurer or client audit examines.
How is an asset integrity digital twin different from a 3D model?
A 3D model is geometry. A digital twin binds live condition data to that geometry: each CML carries its thickness history, each weld its indication history, each circuit its governing damage mechanisms and RBI score. The distinction that matters in practice is that a twin changes when new inspection data arrives — corrosion rates recompute, remaining life shifts, RBI ranking moves — whereas a model does not.
Does the platform do RBI, or does it feed an RBI tool?
It performs RBI natively under API 580/581, and it also exports to external RBI tools where a client mandates one. The value of doing it in the same environment is that probability of failure is computed from measured thickness trends per CML rather than from a default corrosion rate, which is where most RBI programmes quietly lose their accuracy.
Can it run fitness-for-service assessments?
Yes — API 579-1/ASME FFS-1 Level 1 and Level 2 assessments for general metal loss (Part 4), local metal loss (Part 5) and crack-like flaws (Part 9), computed against the thickness grid already held for the component. Results render as pass/fail zones on the model, and inputs, method and code revision are retained so the assessment can be reconstructed and defended later. Level 3 assessments requiring detailed finite-element analysis are performed by our consulting team rather than automated.
How does it integrate with SAP, Maximo or our historian?
Through documented connectors and a full REST API. Typical patterns: inspection findings raise notifications and work orders in SAP PM, Oracle eAM, IBM Maximo or ServiceNow; process conditions are read from AVEVA PI or OSIsoft historians to inform damage-mechanism susceptibility; and engineering geometry is imported from Bentley iTwin, AVEVA or plain CAD and isometrics. The intent is to sit alongside those systems rather than displace them.
What data do we need before starting?
At minimum: an equipment and circuit list, a CML register (even an imperfect one), historical thickness readings in any tabular format, process service conditions per circuit, and current inspection procedures. Geometry is helpful but not blocking — many first deployments start from isometrics and P&IDs and add scan-derived geometry later. Reconciling the CML register is usually the longest single task and is worth starting before the platform decision is made.
How long until the first unit is live?
Ten to fourteen weeks for a first process unit is typical: two to three weeks of geometry capture or import, three to four weeks reconciling the CML register and importing historical thickness data, two to three weeks assigning damage mechanisms per API RP 571, then RBI and FFS configuration and integrity-team training. Subsequent units are substantially faster because the data model and conventions are already established.
Is Atlantis affordable compared with the enterprise APM suites?
The platform is positioned as affordable, accessible and fully customizable, and the commercial model is deliberately simpler than enterprise APM licensing — which typically combines platform fees, per-asset or per-tag fees and a substantial systems-integrator engagement. Scope, asset count and integration depth drive the terms, so request a tailored quote. What we will commit to publicly is the data-ownership position: full export, documented schema, no lock-in.
See it running on your own workflow
Thirty minutes, your job types and your reporting formats, co-presented by an ASNT NDT Level III. Affordable, accessible, fully customizable — request a demo and a tailored quote.
Related: Atlantis Digital Twin platform · Digital twin vendor comparison · vs AVEVA PI System · vs GE Predix / Vernova APM · vs Bentley iTwin · Digital twin ROI calculator