Digital Twins for Turnarounds: Scope, Access, NDT Data

Turnaround Planning Runs on Data That Lives in Six Different Places — Here's What Changes When It Doesn't

Walk into a refinery turnaround planning meeting eighteen months before a scheduled outage and you'll usually find the same fragmented picture: RBI risk rankings live in one software platform, the last inspection reports live in a document management system or a contractor's PDF archive, the P&IDs and isometrics live in an engineering document control system that may or may not reflect the last field revision, corrosion trending lives in a reliability engineer's spreadsheet, and the actual physical condition of the equipment lives in whatever the last inspector remembers from walking the unit. Scope development for the turnaround means someone — usually several someones — manually stitching those six sources together into a work list, and every seam in that stitching is a place where something gets missed, duplicated, or scoped with stale information.

A digital twin doesn't replace any of the underlying engineering or inspection disciplines. What it changes is where that data lives relative to each other and relative to the physical asset — and for turnaround planning specifically, that consolidation has a set of concrete, measurable effects on how scope gets built, how it gets reviewed, and how much of it survives contact with the actual outage.

What "Digital Twin" Actually Means in This Context

The term gets used loosely across the industry, so it's worth being precise about what we mean for a refinery or petrochemical asset: a 3D model of the unit — built from laser scan (point cloud), existing CAD/engineering data, or a hybrid of both — with inspection history, corrosion monitoring data, RBI risk rankings, and equipment tag data attached directly to the corresponding component in the model. Click on a nozzle on the model and you see its CML history, last UT reading, corrosion rate trend, current RBI interval, and any open recommendations tied to that specific location. That's the functional difference from a static 3D model or a walkable VR tour — the geometry is the interface, but the value is the linked data behind it.

Where the data actually comes from

For an existing operating unit, the twin is typically built from a combination of laser scanning (for accurate as-built geometry, since decades of field modifications mean the original design drawings rarely match reality exactly) and import of existing engineering data — P&IDs, isometrics, equipment data sheets — tagged and cross-referenced against the scan. Inspection and integrity data then gets layered on through integration with whatever RBI and inspection record systems the facility already uses, or consolidated directly if the facility is also moving that data into a connected platform like Atlantis NDT ERP.

Before, during and after the turnaround

Before the shutdown, the inspection history on each CML and weld sets which items need access and which examinations, so scaffold and work packs are planned in the model. During it, results go onto the same locations as they are approved. After it, the model holds the as-found condition that sets the next scope. The inspector and the owner's integrity team make the code decisions; the twin keeps the record.

The stakes are well documented. Optelos, a reality-capture vendor, cites benchmarking by TA Cook and Solomon Associates reporting that 82% of turnarounds fail to satisfy their performance requirements (third-party figure: Optelos, 2024).

Scope Development: From Spreadsheet Reconciliation to Spatial Review

The traditional turnaround scope development process involves pulling the RBI-driven inspection list, cross-referencing it against open recommendations from the last outage, checking it against current corrosion trending to see what's actually due, and manually verifying that the scope makes physical sense — that inspecting CML-14 on a given line doesn't require removing three layers of piping, disconnecting instrumentation, or building scaffolding around equipment that's also scheduled for maintenance work in the same footprint at the same time. That last check, the physical feasibility and interference check, is traditionally done by an experienced planner mentally walking the unit from memory or from a site visit, because paper P&IDs don't show you scaffold interferences or access constraints.

With a twin, that spatial reasoning happens directly against the model. A planner can pull every equipment item with an open or upcoming inspection requirement, see them positioned in actual 3D space relative to each other, and immediately identify clustering — three vessels needing internal inspection within twenty feet of each other, which might justify sharing scaffold and confined-space entry setup rather than scoping them as three separate access builds. That kind of clustering opportunity is easy to miss when the work list is a spreadsheet of tag numbers and easy to spot when it's a spatial view of the unit.

Interference detection before the outage, not during it

A recurring and expensive turnaround problem: scaffolding erected for one work scope blocks access needed for another, discovered only once both crews are mobilized and the scaffold is already up. A digital twin with scaffold and access planning modeled against actual equipment geometry lets planners identify these conflicts during scope development, months before the outage, when resolving them costs a planning meeting instead of a day of re-scaffolding during a live turnaround where every day has a real cost in lost production.

NDT Scope Specifically: Connecting the Model to the Inspection Plan

Instead of a spreadsheet row saying "Line 24-P-1015, CML-7, UT thickness, due," the planner sees the actual location on the piping model, can verify access requirements against the current insulation and support configuration, and can pull the full inspection history for that specific point — including whether the last three readings show a corrosion rate that's accelerating, which changes the urgency of that specific inspection relative to others competing for the same turnaround window.

This also changes how findings get communicated during the outage itself. When a UT crew finds unexpected wall loss at a location, logging that finding against the model — rather than just a work order number — means the next person reviewing scope (a fitness-for-service engineer deciding whether a repair or replacement is needed, or a planner deciding whether to expand scope to adjacent CMLs) sees it in spatial context immediately, without needing to cross-reference a tag number against a drawing to understand where the problem actually is relative to supports, nozzles, or other equipment.

Execution-Phase Value: Real-Time Scope Tracking

During the turnaround itself, scope typically grows — planned inspection reveals additional damage requiring expanded scope, or equipment opened for one reason turns out to need work for another. Tracking scope growth against the original plan, and understanding its impact on schedule and resource loading, is traditionally a manual reconciliation exercise done by the turnaround planning team working from status reports and work order updates. A twin with live-linked inspection and work status data lets that reconciliation happen visually and continuously — which parts of the unit are complete, which are in progress, and which have grown scope, viewed spatially rather than as a percentage-complete number on a Gantt chart that doesn't show where the risk actually sits.

A concrete example: catalyst reactor internals inspection

Consider a hydrotreater reactor scheduled for internals inspection and catalyst change-out during a turnaround. The RBI program flags it for internal visual and UT inspection based on known sulfidation and HTHA risk per API 571 damage mechanism screening. In a traditional workflow, the inspection team receives a work order, references the P&ID and any available internals drawings, and plans access and inspection sequence somewhat independently from the catalyst handling crew who's also working inside the same vessel on an overlapping schedule. With a twin, both crews are looking at the same model, can see each other's planned work zones and timing, and the inspection findings (say, unexpected internals corrosion near a distributor tray) get logged against the exact 3D location — which then immediately informs whether the catalyst support structure needs additional scrutiny, without a separate meeting to establish where the finding actually is relative to other components.

Measuring Whether It's Actually Working

Because a digital twin project involves a meaningful upfront scanning and integration effort, turnaround planning teams should track a specific set of before-and-after indicators rather than treating the twin as a self-evidently good idea. None of these are dramatic metrics, but they're the ones that actually reflect where turnaround planning loses time, and they're measurable across a before/after comparison on two consecutive turnaround cycles for the same unit.

Turnaround duration and scope creep

Facilities should be cautious about attributing turnaround duration or cost outcomes directly to a digital twin, because so many other variables — weather, contractor availability, unexpected findings unrelated to planning quality, market conditions affecting crew mobilization — influence those numbers far more than planning tooling does. The more defensible claim is narrower and more honest: better spatial visibility during scope development reduces a specific category of avoidable rework (interference conflicts, access surprises, duplicated scaffold builds) without claiming credit for the turnaround's overall schedule performance, which depends on dozens of factors outside the planning tool's control.

Data Governance: Who Updates the Twin, and When

The single biggest determinant of whether a digital twin remains useful past its first year is whether someone owns keeping it current. Without a clear answer to "who updates the model when a nozzle gets replaced, when a new CML is added, or when insulation gets removed and reinstalled differently than as-built," the twin drifts out of sync with reality at exactly the rate that field modifications happen — which on an active operating unit is continuously. Facilities that get sustained value typically assign this responsibility explicitly, often to whoever already owns updating P&IDs and isometrics after a field change, with the twin update built into the same change-management workflow rather than treated as a separate, easily-skipped task.

Turnaround close-out as the natural update checkpoint

Rather than trying to maintain continuous real-time model accuracy, most facilities find it more realistic to treat each turnaround close-out as a scheduled update checkpoint: reconcile the model against as-built changes made during the outage, import the new inspection findings and updated CML data, and confirm the RBI risk ranking feed is current before the next planning cycle begins. This keeps the twin accurate at the moments it matters most — the start of the next scope development cycle — without requiring a continuous, resource-intensive real-time synchronization effort that most inspection and reliability teams aren't staffed to maintain.

What a Twin Does Not Replace

It's worth being direct about the limits here, because overselling digital twins is a common industry problem that erodes trust once operators see the reality. A digital twin does not perform the inspection — a qualified NDT technician running UT, RT, PT, MT, or advanced methods per a properly screened procedure still generates the actual data. It does not replace the engineering judgment of a fitness-for-service evaluation under API 579-1/ASME FFS-1. It does not replace the RBI methodology's risk calculations under API 580/581 — it visualizes and organizes that output, it doesn't generate it. And it's only as accurate and current as the data feeding it — a twin built once during initial scanning and never updated with new inspection findings degrades into an expensive static visualization within a few turnaround cycles.

The realistic value proposition is consolidation and spatial context, not automation of technical judgment.

Getting Started Without a Full-Facility Build

Facilities don't need to scan and model an entire refinery to get turnaround planning value from this approach. A pragmatic starting point is scoping a twin build around the units actually scheduled for the next major turnaround — the areas where the scope development and interference-detection value is most immediate — and expanding coverage over subsequent turnaround cycles rather than attempting a full-site build up front. This also means the data integration work (connecting RBI output, inspection history, and CML data into the model) happens incrementally against a manageable scope instead of as a single massive integration project.

Atlantis NDT's digital twin platform is built specifically around this kind of asset-integrity use case — 3D visualization tied to live inspection and NDT data rather than a generic facility walkthrough tool — with the underlying inspection records, certification tracking, and reporting managed through Atlantis NDT ERP and NDT reporting software so the twin has current data to display rather than a one-time snapshot. For facilities evaluating whether this fits their next turnaround cycle, the right first step is usually a scoping conversation about which unit and which data sources make sense to connect first, not a commitment to a full-facility rollout.

Atlantis NDT Products & Services