Building a Shutdown Scope From Historian Data
The Most Expensive List in the Business
A major turnaround is the largest single maintenance event a plant runs, and the scope that drives it is usually built the worst way possible: from memory, from a wish list, and from whoever argued loudest in the planning meeting. Someone remembers a pump that sounded rough in March. A superintendent wants a valve replaced because it failed last time. A vendor recommends overhauling an exchanger on a fixed interval whether it needs it or not. The list grows, the budget grows with it, and a good share of the work turns out to have been unnecessary while the failure that actually mattered was not on the list at all.
This is not a planning discipline problem. The planners are usually excellent. It is a data problem. The evidence that would tell you which equipment is degrading, how fast, and whether it will survive to the next window is sitting in the historian, recorded continuously for years, and almost none of it reaches the scope meeting. The scope is built on anecdote while the measurement that would settle the argument goes unused.
This article is for maintenance and reliability managers, turnaround planners, rotating and fixed equipment engineers, and the operations leaders who sign off the shutdown budget. Having worked on historian and plant performance systems for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms, across 18 years in industrial data, the recurring finding is that the single biggest lever on turnaround cost is not execution efficiency. It is building the right scope in the first place, from evidence rather than recollection.
Why Scope Is the Lever That Matters
The economics of a turnaround are brutal and well documented. Turnaround benchmarking published by AP-Networks has reported that a large majority of turnarounds miss their cost or schedule target by a material margin, with a substantial share overrunning by more than thirty percent. The causes cluster around scope: too much low-value work planned in, and too much unplanned work discovered once the plant is open and it is far too late and far too expensive to react well.
Both failures have the same root. Scope was decided without evidence. Work went on the list that the data would have shown was not needed, and work stayed off the list that the data would have flagged months earlier. Every item you add costs labour, materials, and critical-path time. Every real degradation you miss becomes a discovery item at the worst possible moment, or a trip after startup that undoes the whole event. Getting scope right is worth more than any gain in execution speed, because it attacks both sides of the overrun at once.
Two Ways to Build a Shutdown Scope
| Metric | Memory and wish list | Historian evidence | Improvement |
|---|---|---|---|
| What drives an item onto the list | Who argued for it | Measured degradation rate | Objective |
| Fixed-interval overhauls | Done regardless of condition | Deferred when trends are flat | Avoided waste |
| Hidden degradation | Found as discovery work mid-event | Flagged months ahead | Planned, not reactive |
| Budget defensibility | Hard to justify to the board | Traceable to evidence | Auditable |
| Post-startup trips | Common | Reduced by catching the real risks | Lower |
What the Historian Already Knows
The data you need is not exotic. It is the ordinary process and equipment history you already record, read for a different question than the one it was stored for. A few examples make the point concrete.
A pump that is wearing shows it long before it fails. The differential it produces for a given speed drifts down, the motor current pattern changes, vibration overalls climb, and the gap between duty and standby performance widens. None of that is a single alarm. It is a slope in the trend, visible over months, that tells you this machine should be on the scope and that one should not. A heat exchanger fouls on a curve you can measure: the approach temperature creeps up and the heat transfer coefficient you can calculate from the existing flow and temperature tags declines toward the point where cleaning pays for itself. A control valve that is passing or sticking reveals itself in the relationship between its output and the process variable it is supposed to move.
The principle behind all of it is the P-F interval, the window between the point where a failure becomes detectable and the point where it becomes functional. The historian is where detectability lives. The question a scope should ask of every candidate item is simple: what does the trend say, and does the degradation rate mean this will or will not survive to the next window? That is a question the data can answer and a planning meeting cannot.
From Trend to Scope Item
The Reason the Data Stays Unused
If the evidence is already recorded, why is scope still built from memory? Three practical barriers, and none of them is a shortage of data.
The first is access. The reliability engineer who should be reading the trends often cannot get at the historian easily, or can only see one tag at a time through an interface built for operators, not analysts. Getting equipment history into a tool where it can be worked at scale, without standing up a second historian, is a solved problem, and we covered it in our guide to getting historian data into Power BI. Until that path exists, the data may as well not be there.
The second is context. A trend is only diagnostic if you know what the tag means, in what units, measured where. A degradation slope on a mislabelled or ambiguous tag is worse than no data, because it invites a confident wrong conclusion. This is the same foundation problem that sits under every analytics effort on a plant, and it is why tag naming and OT data standards decide whether this kind of analysis is even possible. An asset framework that carries consistent, templated attributes across every pump and exchanger is what lets you ask one question across a whole class of equipment, which is the point of building reusable asset templates.
The third is time. Scope is built under deadline, and reading trends asset by asset for a large plant is slow if done by hand. This is where analytics and, increasingly, AI earn their place, by doing the first pass across the whole estate and surfacing the handful of assets whose trends warrant an engineer's judgement.
Should This Item Be on the Scope?
Where AI Fits, and Where Judgement Stays
The honest version of the AI story here is narrow and useful. A model is good at the first pass: reading thousands of equipment trends, flagging the ones whose degradation rate is changing, and ranking candidates so a limited engineering team spends its attention where it matters. It is good at catching the slow drift that a human scanning one screen at a time will miss. It is good at combining several weak signals, differential, current, vibration and temperature, into a single judgement about one machine.
What it does not do is make the call. Whether a flagged exchanger is scoped this window or the next is a decision that weighs production risk, parts lead time, critical-path impact and safety, and that belongs to the reliability engineer and the turnaround manager. The useful framing is that AI narrows the field and a person decides the scope, not the other way round. An agent reading operational data needs the tag context and a read-only boundary far more than it needs a particular model, the same point we make about any AI over OT data.
This also connects to inspection. Risk-based inspection under API 580 already asks you to direct inspection effort by likelihood and consequence of failure rather than by calendar, and historian-derived degradation rates are exactly the likelihood evidence that discipline is supposed to run on. Using process history to inform the inspection scope is the same move as using it to inform the maintenance scope, applied to fixed equipment.
An Evidence-Led Scope, Working Backward From the Window
The Return Is in What You Do Not Do
The payoff from an evidence-led scope comes from two directions. You remove low-value work that was going to happen on a calendar regardless of condition, which gives back labour, materials and critical-path days. And you catch real degradation early enough to plan for it, which converts expensive discovery work and post-startup trips into ordinary planned items. The figures below are illustrative of the shape of that return for a hypothetical plant, not a claimed result, but the direction is consistent wherever scope moves from recollection to evidence.
Where an Evidence-Led Scope Pays (illustrative)
For the people who approve the spend, this is the difference between a scope that is a negotiated wish list and one that is a traceable argument. A board or an executive asked to sign off a large turnaround budget can reasonably ask why each major item is on the list, and "the trend shows this machine will not survive to the next window" is an answer that holds up where "we usually do it" does not. This is the same evidence-first posture we recommend for AI and operational decisions at board level, and it rests on the same prerequisite: operational data that is accessible, named consistently and trusted.
How to Start Before the Next Window
You do not need a platform or a transformation programme to begin. Pick the next turnaround with enough runway, choose one or two equipment classes where failure hurts most, and assemble their history now. Measure degradation rates rather than reading snapshots. Bring the ranked shortlist to the reliability team as input to the scope, alongside the usual sources, and record which evidence-led items earned their place and which wish-list items the data did not support. One window of that is enough to show whether the scope got better, and it builds the case for doing it systematically.
The same discipline that makes this work, accessible history, consistent naming and a trusted asset model, is the foundation under production reconciliation, alarm rationalisation and every other analytics job on the plant, which is why we treat it as one programme rather than a series of one-offs. We covered the reconciliation side in when SCADA and the ERP disagree on tonnes and the alarm side in rationalising alarms from historian evidence. If you are planning a turnaround and want the scope built on what the data actually shows, that is the kind of scoping work an Australian AI and operational data consultancy is built to do, and it is worth having the conversation while there is still runway to the window.
Common Questions
How do you build a shutdown scope from historian data?
Start by assembling several years of process and equipment history for each candidate asset, then measure the degradation rate rather than reading a single snapshot. For each item, project the trend forward and ask whether the equipment will survive to the next maintenance window. Items with a clear slope toward failure are scoped in, flat trends on interval-driven work are deferred, and ambiguous signals are resolved by fixing the tag context before deciding.
Why do so many turnarounds overrun?
The dominant cause is scope, not execution. Turnaround benchmarking published by AP-Networks has reported that a large majority of turnarounds miss their cost or schedule target by a material margin. Low-value work gets planned in because it was decided by recollection rather than evidence, and real degradation gets missed and becomes expensive discovery work once the plant is open. Both failures come from building scope without the data that would have settled it.
Can AI decide what goes into a turnaround scope?
No, and it should not. AI is useful for the first pass, reading thousands of equipment trends, flagging changing degradation rates, and ranking candidates so a limited team focuses its attention. The decision on whether an item is scoped this window weighs production risk, parts lead time, critical-path impact and safety, and belongs to the reliability engineer and turnaround manager. The right framing is that AI narrows the field and a person decides.
What data do you need before this works?
Three things: accessible equipment history that a reliability engineer can work at scale rather than one tag at a time, consistent tag naming and context so a trend can be trusted, and an asset model that lets you ask one question across a whole class of equipment. Without those, degradation slopes are either unreachable or ambiguous, and an evidence-led scope is not possible no matter what analytics sit on top.
How does this relate to risk-based inspection?
They use the same evidence. Risk-based inspection under API 580 directs inspection effort by the likelihood and consequence of failure rather than by calendar, and historian-derived degradation rates are exactly the likelihood evidence that discipline runs on. Using process history to inform a maintenance scope and using it to inform an inspection scope are the same move, applied to rotating and fixed equipment respectively.
Related Reading
- Tag naming and OT data standards: the decision AI depends on
- Getting historian data into Power BI without a second historian
- PI Asset Framework templates that survive a plant change
- Rationalising alarms from historian evidence
- When SCADA and your ERP disagree on tonnes
- What Australian boards should ask before approving AI
- AI for Australian manufacturers and industrial operations