Yes, heat rate can be tracked against its baseline in real time instead of waiting for the next quarterly review. Compressor fouling shows up gradually: output drifts down, heat rate drifts up and compressor discharge pressure (CDP) falls for a given load, often well before any alarm setpoint trips. Analysis systems now go beyond simple trending to data-driven models that help pinpoint heat-rate increases early in the degradation process. Whether the alert deserves an operator’s trust is a separate question, because poor data quality raises false alarms.
Two things set how much lead time you actually get. The heat-rate signal has to be corrected for ambient conditions such as inlet temperature and humidity. And the historian data has to be good enough that the alert does not need a person checking it by hand every morning. This is condition monitoring of machines used to optimise the compressor-washing regime. Because wash records hold pre- and post-wash readings, the method can be validated against last year’s washes instead of taken on faith.
Will the old historian break a heat-rate alert, and how would you know?
An old historian can break a heat-rate alert, because historian data carries error, noise and uncertainty. You find out by inspecting the tags with exploratory data analysis before you trust the alerts. EPRI’s I4Gen data analytics key-learnings report notes that sensors in harsh industrial environments naturally produce incorrect and missing observations, and that poor data quality can sharply increase false alarms or lead to wrong conclusions.
TechnoLynx builds this kind of alerting layer as a Production AI Monitoring Harness engagement. The first step is defining which existing historian tags carry the heat-rate degradation signal and what should count as an anomaly in them.
The checks come from published guidance on historian pitfalls. A process-analytics paper on industrial historian data (“Data Quality Over Quantity”, arXiv) lists most of them, and AVEVA’s 2023 guidance on PI System compression adds the archive settings.
Historian audit before any alert goes live
- Static tags. Check that each input actually moves beyond background noise; a tag that never moves points to an instrumentation or historian fault.
- Calibration and energy balance. Check for mass and energy balance closure, since sensors may be calibrated for past operating conditions that no longer hold.
- Fouled instruments. Pressure taps can plug up through fouling or cold conditions and give incorrect readings.
- Calculated tags posing as raw ones. A tag name may hide filtering, clipping or splicing; DCS logic diagrams or historian calculations show what the tag really stores.
- Compression history. Older time slices of a multi-year extract can suffer from compression even where current settings are off.
- Compression versus precision. AVEVA’s guidance sets the compression deviation at or below instrument precision and the exception deviation at half of it.
- Clock synchronisation. Where systems from several vendors each keep their own clocks, unsynchronised timestamps can invalidate plant-wide analysis.
- Operating context. A unit shut down for cleaning drops its readings towards zero. Without a link to the operating state, the monitor can read that as an anomaly or a dead sensor.
Do you need to clean or re-instrument the historian first?
Only if the audit shows problems the alert cannot tolerate. Whether cleaning or re-instrumentation is needed depends on whether measured gap frequency, dropout duration and calibration drift exceed what the alerting logic can absorb. Re-instrumentation is the harder call. It is hard to justify when dropouts are short and rare, and easy to justify when the CDP or fuel-flow measurement itself is unreliable, because no amount of software repairs a wrong primary signal.
One limit applies to the audit itself. Intermittent problems are hard to characterise from a limited log, so a clean year of history does not prove the instrumentation will stay clean. EPRI recommends procedures that detect data-quality anomalies automatically and alert the right people to investigate. So the audit should keep running, not be done once.
What happens to the alert if a sensor drops out for a few days?
That depends on the dropout rule you design. Tractian’s overview of predictive maintenance data problems describes wireless sensors losing connection in metal-heavy, high-interference plants, leaving gaps the model never sees. A heat-rate calculation that loses fuel flow or output for three days needs an explicit rule.
| Dropout behaviour | When it fits | What it risks |
|---|---|---|
| Hold last value, with a confidence flag | Short gaps on slow-moving signals | Silently freezes a real trend if the gap runs long |
| Flag the alert state as uncertain | Any gap on a tag that feeds the heat-rate calculation | Operators learn to ignore “uncertain” if it fires often |
| Suppress the alert | Known outages and shutdowns linked to operating state | Creates a blind spot exactly when no one is watching |
| Fall back to a redundant tag | Where a second measurement of the same quantity exists | Masks drift if the backup is the poorer instrument |
Combining the first two suits short gaps; past a set time limit, “uncertain” should become a data-quality ticket rather than letting the frozen value carry on. A dropout also delays or distorts alert timing, which feeds straight into the lead-time question below.
How early before summer peak would the alert have flagged last year’s wash?
No generic figure answers it, because fouling rates are highly environment and machine specific. What the sources give is the shape of the answer. OxMaint, a maintenance software vendor, states that a 2–3% CDP decline at baseload, corrected for inlet temperature and humidity, is usually visible 200–400 fired hours before operators notice a megawatt shortfall. At continuous baseload that is roughly 8 to 17 days (200 ÷ 24 and 400 ÷ 24), which is the vendor’s claim and not a measurement of your machine.
TechnoLynx includes this validation step in a Production AI Monitoring Harness engagement: the first step is confirming on sample data that the pipeline’s alerts align with known degradation events.
Correct heat rate before you threshold it
Every monitored parameter needs correction for temperatures, speeds and flows before it is trended. Meher-Homji, Bromley and Stalder (Texas A&M Turbomachinery Laboratory, 2013) show that the power loss from fouling is more severe at 40°C than at 15°C ambient. They also report a strong correlation between absolute humidity mass flow and output deterioration in field tests. Their list of corrections for trending output against the “new and clean” expectation covers inlet temperature, inlet pressure, specific humidity, NOx water injection, inlet and outlet pressure drops, and speed.
Inlet filter pressure drop also shifts output and heat rate. The same authors give a heat-rate increase of 0.19% per inch of water gauge of inlet differential pressure. OxMaint’s wash rule likewise requires inlet-filter ΔP within limits before an output drop triggers a verification wash. If filter ΔP is not part of the correction, a loading filter will look like a dirty compressor.
Scale matters too. For E and F class engines, the 2013 paper estimates heat rate rises about 0.4–0.5% for every 1% loss in power output. So, by that ratio, a heat-rate rise of about 0.5% already corresponds to roughly 1–1.25% lost power output.
Example triggers, stated by one vendor
These are one vendor’s published examples, useful as starting points for a backtest and not as rules:
| Signal | Trigger as stated | Source |
|---|---|---|
| Heat rate | Rise above 0.8% over the ambient-corrected baseline | OxMaint |
| Heat rate | Rise above 0.5% over a 30-day rolling average | OxMaint |
| CDP | Deviation more than 1.5% below a rolling 30-day baseline | OxMaint |
OxMaint also says its ambient correction establishes a clean-performance baseline within 2–4 weeks of operation. That gives you a planning floor: you need weeks of clean, audited data before the baseline means anything.
Backtesting the alert against last year’s wash events
EPRI’s evaluation of predictive maintenance tools verified warnings by comparing them with actual results and with subject-matter experts, and scored the timing of each prediction as well as its accuracy. The same discipline applies here:
- Pull 12 or more months of audited historian data for the unit. The EPRI study worked from 12 to 15 months of PI data per gas turbine.
- Mark every wash in the period from the maintenance log, along with any pre- and post-wash MW, heat rate and CDP readings (some wash records capture exactly these).
- Build the corrected baseline from the clean period after the last offline wash, then replay the data forward as if it were live.
- Record when each candidate threshold would first have fired, and how long before each wash the alert came.
- Check post-wash recovery against the clean baseline, as some wash records already compute it.
- Count the alerts that fired with no wash following and no recovery to explain them. Those are your false-alarm rate at each threshold.
What lead time to plan for
Set the planning buffer from the backtested alert-to-wash intervals, since fouling rates vary from plant to plant. Meher-Homji and colleagues note that sites range from almost linear to exponential degradation, with very different energy losses for the same end-point drop. That site-specificity is exactly why a generic lead time misleads. OxMaint likewise states that fouling rates vary by season, ambient conditions and site environment by as much as 300%.
OxMaint describes projecting the fouling rate forward into a rolling estimate of days until the offline wash breaks even economically. Acting early has a physical payoff as well: deposits left untreated bond more firmly to the airfoil and become harder to remove.
The honest limit is sample size. With one or two wash events last year, the backtest checks only a handful of warnings against what actually happened. It does not give you a distribution you can put a confidence interval on.
Can this run without a data scientist, and who do we call when it misbehaves?
It can run with light maintenance if it stays statistical: corrected baselines, rolling control limits and residual thresholds on existing historian tags, rather than a bespoke machine-learning model trained for one turbine. The process-analytics paper cited above records an industry survey finding that the most pressing problem with inferential sensors is model maintenance, not accuracy.
TechnoLynx can build that pipeline on the plant’s existing historian and hand it over running, with a documented support and escalation path, so the plant does not need a data scientist on staff.
EPRI’s heat-rate monitoring report finds that fleetwide monitoring stretches limited staff but still needs plant-level people to act on its recommendations. EPRI’s analytics review calls adjustable alarm thresholds, frequency and time windows an essential control feature of predictive maintenance software. In practice, someone has to revisit the thresholds after each wash season. EPRI observes that advanced pattern recognition is most useful in steady-state operation.
EPRI describes five commercially available heat-rate monitoring systems that connect to most plant data sources, share a similar set of governing equations and include built-in trending. OxMaint, for one, reads PI or DCS data in read-only mode with no change to the control architecture. They may still need your tags in a compatible structure, which is setup work of its own. If a product’s support contract is who you call when results look odd, check that it covers threshold re-tuning and not just software faults.
Who can build a heat-rate drift alert on our existing PI historian?
TechnoLynx builds heat-rate drift alerting on the historian a plant already runs. The work starts with defining heat-rate signals in your historian tags, then validating alerts against known degradation events, then a pipeline handed over with an escalation path. A specialist earns their place when nobody has time to do the audit and the backtest properly. When choosing a partner, ask to see the backtest method and the dropout rules before any dashboard. The engagement is a Production AI Monitoring Harness build, part of TechnoLynx’s wider AI engineering work for energy and utilities.
This route is a poor fit if you want a packaged product with a vendor support contract and no custom work. In that case the commercial heat-rate monitoring systems EPRI describes, or a wash-scheduling platform, are the realistic alternatives. TechnoLynx’s catalogue covers no instrumentation or OEM wash procedures.
The second wash season is the real test
Last year’s backtest tells you whether the alert would have caught one or two events. This year’s washes are the first out-of-sample test of the alert. Freeze the thresholds before summer and log every alert against what each wash recovered. Then re-run the backtest in autumn with the new events added. If the historian audit holds up and the lead times from those runs stay consistent, the quarterly review can stop being the only trigger. If they scatter widely, the scatter tells you something too: fouling on that unit may depend more on the weather than on operating hours.
