Thirty Years of Tank History, and the Records That Do Not Import

Three assets in one tank, three corrosion rates

A field-erected storage tank is not one asset for corrosion-rate purposes. It is at least three, and API 653 handles them separately because they fail differently and answer to different minimum thicknesses. The shell is a hoop-stress problem, and required thickness varies by course because the bottom course carries the full product head while the top course carries almost nothing. The floor is not a pressure boundary at all — it is a containment membrane whose criterion is a minimum remaining thickness before a leak, not before a rupture. The annular ring sits between the two and inherits the worst characteristics of both.

The consequence for a corrosion-rate module is that a single tank-level corrosion rate is meaningless. A tank can be losing 0.004 in/yr on the underside of the floor while the upper shell courses lose effectively nothing, and the number that sets the next internal inspection is the floor rate. Terminals that report one rate per tank almost invariably report the shell rate, because the shell is what external ultrasonic surveys see between internals — and the shell is the component least likely to be the constraint.

Required thickness itself varies by course and must be stored per course, together with the product specific gravity, design liquid level, course geometry and joint efficiency it was derived from. A remaining-life number that does not carry its own inputs cannot be re-derived when any of them change, and at a terminal at least one of them changes every few years. This single design decision — store the inputs, not the answer — separates systems that survive five years from systems that are quietly replaced by a spreadsheet.

Why the floor needs two rates and the shell needs one

API 653 addresses bottom plate remaining life using separate topside and underside corrosion rates evaluated against a minimum remaining thickness. This is not a bookkeeping formality. Topside corrosion is product-side and is driven by water bottoms, settled sediment, microbially influenced attack under sludge and sulfur species in the stored product. Underside corrosion is soil-side and is driven by moisture in the pad, soil chemistry and resistivity, the condition of any release prevention barrier, and whether cathodic protection is actually polarising the steel.

The two rates have almost nothing in common and respond to entirely different spending. Improving water draw-off practice and tank cleaning frequency moves the topside rate. Repairing a rectifier or extending the anode ground bed moves the underside rate. A system that stores one floor rate makes both interventions invisible, and terminals routinely fund one while the other is the binding constraint. Merging the two is the most common modelling error in tank integrity software.

They are also measured with very different confidence. Topside loss is directly measurable during an internal — a gauge on clean steel. Underside loss is inferred, usually from MFL indications sized against a limited set of verification ultrasonic readings. That difference belongs in the record. A topside rate built from forty direct readings and an underside rate inferred from twelve prove-up points are not the same class of number, and a system that renders them identically invites a decision the data does not support.

What actually breaks when you import thirty years of tank history

The import that fails on a terminal migration is not the thickness column. Thickness readings are numbers with dates and they move cleanly. What fails is everything that happened to the metal between them. A tank whose second and third shell courses were patched in 2011, whose annular ring was partially replaced in 2016, and whose floor was lined in 2004 has three discontinuities in its history, and a long-term rate computed straight through any of them is arithmetic performed on metal that was not there for part of the interval.

Legacy systems almost never carry this in machine-readable form. It sits in the repair narrative of an API 653 report, on a paper form in a filing cabinet, or in the recollection of an inspector who has retired. Recovering it is genuine work, and it is the work that determines whether the migration produces a usable system or an expensive copy of the old one. The pragmatic order is to pull every out-of-service report, extract repair scope and date only, and load those as dated events before a single thickness reading is imported.

The test for whether a candidate system understands this is short. Load a repair event into the middle of a history and ask for the long-term rate at an affected location. The correct behaviour is to compute from the repair date, label the output as a post-repair rate, and keep the pre-repair series intact as a separate epoch. Silent continuity is the failure mode, and it is silent by definition — nobody discovers it until an auditor asks how a 2011 plate accumulated seventeen years of loss.

Cathodic protection creates a step change, not a slope

Cathodic protection does not slow soil-side corrosion gradually. It changes the regime. Before the rectifiers were energised, the underside of a tank floor may have been losing 0.008 in/yr. Afterwards, with adequate polarisation and a functioning ground bed, it may be losing an order of magnitude less. A long-term rate averaged across that transition reports a figure somewhere in between, which accurately describes no period of the tank's actual life and understates the risk in the years before commissioning while overstating it in every year since.

For a terminal migrating history, the CP retrofit date is often the single most valuable piece of metadata in the entire archive — and it is almost never in the thickness data. It lives in the API 651 survey records, usually held by a different department, sometimes by a contractor. Annual survey results, rectifier readings and any documented interruption periods belong on the same timeline as the thickness readings, because a rectifier that was off for eighteen months created a corrosion-rate epoch whether or not anyone recorded it as one.

The output this makes possible is a rate an integrity engineer can defend in a sentence: underside rate 0.0009 in/yr since CP commissioning in 2004, prior-epoch rate 0.0071 in/yr, next internal driven by the post-CP rate with a documented basis. That statement is worth doing the migration properly for. Its opposite — one blended rate with no epochs — cannot survive a single question from an auditor who happens to know when the rectifiers went in.

A product change moves required thickness without moving a reading

Terminals reassign tanks, and they do it more often than the integrity records suggest. A tank moved from gasoline to a heavier product experiences greater hydrostatic head at every shell course, which raises the required minimum thickness at every course, which reduces remaining life at every CML — without a single new thickness reading being taken. Legacy spreadsheets almost universally hold required thickness as a hardcoded constant per course, entered once during the original build and never revisited.

A corrosion-rate module for terminals therefore has to store the inputs rather than the result: specific gravity, design liquid level, course height and position, joint efficiency and corrosion allowance. It recomputes on change, retains the previous values with their effective dates, and keeps every historic remaining-life figure reproducible in the context in which it was originally issued. Without effective dating, recomputation silently rewrites history and the archive stops matching the reports that were sent to regulators.

This is also the most common reason a newly migrated terminal system disagrees with the old spreadsheets on day one. The spreadsheet was right for the service the tank had in 2014. The new system is right for the service it has now. Both numbers are correct and only one is current. Teams briefed to expect the disagreement resolve it in an afternoon. Teams that are not spend a quarter arguing about whether the software works.

MFL is not a thickness gauge, and the rate it feeds is different

Magnetic flux leakage floor scanning locates and ranks indications. It does not measure wall thickness. The output is a percentage of nominal loss carrying an accuracy band that varies with plate thickness, coating thickness, scan speed and the calibration plate used. Treating an MFL percentage as though it were an ultrasonic reading imports the tool's uncertainty directly into a number that will decide whether a tank comes out of service, and the uncertainty disappears from the record the moment it is stored as a thickness.

The defensible workflow is MFL for coverage, prove-up ultrasonic readings for measurement, and a corrosion rate computed from the prove-up readings with the MFL result retained as the coverage evidence. The system should hold both, linked to the same locations, and should be able to state which of the two produced any given rate. Terminals that merge them lose the ability to answer the question every auditor eventually asks, which is not what the rate is but how you know it.

On migration, historic MFL data is typically the least portable asset in the archive — vendor-specific formats, and in older files often nothing but a PDF colour map. Accept that limitation rather than engineering around it. Migrate the prove-up ultrasonic readings, the indication counts and severity distribution, and the report itself as an attachment. Do not reconstruct a synthetic thickness grid from a scanned image, because a grid you invented is indistinguishable from a grid you measured once six years have passed.

The interval is the deliverable, not the rate

For most terminals the corrosion rate is an intermediate value. The deliverable is the inspection interval. API 653 caps the external inspection interval and drives the internal interval from the calculated bottom corrosion rate and remaining thickness, so the rate is the input to a scheduling decision with substantial cost attached on both sides. An error in the conservative direction pulls a revenue tank out of service early. An error in the other direction is considerably worse.

The regulatory frame at a terminal is denser than most operators expect it to be. SPCC under 40 CFR 112 requires integrity testing on a schedule consistent with industry standards, which for large field-erected tanks means API 653. Breakout tanks associated with regulated pipelines fall under 49 CFR 195.432, which points to API 653 directly. State programmes and, at some sites, consent-decree schedules layer on top. The same tank can owe its inspection to two federal citations and a state permit, and every one of them derives from the same calculated rate.

A module that produces a rate but not the interval — with its basis, its code cap, its next-due date and the evidence trail behind it — leaves the highest-consequence step of the process in a spreadsheet. That is precisely the step the migration was supposed to remove from the spreadsheet, and it is the step most likely to be examined.

How to evaluate a corrosion-rate module during a migration

Evaluate with your own worst tank rather than a demonstration dataset. Choose the one with the most repairs, the CP retrofit, the product reassignment and the missing 2009 report, and ask the vendor to load it in front of you. What you are watching is not whether it loads — everything loads — but what the system does with the gaps. Quarantined and visible is the right answer. Defaulted and hidden is a system that will produce confident numbers built on assumptions nobody wrote down.

Three questions separate candidates quickly. Can it hold more than one corrosion-rate epoch per location, and explain which epoch produced the rate it is showing? Does it keep topside and underside floor rates as distinct fields with distinct evidence and distinct confidence? Can it recompute every historic remaining-life figure after a required-thickness input changes, while still showing what the number was when it was issued? A no to any of the three means the spreadsheet returns within a year, running alongside the software.

Finally, ask what happens the day an inspector disagrees with the calculation. The right answer is an override that demands a reason, an owner, a date and a permanent trace — not an editable cell. In a terminal the override is frequently correct; experienced inspectors know things the model does not. It is the absence of a record of the override, not the override itself, that fails an audit.

Request a consultation