When the tank interval spreadsheet stops being reproducible

Why the workbook stopped being trustworthy

Nothing dramatic happens when a tank inspection workbook fails. There is no error message. A planner opens it in March, sorts the sheet by next-due date to build the outage list, and the sort moves the values while leaving a block of formulas pointing at the rows they used to sit beside. Every remaining-life figure below a certain row is now computed from a different tank's readings. The file still looks right, still prints, still gets emailed to the terminal manager. It is discovered eighteen months later when a tank the sheet credited with eleven years of life comes up short on a lower course.

The second failure is quieter. Two people maintain the workbook. One treats the corrosion rate column as the long-term rate measured from original thickness; the other has been overwriting it with the rate between the last two inspections whenever those two look worse. Both practices are defensible — API 570 defines long-term and short-term rates precisely and expects the governing one to be selected with engineering judgement, and API 653 applies the same logic to shell and bottom. What is not defensible is a column where you cannot tell, row by row, which of the two you are looking at.

The moment this stops being an annoyance and becomes a project is usually external: a new terminal manager, an insurer's engineering survey, an acquisition, or an API 653 evaluation an authorised inspector has to put a stamp on. Someone asks a question the workbook cannot answer. Not what is the next date, but show me how you got it. Reproducing a number requires the inputs as they stood when it was computed, and a spreadsheet only ever holds the inputs as they stand now.

What API 653 actually asks the engine to compute

The code produces a family of dates on different clocks from different evidence. Routine external inspection by owner personnel is a short-cycle visual activity. External inspection by an authorised inspector is bounded by the lesser of the code cap and RCA divided by four times the shell corrosion rate. External ultrasonic thickness measurement, where a corrosion rate is established, is bounded by the lesser of a longer cap and RCA divided by twice that rate. Internal inspection is driven by the bottom and carries a twenty-year default ceiling that only a documented risk-based assessment can extend.

Every one of those is a minimum taken over a code cap and an arithmetic result, and each arithmetic result depends on a remaining allowance and a corrosion rate that are themselves derived from readings. A spreadsheet almost always collapses this into one column. That collapse destroys the single most useful distinction in the whole calculation: which term bound the answer.

If a tank's UT interval landed on the code cap because RCA/2N came out at twenty-two years, the corrosion rate is currently not interesting and the tank is a scheduling problem. If RCA/2N came out at nine years, the corrosion rate is the entire story, the next reading set is consequential, and the CML coverage on that course deserves review. Terminals with a hundred tanks and a small integrity team live or die on that sorting. An engine that shows the binding term turns an undifferentiated due-date list into a work plan.

t-min is not a constant at a terminal

API 653 computes the minimum acceptable shell thickness for each course from tank diameter, the height from the bottom of the course under consideration to the maximum design liquid level, the specific gravity of the stored product, the allowable stress and the joint efficiency. Two of those inputs describe the service rather than the steel. In a refinery, service rarely changes for decades. In a third-party terminal, service changes with the lease.

A tank that held distillate and then takes on a customer storing a heavier additive package has a higher t-min in every course from the day the product changes, and less remaining corrosion allowance than the sheet claims. The reverse costs money in the other direction: a tank formally derated to a lower maximum fill height genuinely has a lower t-min, more allowance, and a longer legitimate interval — potentially a tank that comes out of an outage year on real evidence rather than being cleaned and entered because the workbook said so. Terminals leave that value unclaimed because recomputing t-min across every course of every tank by hand is a week of work nobody schedules.

This is the argument for deriving rather than typing, in its sharpest form. When t-min is a stored constant, a commercial decision made in the front office silently invalidates an engineering conclusion in the back, and neither side finds out. When t-min is a function of the current service record, a product change recomputes the affected dates the same afternoon, the change is attributed to whoever edited the service record, and it can be inspected and reversed.

The bottom is where the arithmetic gets uncomfortable

Shell corrosion is measurable. Bottom corrosion is half-measurable. The internal interval works from the minimum remaining bottom thickness against the minimum the code will accept, divided by the sum of the topside and underside corrosion rates. A floor scan gives the topside rate with reasonable confidence and gives underside metal loss as it stands at the time of the scan. It does not give an underside rate, because a rate needs two observations at the same location and there is only one.

So the underside rate is an assumption, built from soil resistivity, the cathodic protection record kept under API 651, whether the tank sits on a release prevention barrier, the age and condition of any liner installed under API 652, and how similar tanks on the same pad have behaved. Assumptions are legitimate and unavoidable. Undocumented assumptions buried in a spreadsheet cell are not. A tank whose interval rests on an assumed three mils per year is a different risk proposition from one resting on eight, and in a workbook that shows only the answer the two are indistinguishable.

The critical zone needs its own handling. The band of bottom plate immediately adjacent to the inside of the shell carries a tighter minimum than the rest of the floor, and the acceptable minimum elsewhere depends on whether the tank has a release prevention barrier and leak detection beneath it. A terminal with mixed-vintage tankage on one pad will have three or four different acceptance bases sitting side by side. Any engine that holds a single site-wide bottom t-min is wrong for most of them, and wrong in the unconservative direction for the oldest ones.

The rack and the manifold are not on the tank's clock

A terminal is not a tank farm with some pipe attached to it. Transfer lines, the loading rack, meter runs, the manifold, pumps and vapour recovery equipment fall under API 570, and the pressure vessels among them — knockout drums, air receivers, LPG bullets — fall under API 510 with required thickness evaluated against ASME B31.3 or Section VIII rather than against the API 653 shell formula. Three rule sets, one site, one due-date list.

The mixing points are where terminals get hurt. Additive and dye injection at the rack creates injection-point circuits that API 570 treats distinctly, with a shorter default interval and a defined upstream and downstream extent for the CML set. Seasonal and customer-specific lines produce dead legs that corrode faster than the live circuits on either side of them, and a dead leg is the most common location for a loss of containment at a terminal that has otherwise inspected diligently. Both are classification problems before they are measurement problems: if the circuit is typed as ordinary, the engine will derive a comfortable and wrong date.

The buying implication follows directly. An engine that only implements API 653 solves part of the terminal's scheduling problem and leaves the rest in the workbook you were trying to retire. Tanks, circuits and vessels have to live in one asset register with one derivation layer and several rule sets, or you end up running two systems and reconciling them by hand — which is the failure mode you started with, wearing better software.

Reproducibility is the actual deliverable

Reproducing a five-year-old interval means holding four things a spreadsheet does not hold. The readings as they stood then, including ones later superseded or excluded and the reason for the exclusion. The calculation basis in force then, including the fill height and product gravity the tank was operating on. The code edition and the owner-user's own written procedure as they then stood. And the identity of the person who accepted the result, with the date they accepted it.

Practically that means readings are immutable records and a correction is a new record that supersedes rather than an edit that overwrites; that the engine can be asked to recompute as of a date and will use the inputs valid on that date; and that every field carries who changed it, when, and from what. This is unglamorous plumbing and it is the whole point of moving off Excel. A dashboard is easy to build. An answer to why did this date move is not.

The test to run during evaluation is simple. Pick a tank whose next date has moved in the last two years. Ask the system to explain the movement without anyone opening a document. A serious engine returns the before and after values, the input that changed, the person who changed it, and whether the binding term switched from the code cap to the arithmetic bound. Anything that returns only the new date is a prettier spreadsheet.

How to evaluate this on your own tanks, not on a demo dataset

Bring three real tanks to the evaluation: one on the code cap, one bound by shell corrosion rate, one whose internal interval is driven by an assumed underside rate. Load their actual reading history with its actual gaps. Demo data is uniform and complete, which is exactly why it proves nothing about a system that has to cope with a course inspected in 2011, replated in 2016 and scanned by two different contractors since.

Then run four specific probes. Change the product gravity on the first tank and confirm every affected course's t-min and date recompute without anyone editing a date field. Enter a thickness reading that is greater than the previous one and confirm the system flags a non-physical rate rather than quietly returning an infinite remaining life. Ask which term bound each interval. And ask for the exclusion record on a scattered pit that was deliberately not used to drive the rate — API 653 permits ignoring certain isolated pitting under stated conditions, and the record of that decision is precisely what an auditor will want.

Finally, ask what the system does with the rack. If piping circuits and vessels have to be handled in a separate module with a separate register and no shared derivation, price the reconciliation effort into your comparison, because it will recur every quarter. For a scoped walkthrough against your own tank and circuit data, request a consultation at info@atlantisndt.com.

Request a consultation