Carrying cement plant inspection history into a code-driven interval engine

The grid minimum, and the corrosion it invents

For decades, thickness survey reports in cement and lime plants were delivered as a table of areas with a single number against each: the minimum reading found in that area. It was sensible field practice and a perfectly reasonable report for a fitness decision at the time it was made. It is a catastrophic input to a remaining life calculation, because the minimum of a twelve-point grid is not a place. It is a statistic, and the physical point that produces it moves from survey to survey.

Subtract this year's minimum from last year's and you have differenced two different physical points. On an abrasion-worn riser duct or a clinker cooler casing, where the spread across a single grid can be several millimetres, that difference is dominated by which point happened to be lowest on the day, not by wear. It produces rates that are alarming on one asset and negative on the next, and a migration that loads them as a CML trend will publish both with identical confidence and identical formatting.

The correct migration rule is to import grid minima as survey evidence — genuinely useful for fitness screening and for showing the worst case at a point in time — but never as the basis of a corrosion rate. Rates begin at the first survey with real fixed-point identity. That usually means the usable trend is short, which is uncomfortable, and it means the engine has to fall back to a default interval until enough genuine history accumulates. Uncomfortable and true beats comfortable and fabricated.

CML identity across five contractors and four grid schemes

A twenty-year history in a cement plant has typically passed through several inspection contractors, each of whom arrived with their own grid convention, renumbered the drawings and left. The physical points may even have been the same ones, but nothing in the record links CML 14 in the 2009 scheme to CML B-3 in the 2016 scheme. Load them as distinct identities and every trend restarts at each changeover. Merge them without evidence and you have invented a continuity you cannot defend to an inspector or an insurer.

The reconciliation work is manual and it is the single largest cost item in a migration of this kind. It needs the isometrics or general arrangement drawings from each era, the survey sketches, and someone who knows the plant physically rather than only on paper. The output is a mapping table carrying a confidence flag per point: confirmed, probable, or unlinked. That flag has to survive into the engine, because a long-term rate built on a probable link is a weaker number than one built on a confirmed link, and the report should say so plainly rather than presenting both at the same precision.

Budget for this explicitly and do it once. The common failure is to defer the mapping, run both systems in parallel "for now", and discover three years later that the new system's usable history begins at go-live while everything before it sits in a PDF archive that nobody opens and nobody trusts.

The missing required thickness

Remaining life is meaningless without the floor it is measured down to. Legacy cement plant records almost never store required thickness. What they store, if anything, is a column headed corrosion allowance remaining, or a hand-written minimum acceptable value on a survey sheet whose derivation has been lost with the engineer who wrote it. Migrating either into the required thickness field is not a rounding error. It moves the floor by the entire corrosion allowance, and every remaining life computed above that floor is overstated by the same margin.

The proper source is the design calculation. For pressure vessels that means recovering the manufacturer's data report and the thickness calculation behind it, or recalculating required thickness for the governing load case under the applicable ASME Section VIII rules at current design conditions. For piping it means the applicable ASME B31 code with the actual design pressure and temperature, not the nameplate maxima, which are usually more generous. On equipment installed in the 1970s and 1980s those documents are frequently gone, and the honest migration outcome is a required thickness marked as recalculated with its assumptions recorded alongside.

The engine must distinguish three states — retained original calculation, recalculated, and assumed — and must report how much of the fleet sits in each. In a first migration it is entirely normal for the assumed population to be large. It should shrink every year as design calculations are recovered or redone, and that shrinkage is a far better measure of programme progress than any compliance percentage a dashboard can produce.

Readings that were never taken on steel

Cement plants are full of surfaces that defeat ultrasonic thickness measurement in ways a refinery's are not. Preheater cyclone cones, riser ducts and the kiln hood are refractory lined, and an external reading is only valid where the acoustic path is shell plate alone. A probe placed over an external stiffener, a wear plate, a weld overlay, or heavy build-up of clinker dust and coating returns a path length that is not the wall. Air receivers and fuel tanks accumulate paint layers and scale. Readings taken on hot surfaces without temperature-corrected velocity read short.

In a legacy dataset these appear as thickness that increases with time — a physical impossibility that an engine will convert into a negative corrosion rate and, downstream, into infinite or nonsensical remaining life. Some systems silently discard negative rates. That is worse than publishing them, because it removes the only visible evidence that the data set has a systematic problem, leaving a clean-looking report built on a filtered population.

The migration rule is to quarantine rather than delete. Import the reading, flag it as anomalous with the reason recorded, exclude it from the rate calculation, and keep it visible in the asset's history. Where the same CML produces anomalies across multiple surveys, it is usually telling you something real about access, surface condition or procedure that should change how the point is examined — not something about the metal underneath it.

Tanks: what API 653 needs that cement plant records rarely contain

Cement plants have acquired API 653 obligations without always noticing them. Fuel oil storage was always there. The growth of alternative fuel firing added solvent, waste-derived liquid fuel and used oil tanks, frequently acquired second-hand or converted from another duty rather than purpose-built and documented. API 653 requires external visual inspection at defined intervals, ultrasonic shell thickness measurement on a schedule that depends on whether a corrosion rate is established, and internal inspection subject to a long ceiling that risk-based methods may approach but not exceed.

The data those evaluations need is granular in a way legacy records simply are not. Shell evaluation is per course, because the required thickness varies with head and the corrosion does not distribute itself evenly up the shell. Bottom evaluation needs plate thickness data across the floor together with knowledge of whether a release prevention barrier is present, since that changes what the interval determination may assume. A legacy record holding one average shell thickness and no bottom data cannot reproduce any part of it, however it is reformatted.

The realistic migration position is to carry forward what exists as reference, re-baseline at the next external inspection, and let the engine mark the tank's interval as provisionally assigned until real data arrives. Backfilling assumptions into an API 653 evaluation so that the new system looks complete at go-live is how a plant ends up defending a number that nobody can reconstruct, in front of an inspector who will ask exactly that.

Jurisdictional inspections that no calculation may extend

The waste heat recovery boiler, the plant air receivers, and in many works a hot water or auxiliary steam generator are jurisdictional equipment. Their in-service inspections are performed or witnessed to a state or provincial requirement, commonly administered through the National Board Inspection Code, and their frequency is statutory. A risk-based assessment can inform maintenance planning around them; it cannot extend the legal inspection by a single month.

Legacy cement records typically hold these as a separate paper file kept by the maintenance superintendent, with the jurisdiction number and the current certificate. Migrations that consolidate everything into one asset table routinely lose the jurisdiction number, the inspector's identity and the certificate expiry, because the new system's data model has no fields for them and nobody asked. The first time this surfaces is when a certificate lapses and the equipment cannot legally operate.

Build the fields before the load: jurisdiction, jurisdiction number, national board number, certificate expiry and the authority. Then make the engine take the earlier of the statutory date and any derived date, and label which one governed. This is the same discipline any multi-jurisdiction operator needs, and cement plants need it particularly because their statutory population is small enough to be forgotten inside a register of thousands of assets.

Snapping derived dates to the kiln outage calendar

A cement works has one, sometimes two, major kiln outages a year, and almost everything intrusive happens inside them. A derived due date of 14 March carries no operational meaning if the outage runs in October. The engine has to hold the outage calendar as a first-class object and express each due item in relation to it: due before the next outage, achievable within the next outage, or requiring deferral to the one after. That single reframing is what makes the output usable by a planner rather than by an auditor only.

Deferral is legitimate but it has to be recorded properly. API 510 and API 570 permit interval adjustment within their own limits with owner-user justification and approval; they do not permit a date to slip because the outage ran short or the scaffold arrived late. The engine should force a deferral record carrying a basis, an approver and a new date, and should refuse to move a date silently. The audit value of that record is high and its cost is a two-minute form filled in by the person who made the decision anyway.

The reverse case matters as much and is far more often missed. Items falling due shortly after an outage should be pulled into it, because the alternative is either an unplanned opening or an overdue asset carrying a deferral that was never really justified. A due-date list that does not draw the outage boundaries makes both decisions invisible to the planner who has to make them.

Proving the migration before the old system is switched off

The acceptance test for a migration of this kind is not a record count and it is not a screenshot. It is reproduction. Choose thirty assets spanning the whole population — a vessel with a full retained design calculation, a vessel with none, a piping circuit with a contractor changeover inside its history, an alternative fuel tank, a jurisdictional boiler, a refractory-lined duct — and require the new engine to reproduce the interval currently in force for each, with every input traceable, before anything is decommissioned.

Where it cannot reproduce the current interval, the usual explanation is that the current interval was never derived at all. It was typed, years ago, by someone reasonable who had no better basis available. That is a finding worth having, and it is the actual return on the migration. Expect a meaningful fraction of the register to fall into that category, and plan resourcing for the workload that appears when those assets receive a calculated date for the first time.

Atlantis builds the interval engine on Odoo, so migrated history, examiner certifications under SNT-TC-1A and ISO 9712, equipment calibration records, outage work orders and deferral approvals live in one system rather than four. Migration scope is built around the CML mapping exercise and required thickness recovery, because those two items decide whether the derived dates are defensible at all. Affordable, accessible and fully customisable. To discuss a migration against your own legacy dataset, contact info@atlantisndt.com.

Request a consultation