CML and TML management at plant scale

A single refinery can carry fifty thousand condition monitoring locations across its piping and vessels. Each one is a promise: that a technician will return to the same square centimeter of steel, read it with a calibrated gauge, and add the reading to a history that goes back to the day the equipment was installed. At that scale the engineering questions (where to put the points, how many, what they mean) are inseparable from the data questions (how a point keeps its identity through a drawing revision, a repair, a re-tag and two software migrations). This paper covers both, with API 570 and API 510 as the frame, and describes what CML management has to protect above everything else: the identity of the point and the continuity of its history.

What is a CML, and how does it differ from a TML?

API 570 defines a condition monitoring location (CML) as a designated area on piping where periodic examinations are conducted. The examination can be ultrasonic thickness, radiography, visual for cracking or external corrosion, or any other technique appropriate to the damage mechanism. A thickness measurement location (TML) is the older, narrower term for a CML where thickness is measured. In practice most CMLs on piping are TMLs, but the distinction matters for the record: a CML monitoring for stress corrosion cracking by wet fluorescent magnetic particle testing has a history of indications, not thicknesses, and the data model has to hold both.

API 510 applies the same concept to vessels. A CML on a vessel may be a single point, a grid over a corrosion-prone region (the bottom head, the liquid line, below a nozzle), or a scan line. The grid geometry is part of the CML's identity: a 4 by 4 grid at 50 millimeter spacing is a different location than a single point at its center, and a reading from one is not comparable to a reading from the other.

What a CML is not: a row in this year's survey spreadsheet. The spreadsheet view is how most CML data ends up destroyed, because each survey creates new rows and the link between this year's row 412 and last year's row 398 is a human's memory.

How does API 570 say CMLs should be selected?

API 570 asks the inspector and corrosion specialist to place CMLs where corrosion is expected and to size the count to the circuit. The guidance:

• Circuitize first. Group piping into circuits with the same design conditions, material, process fluid and expected corrosion mechanism. The circuit is the unit of analysis; CMLs characterize it.
• Target expected corrosion. Elbows and tees (outer radius), reducers, downstream of control valves, orifices and flow restrictions, injection and mixing points, dead legs, low points and drains, soil-to-air interfaces, and locations where the mechanism identified for the circuit will act first.
• Add representative locations on straight runs so the circuit's general corrosion rate is known, not only its worst spot.
• Scale to class and rate. Class 1 circuits (highest consequence) carry more CMLs than Class 3; circuits with higher or more variable corrosion rates carry more than stable ones.
• Reduce where justified. API 570 permits fewer CMLs on circuits with low corrosion rates and low consequence, and permits eliminating thickness monitoring on Class 4 piping in some cases. A CML that has read the same thickness for twenty years on a low-consequence line is a cost, not a control.
• Maximize information. Where a circuit has one dominant mechanism at one location, a few well-placed CMLs beat many scattered ones.

The principle is that the CML program should be able to state, for each circuit, the location expected to fail first and how confident the program is in that statement. A program that has ten thousand CMLs and cannot answer that for a given circuit has data, not knowledge.

Why is CML identity the whole problem at scale?

Every CML value depends on comparing readings across time at the same location. That comparison is only valid if the identity of the location is durable. Identity fails in predictable ways:

• Drawing revision. The isometric is redrawn, CML numbers are renumbered, and the history is now attached to numbers that mean something else.
• Retagging. A unit reorganization changes line numbers. CML 12-P-101-04 becomes 12-P-201-04 and the history stays with the old tag in an archive.
• Physical loss. The stencil weathers off, the marking tape is under new insulation, and the technician measures a spot 200 millimeters away.
• Repair. A spool is replaced. The CML now reads a new wall, and if the history is not restarted with a documented discontinuity, the long-term rate becomes negative and the short-term rate meaningless.
• Duplicate identity. Two units use the same CML numbering scheme and a plant-wide report merges them.
• Migration. The data moves from one system to another, and the field that carried the link to the previous system's identity is dropped.

The remedy is a stable, system-generated identity for each CML, separate from any human-readable tag, with the tag as an attribute that can change. The identity sits in a hierarchy (site, unit, equipment or circuit, component, weld) so a plant-wide query is unambiguous, and every reading, drawing mark and photograph attaches to that identity. Tags, drawings and line numbers come and go; the identity and its history do not.

How should readings enter the CML record?

At plant scale, a transposed digit is indistinguishable from a corrosion event. A reading of 8.05 mm entered as 8.50 mm hides two years of loss; 8.50 entered as 8.05 creates a phantom short-term rate that triggers an unnecessary inspection. The controls:

• Direct gauge capture. Ultrasonic thickness gauges (the Evident 38DL Plus, Elcometer MTG and DeFelsko PosiTector UTG among them) send readings over Bluetooth or through a keyboard wedge. The value on the record is the value on the gauge, with the device identity attached.
• Context at capture. Technician, date and time, procedure, couplant, surface condition and temperature are captured with the reading, because the next reviewer will need them to judge whether a change is real.
• Prior reading visible. The technician sees the previous reading and nominal at the CML while measuring, so a gross difference is questioned on the spot, not six weeks later in the office.
• Grid capture in order. For grid CMLs, the app prompts each cell in sequence so the reading lands in the right cell.
• Photographs bound to the CML at capture, showing the marked location and the gauge display.
• Offline by default. Most CMLs are in places without coverage. Capture has to work fully offline and sync later with conflicts made visible at field level, not silently overwritten.

Bulk loading matters too. Legacy surveys arrive as workbooks, and the import has to map columns to CML fields explicitly, reject rows whose identity does not resolve, and keep the import itself as an audited event.

How do you govern adding, moving and retiring CMLs?

CML populations drift. Points are added after findings and never reviewed; points are dropped when a drawing is redrawn and no one notices. Governance keeps the population meaningful:

1. Adding a CML records the reason (finding, new mechanism, process change, RBI recommendation), the person, the date, and the baseline reading. A CML without a baseline has no long-term rate.
2. Moving a CML (correcting a marked location) creates a documented discontinuity: the old readings stay attached, flagged as taken at the prior location, and rates restart from the first reading at the corrected spot.
3. Retiring a CML requires a reason (circuit reclassified, equipment removed, redundancy demonstrated) and approval. The history is retained and readable; the CML simply stops being scheduled.
4. Repairs and replacements reset the history at the same identity with a new baseline and a link to the repair record.
5. Periodic review of the population per circuit: which CMLs have never shown loss, which show variable readings that suggest a location problem, which circuits have no CML at the expected worst location.

Each of these is a change to a controlled record, and each should be visible in the audit trail with who and why. A program that can show the history of its CML population, not only the history of each CML's readings, is one that can defend its inspection intervals.

How intelliSPEC handles it

intelliSPEC stores each CML as a record with 64 fields: nominal thickness, tMin and its method, design pressure, material, outside diameter and schedule, allowable stress, joint efficiency, corrosion allowance, grid geometry, latest thickness and three corrosion rates among them. CMLs sit in an asset graph of nodes with roles (company, site, facility, asset, component, weld), so a plant-wide query resolves to one location and the human-readable tag is an attribute that can change without touching the history. Damage mechanisms (thinning, cracking) are first-class records, so a CML monitoring for cracking holds its indications alongside a neighbor's thicknesses.

Drawing annotation detects CML points automatically on uploaded drawings and isometrics and links each mark to its CML record. When a 3D model is updated to a new version, the same asset nodes are updated in place, so inspection history is preserved across model revisions. Readings arrive from the Evident 38DL Plus, Elcometer MTG, DeFelsko PosiTector UTG and other gauges over Bluetooth or keyboard wedge without retyping. Field capture in intelliNDT and intelliINSPECT works fully offline with no time limit on the local store, and a conflict between two technicians on one CML is recorded at field level with both values, who resolved it and when.

intelliINTEGRITY computes tMin by equipment type with the design code and formula shown, the three corrosion rates with the maximum governing by default, remaining life and the API 510 or API 570 interval capped at half the remaining life, all provisional until an engineer verifies them. Legacy surveys load through Excel workbook import with assisted column mapping, and an open API with a documented OpenAPI 3.0 specification is the integration surface. Every create, update, import and export lands on a hash-chained audit trail, so the history of the CML population is as auditable as the readings. Terms are defined in the glossary.