Freezing outage scope on thickness data you can defend

Outage scope is written months before the plant is cold

The uncomfortable structural fact of nuclear inspection planning is that every important decision is made while the plant is at power and nothing can be verified. Scope development runs from roughly six months out. Scaffold packages, insulation removal work orders, contract crew mobilisation, radiological work permits and dose estimates all key off a frozen list of components. By the time anyone puts a probe on steel, the choice of what to inspect has already been made and the resources have already been committed.

That list is generated almost entirely from thickness history. A predictive FAC model narrows the candidates, but the acceptance decision, whether a component survives another cycle, is arithmetic on measured wall: last measured thickness, a wear rate, a cycle length and a governing minimum. Nothing in that chain is stronger than the record it is drawn from. If the last reading was taken from a grid nobody can locate, the projection is a guess wearing a decimal point.

So the practical test of a thickness history module in this industry is not how well it charts. It is whether, at scope freeze, it can produce a defensible ranked list of components with the uncertainty in each projection made explicit, and separately a list of everything last outage failed to measure. Most systems can do the first. Very few can do the second, because they never recorded a failure to measure as anything at all.

Every reading has a dose cost, so the record has to justify itself

Outside nuclear, a thickness reading is cheap and the temptation is to take more of them. Inside, a reading in a radiological area consumes person-rem against a budget the site defends under 10 CFR 20.1101(b), plus scaffold, plus insulation removal, plus containment access in a window with competing craft. Adding points is not free, and the ALARA committee will ask why each one is there.

This inverts the usual data argument. The question is not how to collect more readings but how to make each existing reading do more work. A point that has been read four times with consistent method, instrument and datum supports a regression and a bounded rate. The same four readings with unknown provenance support nothing better than a two-point comparison, and a two-point comparison between the first and last is precisely the calculation that gets challenged.

There is a direct planning consequence. When history is trustworthy, scope shrinks, because you can defend not inspecting a component whose bounded rate leaves comfortable margin. When history is untrustworthy, scope inflates defensively, and inflated scope in a nuclear outage means more scaffold, more dose, more critical path and a longer window. Data quality is not an administrative concern here. It shows up in person-rem and in days.

Repositioning error is usually larger than the corrosion you are looking for

Component grids on FAC-susceptible piping are dense, often a matrix of points at fixed axial and circumferential intervals referenced from a girth weld or a permanent marker. Wall loss between outages on a well-behaved component might be a few thousandths of an inch. The error in re-establishing a grid on insulated, painted, sometimes scaffolded-over pipe, after the reference marking has weathered through a cycle, can easily exceed that. The measurement is fine. The location is the problem.

This produces two recognisable artefacts. The first is a sawtooth trend at a single point, alternating thinner and thicker each outage, which is a location oscillation and not a corrosion mechanism. The second is a persistently rising wear rate at the band level, produced by comparing the minimum found in each outage against the minimum found in the last, when in fact the crew is finding a slightly different worst point each time as coverage varies.

The record has to make the pairing explicit rather than implied. That means storing the datum feature, the offset and orientation convention, the grid revision number, and any photograph or sketch that lets the next crew reproduce it. It also means the module should distinguish, in the data model, between a point-to-point comparison and a band statistic, and should refuse to present a band minimum trend as though it were a wear rate at a location.

Exclusions are the difference between a scope and a wish

An outage always ends with points that were not read. The scaffold arrived late. The insulation crew hit asbestos abatement. The component turned out to be behind a permanent obstruction nobody had drawn. Dose in the area went up after a resin transfer. The examination started and was stopped when the window closed. These are normal outage events and none of them reflects badly on anyone, provided they are recorded.

The failure mode is banal and consequential. When a planned point comes back as a blank cell in a spreadsheet, next outage's scope is built from the last available reading, which is now two cycles old, while the projection quietly assumes the interval was one cycle. The wear rate is halved. The component looks better than it is. Repeat that twice and a component with a real margin problem sits comfortably in the middle of the ranked list.

What is needed is a record that distinguishes not measured from measured and unchanged, carries a coded reason from a governed list, names who accepted the exclusion, and states what would have to be different for the point to be read. That last field converts the exclusion list into next outage's scaffold and insulation scope, which is the single most useful report this module can produce and the one most systems cannot generate at all.

Appendix B records outlive the software that made them

Criterion XVII of 10 CFR 50 Appendix B requires that records furnishing evidence of activities affecting quality be maintained, identifiable and retrievable, for a duration set by the licensee's quality assurance programme. Inservice inspection records supporting the plant's basis are frequently lifetime-of-plant. Plant life is now routinely being extended past sixty years. No inspection database vendor has existed for sixty years.

This is not a theoretical concern. Many stations are on their third or fourth inspection data system, and each migration is where provenance dies. Numbers migrate cleanly. Instrument serials, technician certification status as of the reading date, exclusion reasons, correction factors and the audit trail on edited values are the fields that get dropped, because they are the fields the new system does not have a column for. What arrives on the other side is a trend with no defence behind it.

Two requirements follow. First, the export must be complete, self-describing and independent of the application, so that the record can be read by a person with no access to the software. Second, the audit trail on any change to a reading, prior value, new value, reason, approver and timestamp, must itself be exportable, because the change history is part of the record, not metadata about it. Ask any vendor to demonstrate both, on real data, before signature.

The software quality question your QA organisation will ask first

Every other industry procures inspection software as an IT decision. In nuclear it lands on a desk in quality assurance, and the question is whether the application is being used in a way that makes its output credited in a safety-related evaluation. If a licensee credits a calculated remaining wall or projected end-of-cycle thickness in an evaluation supporting continued operation, the software that produced it comes within the scope of ASME NQA-1, and Subpart 2.7 addresses computer software for nuclear facility applications. Commercial products then have to be dedicated using the EPRI guidance in NP-5652 and its successors, with 10 CFR Part 21 obligations attached.

There is a legitimate architecture that avoids much of this, and it is worth deciding on deliberately rather than by accident. The database can hold and present readings, provenance, exclusions and history while the credited calculation is performed in a qualified tool or a controlled hand calculation, with the result written back as an attributed record. That keeps the management system in the non-safety domain and confines the dedication burden to the small piece that genuinely needs it.

What must not happen is for the classification to be settled after go-live, when an internal audit notices that engineers have been quoting a screen. Establish before procurement which outputs are credited, put the boundary in writing, and make the system display the classification alongside any calculated value. That single interface decision has saved stations more grief than any feature on a comparison matrix.

How to evaluate a system against an outage rather than a demo

Demonstrations are run on clean data by people who know where the buttons are. Evaluate against your worst outage instead. Take the messiest historical data set you own, one with a mid-outage crew change, a partially completed grid and a known repositioning argument, and ask the vendor to load it. What you are watching for is not whether it loads. It is what the system says about what it does not know.

Then ask for three reports. Every component projected below its governing minimum before end of next cycle, with the basis for each rate and the uncertainty stated. Every planned point not read in the last two outages, with reason and access requirement. Every reading in the data set whose provenance is incomplete, itemised by which field is missing. A system that can produce all three at scope freeze is directly reducing your dose and your critical path. A system that can produce none of them is a chart generator with a login page.

Finally, test the boring paths. Can a reading be corrected without destroying the original? Can a grid be revised without orphaning history? Can a technician's certification lapse without silently invalidating four years of accepted records? Can the whole thing be exported and read without the application? These are the questions that determine what the record is worth in year fifteen, and they are never on the feature list.

Request a consultation