Building a CML Registry That Survives a Tank Out-of-Service Window

A terminal window is one tank, not a unit turnaround

In a refinery the turnaround is a coordinated shutdown of an entire unit, and every discipline queues for the same window. A terminal works the opposite way. The facility never stops. One tank comes out of service while product keeps moving through the rest of the tankage, and the window that tank gets is negotiated against throughput commitments, lease agreements with the customers who own the product, and the seasonal shape of demand. A gasoline tank that has to be back in service before a seasonal volatility transition, or a distillate tank that has to be full before winter, carries a return date that no inspection finding is going to move.

That constraint has a direct consequence for the registry. Degassing, washing, sludge removal and waste disposal consume the front of the window, and nobody enters the tank until they are finished. Scaffold contracts, rope access teams, vacuum trucks, long-lead plate material and the authorised inspector are all committed before anyone sees bare metal. The scope therefore has to be built entirely from what you already know: which monitoring locations exist, where they sit, what they read last campaign, and what it costs to reach them. If that information is spread across three PDF reports from three different contractors, the scope is a guess, and the guess is reliably low.

The second consequence is that scope growth is unusually expensive here. In a large turnaround a discovered problem competes for shared resources and can often be absorbed. At a terminal there is one tank, one crew and one dike. An unplanned floor repair does not get absorbed; it extends the outage day for day against a contractual return date, and in a leased tank it may trigger commercial consequences that dwarf the cost of the repair itself. A registry earns its keep by shrinking discovery, not by documenting it afterwards.

A monitoring location and an indication are not the same record

Most thickness software models exactly one thing: a location that receives a reading every campaign, indefinitely. Terminal tanks generate two other kinds of record that do not fit that shape, and forcing them into it is how history gets lost. A shell CML is genuinely persistent, because you intend to return to the same point on the same course for two decades. A floor indication is not persistent at all. It is a discrete feature found during a magnetic flux leakage scan, proved up with ultrasonics or a pit depth gauge, dispositioned by the evaluator, and very often removed from existence by a patch plate before the tank returns to service.

If that indication is stored as a CML, it pollutes every trend it touches, sitting in the corrosion rate calculation as a location with one reading and no future. If it is stored only in the report narrative, it effectively disappears, and the next campaign cannot answer the question the inspector will certainly ask, which is what was at this coordinate last time and what was done about it. The registry needs three distinct classes: recurring monitoring locations, indications with a found date and a disposition, and repairs with their own installation date, material and baseline.

Repairs deserve particular attention because they reset the arithmetic. A patch plate installed in one campaign has that campaign's baseline and its own corrosion rate from that point forward. Averaging its readings with the surrounding original floor understates loss on the old plate and overstates it on the new one. A registry that cannot represent a repair as a new component with a new baseline will quietly corrupt the bottom evaluation on every tank that has ever been repaired, which at a working terminal is most of them.

One t-min across all shell courses is the most common arithmetic error

API 653 evaluates shell thickness course by course, because the hydrostatic head acting on a course depends on how much product sits above it. The bottom course carries the largest head and the largest required thickness; the top course carries almost none. The required minimum is a function of tank diameter, the height of product above the course, the specific gravity of the stored product, the allowable stress for the shell material, and the joint efficiency of the original construction. None of those are constant across a tank, and at least two of them are not constant across a tank's life.

The failure mode is banal and widespread. Somebody computes a required thickness once, types the number into a spreadsheet column, and it propagates through every subsequent report. Applied to the upper courses it condemns steel that is entirely serviceable and generates repair scope nobody needed, which at a terminal means scaffold time and plate that were bought against a fixed window. Applied to the bottom course it does the opposite, and that is the direction that matters.

Product service is the change that catches people out. Moving a tank from gasoline at roughly 0.74 specific gravity to a denser product raises the required thickness on every course without a single thousandth of an inch of metal being lost. Reducing the maximum operating level after a settlement survey lowers it. In both cases, every historical evaluation on that tank is now computed against the wrong denominator. A registry that derives required thickness from a stored design basis can re-evaluate the entire reading history the moment the basis changes. One that stores a typed number cannot, and nobody notices for a decade.

Floor grids, MFL screening and the prove-up problem

The tank bottom usually governs the internal inspection interval, and the bottom is measured differently from everything else on the tank. Magnetic flux leakage scanning is a screening technique. It detects volumetric metal loss and estimates it as a percentage of wall, with an accuracy that depends on plate thickness, coating thickness, sensor lift-off, scan speed and the calibration plate used. It does not produce a thickness. Prove-up with ultrasonics or a pit depth gauge produces the number that goes into the evaluation, and only the proved-up value belongs in the arithmetic.

A floor campaign therefore generates two data sets that must both be recorded and must never be confused. The first is coverage: which plates were scanned, at what percentage, with what reporting threshold, using what equipment and calibration. The second is the proved-up measurements at specific coordinates. If the coverage parameters are not stored, the next campaign cannot compare like with like. A full scan reported at a twenty per cent threshold and a partial scan reported at a forty per cent threshold will produce very different indication counts on a floor that has not changed at all, and somebody will read the difference as deterioration and buy a floor.

Attribution is the third thing to record. API 653's bottom evaluation projects a minimum remaining thickness forward using corrosion rates, and topside and underside loss behave differently. Topside loss follows water bottoms, sediment and product chemistry. Underside loss follows soil-side conditions, the release prevention barrier and the state of cathodic protection, and only one of those is affected by a new internal coating. A grid point recorded without stating which side the loss was on gives the evaluator no defensible basis for choosing a rate, so the evaluator chooses conservatively, and conservative on a tank bottom means an earlier and far more expensive next outage.

Access class is the real cost driver, not the CML count

Estimators are handed a location count and multiply it by a blended rate per reading. On a storage tank that method is wrong by a factor of two or three, because the cost of a shell reading is almost entirely the cost of getting a qualified technician to the metal. Courses one and two are typically reachable from grade or a small manlift. Above that you are into elevated work: a manlift with the reach and the ground bearing pressure to be positioned inside a diked area, a swing stage, erected scaffold, or a rope access team working to a recognised rope access scheme.

The productivity difference is not marginal. A technician working from grade can take a hundred or more thickness points in a shift. The same technician on rope, in a team that cannot be smaller than two working technicians plus a supervisor, covers a fraction of that, and every reposition is a rigging change with its own hold points. Add the containment dike, whose wall and slope block wheeled access to a substantial arc of the circumference on many terminal tanks, and the reachable-from-grade fraction is considerably smaller than the plot plan suggests.

The fix is to make access a first-class field on every location rather than a sentence in a report. Each CML carries an access class: grade, manlift, scaffold, rope, roof, or confined space entry. The registry can then produce a scope that reads as hours and crew composition rather than as a count of readings. That is the number you can sign a scaffold contract against and book a rope crew against before the tank is degassed, which is the entire reason for building the registry before the window opens.

Service changes break the corrosion rate, not just the required thickness

Terminals change what they store, sometimes several times in a tank's life. A tank runs gasoline, then a ten per cent ethanol blend, then a renewable diesel or fatty acid methyl ester blend, then perhaps jet. Each service brings its own mechanism. Ethanol and biodiesel blends hold and release water differently and support microbiologically influenced corrosion at the water interface and in the floor sump region. Heated products cycle the shell thermally and introduce the possibility of heating coil leaks. Jet fuel makes coating and lining condition more commercially consequential than a few thousandths of shell loss, because the product specification is unforgiving about particulate and free water.

A corrosion rate computed straight across a service change is a blended fiction. Six years in a benign service averaged with three years in an aggressive one produces a number that describes neither period and systematically understates the mechanism currently running. Terminal registries should carry service history as a timeline on the tank, compute rates within a service epoch, and flag any location whose reading span crosses a change so that a human decides how to treat it rather than an average deciding silently.

The same timeline earns its keep a second time during outage planning. Knowing that a tank has been in a water-bearing blend since the last internal tells the planner to expect floor and sump scope, to book more prove-up capacity than the location count implies, and to hold a coating contractor provisionally. That is a scope decision made from stored data weeks before anyone opens a manway, and it is precisely the difference between a planned outage and a discovered one.

The registry is an SPCC record whether or not you designed it as one

Petroleum storage terminals in the United States sit under the EPA's Spill Prevention, Control and Countermeasure rule, and the integrity testing provision at 40 CFR 112.8(c)(6) requires testing on a regular schedule combined with visual inspection, in accordance with recognised industry standards. The facility's professional-engineer-certified SPCC plan names the standard it follows, commonly API 653 for field-erected tanks or STI SP001 for shop-fabricated ones, and the intervals stated in that plan become the facility's own commitment. Facilities that could reasonably be expected to discharge into navigable waters carry facility response plan obligations under 40 CFR 112.20 in addition.

The practical consequence is that the thickness registry is evidence, not merely a maintenance convenience. When a regulator or an auditor asks how the interval on a particular tank was set, the answer has to be reconstructable in full: which readings, taken by whom, under which written procedure, with instruments calibrated when, evaluated against which required thickness and which fill height. Data that lives in a contractor's proprietary system, or in a spreadsheet that has been edited in place for a decade with no version history, cannot answer that question in a form anyone will accept.

There is also a change-control point that operators tend to discover late. Moving from a calendar-based interval to a risk-based interval, or extending an interval on the strength of a release prevention barrier and a supporting evaluation, changes the basis stated in the SPCC plan and is therefore a plan amendment requiring professional engineer certification. A registry that timestamps interval changes, records the justification and retains the superseded basis makes that amendment a short piece of paperwork. One that simply overwrites a next-due date makes it an archaeology project conducted under time pressure.

What to ask a vendor before the scope freeze date

The questions that separate systems are narrow. Can required thickness be derived from the tank's design record rather than typed in, and does the system re-evaluate history when the design basis changes? Can it hold indications and repairs as record types distinct from monitoring locations, each with its own dates and dispositions? Does every location carry an access class, and can the system produce a scope expressed in crew hours by access class rather than in counts? Can it store MFL coverage parameters alongside proved-up measurements, and will it refuse to compute a rate from a screening estimate?

A second set of questions concerns handover, because terminals change inspection contractors and contractors change software. Can the full registry, including reading history, procedures, calibration references and inspector credentials, be exported in an open format at any time without vendor assistance? Is the export complete enough that a different system could rebuild the trend? Who holds the data if the contract ends mid-campaign? Terminals that have lived through one contractor transition without a clean export rarely need this explained twice.

Finally, ask to see the system fail. Load a real tank from your own history, including the messy parts: a service change, a patch plate, a course where the required thickness was revised, a floor campaign with partial coverage. A demonstration built on clean synthetic data proves nothing, because clean data is not the problem you are buying a solution to. Atlantis will run that exercise against your own records as part of a scoping consultation, and the output should be a scope you could hand to a scaffold contractor before the tank is degassed.

Request a consultation