Refining: the integrity record across a turnaround cycle

A refinery turnaround is the one time the integrity program gets full access to the equipment. Vessels are opened, exchangers are pulled, insulation comes off, and for a few weeks the inspection team can see and measure what it has been estimating for years. Then the unit goes back on stream and the next opportunity is four or five years away. Everything the program knows about that equipment in between rests on what was recorded during those weeks. This paper is about the record that has to survive that gap, and what refinery inspection software has to do to carry it.

What does API 510 need from the vessel record?

API 510 covers in-service pressure vessels, and its core mechanism is simple: measure thickness at defined locations, compute a corrosion rate, compute remaining life against the required minimum thickness, and set the next internal or on-stream inspection at no more than half the remaining life or ten years, whichever comes first. Every step depends on the previous one.

For that chain to hold across a turnaround cycle, the record must carry:

• Condition monitoring locations with stable identity, so the reading taken this turnaround is compared against the same point last turnaround, not against a point that was renumbered on a new drawing.
• The required minimum thickness and how it was derived: the design code, the formula, the design pressure, allowable stress, and joint efficiency that went into it. A tMin without its basis cannot be defended.
• Nominal thickness, corrosion allowance, and material, so a reviewer can check the arithmetic.
• The short-term and long-term corrosion rates and which one governed the interval decision.
• The inspector's name, certification, and the date and method of each reading.

In intelliSPEC each CML point carries 64 fields that cover this list, including nominal thickness, tMin and its method, design pressure, material, allowable stress, joint efficiency, corrosion allowance, the latest thickness, and three corrosion rates. The tMin calculation routes by equipment type to ASME VIII Div 1 for vessels and returns the design code and formula with the number. The intelliINTEGRITY module is where the rate and interval are computed, and the interval is capped at half the remaining life.

How should API 570 circuits be organized in the system?

Piping is where refinery programs most often lose control of their data, because there is so much of it and because it is organized differently by different people. API 570 asks the owner to define piping circuits: sections of piping with similar service, material, and corrosion behavior that can be treated together for rate and interval purposes. It then classifies circuits by consequence of failure, with Class 1 carrying the shortest thickness-monitoring intervals.

The software question is whether the circuit is a real object with the CMLs attached to it, or a label on a spreadsheet. If it is a real object:

• A corrosion rate can be computed for the circuit from all its CMLs, and the governing rate can be identified.
• Injection points, mixing points, and dead legs can be flagged as their own inspection scope, as API 570 asks.
• CUI inspection scope can be built from the circuit's insulation and operating temperature attributes.
• A change in service (a new feed, a new chemical) can be recorded once and every CML in the circuit picks it up.

The asset hierarchy in intelliSPEC is a graph of nodes with roles (company, site, facility, asset, component, weld), not a fixed tree. That allows a circuit to be represented as an asset whose components are its spools, with welds as nodes below them, and CMLs attached where the readings are actually taken. The tMin engine routes piping to ASME B31.3.

What is different about API 653 tanks in a refinery program?

Storage tanks run on a slower clock than process equipment. API 653 sets external inspection intervals of at most five years and bases the internal inspection interval on the measured or projected bottom corrosion rate, with a code maximum. Internal inspection means taking the tank out of service, cleaning it, and often doing so on a schedule that is decoupled from the unit turnaround.

The record has different content too:

• Bottom plate thickness surveys, usually from floor scanning, with settlement measurements.
• Shell course thicknesses and the course-by-course minimum required thickness.
• Roof, nozzle, and appurtenance condition.
• Foundation and containment observations.

A tank program benefits from the same discipline as a vessel program: stable location identity, a documented minimum thickness basis, and a computed rate. In intelliSPEC, tMin for tanks routes to API 653 and the same corrosion summary (short-term, long-term, max, governing) applies. Tank internals are one place where the full offline capture matters most, because the inside of a floating-roof tank is a dead zone for connectivity and the technician may be in there for days. The local store has no time limit, and field-level conflict records show what happened when two people touched the same record offline.

How does turnaround scope get built from the integrity record?

A turnaround scope for inspection is a list: which vessels open, which exchangers are pulled, which circuits get thickness surveys, which insulation comes off for CUI, which tanks come out of service. In a mature program the list is generated from the record: due dates from the interval calculation, open findings from the last cycle, RBI ranking, and recommendations that were deferred.

That only works if the record is queryable. If the last turnaround's findings live in a contractor's PDF, someone has to read it and retype. The alternative is that findings are records with severity, mechanism, location, and status, attached to the component they were found on, so "open findings on this unit" is a query.

intelliPROJECTS models the turnaround as a set of entities: the event, activities within it, crews assigned, daily progress, delay events, gate reviews, and cost entries. An inspection activity in the plan links to the equipment it covers, and findings made during the activity land on that equipment rather than on the event. Daily progress and delay records give the turnaround manager the frontier view, while the integrity engineer sees the same findings on the asset.

What happens to findings and repairs during the event?

The event is where the record is most at risk. Findings come in fast, from many hands, on many devices, and the pressure to close scope is intense. The controls that protect the record are procedural as much as technical:

• Each finding recorded by an identified person, with the photo bound to the component at capture time.
• A workflow with visible states: submitted, under review, accepted, repair planned, repaired, verified, closed. Rejections and holds recorded with a reason.
• Repairs recorded as their own records, linked to the finding and to the weld or component, with the post-repair NDE attached.
• Sign-off by the inspector of record, with the signature freezing the record.

intelliSPEC supports 13 workflow transitions, including submit, approve, reject, hold, resume, reopen, and owner sign-off, and a signature widget that records per-signer identity even on a shared device. NDE results from the turnaround (UT thickness, PAUT, RT) are recorded through intelliNDT, and instrument readings from supported gauges enter the record over Bluetooth or keyboard wedge without retyping.

How do you keep the record readable five years later?

Here is the failure mode that catches programs at the second turnaround on a new system: the form has changed. Someone added a field, renamed a dropdown option, or changed a unit. The record from the last cycle now renders with a blank where a value used to be, or with an option label that no longer means what it did. The data is still there, but the evidence is degraded.

The fix is to pin. A completed record should carry the version of the form, the locale, and the reference options it was executed with, and render with those forever. In intelliSPEC completed records pin their field configuration, locale, and reference options, so a record finished in one turnaround looks the same when it is opened at the next.

The second half of readability is provenance. Every change to a record should be attributable: who, when, from where. intelliSPEC records every create, read, update, delete, login, and export event with the actor, tenant, request id, IP, and user agent, and chains the events per tenant with SHA-256 hashes so an auditor can verify nothing was removed. Audit events are never auto-deleted.

The report is what you produce for the regulator. The record is what you produce for yourself, five years from now, when you have to explain why the interval was set where it was.

How intelliSPEC handles it

For a refinery program moving from one turnaround to the next, the relevant facts are these.

• Ten modules write to one asset record, so the visual finding, the UT reading, the corrosion rate, the turnaround activity, and the repair are all views of the same equipment.
• The asset hierarchy is a graph with roles down to the weld, so circuits, spools, and welds are real objects with CMLs attached.
• CML points carry 64 fields including the tMin basis. The tMin engine routes to ASME VIII Div 1 for vessels, ASME B31.3 for piping, and API 653 for tanks, and returns the design code and formula with the number. Intervals are capped at half the remaining life.
• API 580/581 semi-quantitative RBI scoring (probability by consequence, rank 1 to 5) supports interval decisions where the owner has adopted RBI.
• The field app captures fully offline with no time limit on the local store, and conflicts are recorded at the field level.
• Completed records pin the form, locale, and reference options they were executed with.
• The audit trail is hash-chained per tenant and verifiable.

Refining is the service intelliSPEC was built in, and the oil and gas solutions page describes how the modules map onto a downstream program. The best evaluation is to load a unit's last turnaround package and see whether the next one can be scoped from it.