Demo anfordern
Zur Übersicht

Blog

Pipeline Fitness-for-Service Software: From ILI Data to Repair Plans

18 September '26

pipeline fitness for service software

If your FFS (Fitness-for-Service) process still lives in a spreadsheet, you are already doing by hand what pipeline fitness-for-service software does automatically. This piece walks through how ILI (In-Line Inspection) data becomes a Corrosion Tolerance calculation, how that calculation feeds a Risk-Based Assessment, and how the two together turn into a repair plan you can actually schedule around. The gap between the manual version and the connected chain is exactly where a calculated number quietly stops matching the pipeline’s actual condition.
Here is what usually goes wrong, and what replaces it.

Why Manual Fitness-for-Service Assessment Fails

Every pipeline engineer knows the routine after an ILI run. A contractor delivers pipe tally data, usually as a report or raw export. Someone manually transcribes the relevant numbers into a tracking spreadsheet, checks them against the wall thickness already on file, and recalculates Corrosion Tolerance and Safe Working Pressure by hand. That spreadsheet becomes the de facto record, even though nobody ever formally approved it as such.

That setup is fragile in two separate ways. First, the file itself can break. A formula gets overwritten, a cell reference shifts when someone inserts a row, or an old version gets used by mistake. When that happens, the trail behind the number disappears. If the person who built the spreadsheet leaves the company, so does part of the process knowledge. Second, there is no review step built in. Anyone with edit access can change a value directly, with nothing standing between a calculation and a decision that gets made based on it.

This is not a data problem. You already have the ILI data. It is a workflow problem. Too many manual handoffs occur between when inspection data arrives and when a repair is actually scheduled.

What Breaks Down in a Manual FFS Process

Three things break down in practice.

  • Wall thickness has to match, and nobody checks it automatically. Every pipe tally or dig-up import needs to be reconciled against the wall thickness already on file. Miss a mismatch, and the Corrosion Tolerance calculation is wrong before you even start.
  • The calculation gets rebuilt every cycle. Corrosion Tolerance and Safe Working Pressure depend on the design factor, the failure pressure of the undamaged pipe, and the remaining strength factor from corrosion defects. Calculating these is the core of a pipeline Fitness-for-Service assessment under a code such as ASME B31G, Modified ASME B31G, or DNV-RP-F101.When the calculation is rebuilt manually, a single incorrect input can pass unnoticed. The error may only become visible later. Sometimes it shows up when the resulting Remaining Life appears inconsistent with the inspection history. Other times it surfaces only after repair work has already been planned. In the worst case, a defect that should have triggered corrective action is not flagged at all. It then continues to grow until the next inspection cycle catches it, or it contributes to a loss-of-containment event.
  • Nothing connects automatically. Corrosion Tolerance needs to feed a Remaining Life estimate. That estimate needs to set the next inspection date. The date needs to trigger a defect review, and if the numbers are bad enough, a repair. In a spreadsheet-based process, each step lives in a different file, on a different laptop. The pipeline does not wait for your files to sync.

What Pipeline Fitness-for-Service Software Automates

Remove the manual reconciliation, and this is the chain that is left.

  1. Import. An ILI run returns pipe tally or dig-up data. You create a Condition History, record the inspection date, and set the assessment code, then import the data directly.
  2. Reconcile. The system checks imported wall thickness against what is already on file, section by section. A mismatch shows up immediately instead of further downstream.
  3. Calculate. Corrosion Tolerance and Safe Working Pressure are calculated, not rebuilt. Before it can be used further, the Condition History must be final approved, giving the review step a spreadsheet never had. Both values recalculate automatically if a later corrective action removes a defect.
  4. Assess Remaining Life. Once approved, the past corrosion rate derived from inspection history is combined with the Corrosion Tolerance from your FFS assessment to calculate Remaining Corrosion Tolerance. That figure is then paired with the future corrosion rate projected by engineers to set Remaining Life. From there, a Risk-Based Assessment (RBA) weighs the section’s criticality, how likely it is to fail and how bad it would be if it did, to set the next inspection date.
  5. Prioritize the Repair. If Remaining Life drops low enough, defects are ranked and a repair plan sets which ones get fixed and when. That plan is reviewed and approved before the work order goes out.
fitness from service software 5 steps

That is the real answer to how pipeline Fitness-for-Service software turns ILI data into a repair plan. It is a five-step chain, each feeding the next, with an approved Condition History behind every number.

None of these steps requires a new methodology. ASME B31G, Modified ASME B31G, and DNV-RP-F101 work the same way they always have. What changes is who does the reconciliation work between them. Instead of an engineer, the software does it.

The Business Impact of Automated FFS Assessment

For the asset manager, this reduces the number of contractor days spent reconciling data rather than inspecting. A wall thickness mismatch caught at import is a five-minute fix. Caught two weeks later during a scope review, it becomes a re-inspection or a delayed turnaround decision. The gap widens with scale. Reconciling one pipeline by hand is manageable. Reconciling the same steps across fifty or a hundred sections in a portfolio, every ILI cycle, is where manual FFS stops being a nuisance and starts eating budget.

For whoever owns the budget, the FFS-to-RBA-to-repair chain changes the timing of the spend, not just its size. RBA ranks pipeline sections by risk, not just by age or schedule, so the budget goes where the actual exposure is. A pipeline section showing a two-year Remaining Life gives you time to plan a repair during a routine shutdown. That protects revenue. It also means capital spending stays tied to the actual pipeline condition. You replace a section when the data calls for it, not out of caution alone, which keeps CAPEX closer to what the asset needs.

Compare that to a section replaced two years early because nobody trusted the last spreadsheet update. That is not caution. It is a budget decision made on incomplete information, and it is exactly the kind of spending that a connected FFS-to-RBA chain is built to prevent.

The Case for Replacing Spreadsheets with FFS Software

The FFS-to-RBA-to-repair chain does not replace engineering judgment. An engineer still sets the assessment code, projects the future corrosion rate, reviews the Condition History, and signs off on the final approval. What changes is where that engineer spends their time. Instead of rebuilding a wall thickness check and a Corrosion Tolerance formula for the fifth time this year, engineers can review a traceable, approved result alongside earlier assessments and calculations from other sources already available in the software. This broader context helps them make a more confident decision about the appropriate action.

That is the real case for moving Fitness-for-Service off a spreadsheet. Not that spreadsheets are outdated, but that every hour spent reconciling data by hand is an hour not spent deciding which pipeline needs attention first, and which contractor day can be skipped.

How IMS PLSS Handles Fitness-for-Service Assessment

The Fitness-for-Service software behind everything described above is part of IMS PLSS (Pipeline and Subsea Systems), Cenosco’s pipeline and subsea integrity software. Inside it, the value compounds over time: every FFS cycle adds a Condition History, and every Condition History sharpens the corrosion rate used in the next RBA calculation, so a Remaining Life estimate built on five ILI cycles rests on more history than one built on your first.

IMS PLSS also reads that accumulated history back to you. Instead of rereading years of past narratives by hand, an AI summarization tool generates a concise summary of what has been found over time.

Running FFS in a spreadsheet is not a technology preference. In Cenosco’s Digital Maturity Framework, it is a Level 1 pattern, built around individual expertise rather than a governed process, and it caps what you can do downstream, no matter how advanced your RBA or repair planning gets. Connecting FFS to RBA and repair planning elevates this workflow to Level 3, where the process runs on structured, connected steps rather than on a single person’s spreadsheet.

Bereit für eine Demo?

Want to see how IMS PLSSconnects Fitness-for-Service to Risk-Based-Assessment? Request a demo.

denis tkalec cenosco

Denis Tkalec Technical writer

Denis Tkalec is a technical writer at Cenosco, specializing in asset integrity management software since 2022. With a background in education and six years in marketing, she turns complex topics into clear, user-friendly content. Inspired by Camus’s belief that “a writer keeps civilization from destroying itself,” she brings precision and care to every manual.