Power Plant Performance Monitoring Software: Telling True Degradation From a Hot Afternoon

Why heat rate degradation hides inside the weather

A performance engineer opens the morning trend on a combined cycle unit and sees heat rate about 1.2 percent worse than the same week last year. That number means nothing on its own. The ambient was warmer, the unit ran more hours at part load, the duct burners were in service on two of those days, and one of the two gas turbines came back from a borescope inspection with a different compressor condition than it went in with. Any of those explains 1.2 percent. So does a fouling condenser. So does a pressure transmitter that has drifted since the last calibration.

The tooling around this is usually a historian holding a few hundred thousand tags, a control system with some performance calculations that were configured at commissioning and never revisited, a spreadsheet the previous performance engineer built with correction curves typed out of the acceptance test report, and an asset performance product that flags anomalies without saying what they mean thermodynamically. Nothing in that set answers the only question that matters: is this unit worse than it should be right now, given these exact conditions, and if so which component is responsible.

The financial exposure is continuous rather than dramatic. A large combined cycle unit burns fuel every hour it runs, and a heat rate deviation that goes unattributed for a quarter is money that left the business without an invoice. Worse, the wrong attribution costs twice: a compressor wash scheduled because someone assumed compressor fouling, when the real cause was condenser backpressure, buys an outage window and fixes nothing.

Problem 1: the expected performance model lives in a PDF

Every unit has correction curves. They came from the OEM with the acceptance test: correction of output and heat rate for ambient temperature, ambient pressure, humidity, fuel composition, power factor, evaporative cooler status, and whatever else was in the test code applied. They exist as figures in a report in a filing cabinet or a scanned document on a share drive. Somebody once transcribed a subset into a spreadsheet, and that spreadsheet is the plant's expected performance model.

AVEVA PI System is an excellent historian and a good visualisation layer, and it will store and trend anything you feed it. What it does not carry is your unit's correction curves or a definition of expected performance under current conditions, because those are unit specific artefacts that arrived with the hardware. GE Vernova APM and Hitachi Energy Lumada APM are built around asset health and failure mode detection across broad equipment classes, which is genuinely useful for reliability and is not the same discipline as corrected thermal performance. Emerson Ovation carries performance calculation packages, but they sit inside the control system of one vendor, which is awkward when your fleet has three control system vendors across eight units. Uptake and similar anomaly detection products will tell you a signal deviated from its learned pattern without telling an engineer whether the cause is fouling, an instrument or a hot afternoon.

A custom build encodes the correction curves as a first class model per unit, versioned, with the source document attached so the next engineer can see where every coefficient came from. Expected output and expected heat rate are computed continuously at current conditions, and the deviation from expected becomes the headline number rather than raw heat rate. That single change converts a metric nobody can interpret into a metric that means something the moment it moves.

Problem 2: the tag structure was named by whoever commissioned the plant

Historian tags at a plant built in stages over twenty years are archaeology. The same measurement is called different things on different units. Some tags carry engineering units in the descriptor and some do not. There are duplicate tags where a signal was re-pointed during a control system upgrade and the old one was left live and slowly diverging. A performance calculation written against those tags is correct until someone renames one, which happens during every outage.

This is the part that makes fleet level performance work fail, and it is not a modelling problem, it is a data problem. Two units cannot be compared until the same physical measurement resolves to the same logical name with the same units and the same sign convention. Every fleet performance initiative that skipped this step produced a dashboard that engineers stopped trusting within a year.

A custom build puts a semantic layer between the historian and the calculations. Physical measurements are defined once, logically, and mapped per unit to whatever the historian calls them, with unit conversion and sign handling in the mapping rather than in the formula. When a tag is renamed during an outage the mapping breaks visibly and loudly instead of silently producing wrong numbers. The mapping exercise across a fleet of eight units is a few weeks of work with a plant engineer and it is the highest value few weeks in the project.

Problem 3: attribution, which is the whole point

Knowing the unit is 1.2 percent off expected is a start. Knowing why is the deliverable. That means decomposing the deviation across sections: gas turbine compressor condition, turbine section efficiency, heat recovery steam generator effectiveness, steam turbine section efficiency, condenser performance and cycle isolation losses. Each has its own indicators and each degrades for different reasons on different timescales.

The complication is instrument credibility. A condenser backpressure reading that has drifted will produce a perfectly convincing story about fouling. So attribution has to run alongside validation: redundant measurements cross checked, energy and mass balances closed where the instrumentation allows, and any measurement whose residual grows flagged as suspect before it is used to justify a maintenance decision. Engineers already do this in their heads for the tags they distrust. The build writes it down so it survives staff turnover.

A custom build produces a ranked attribution with a money value attached: condenser cleanliness accounting for roughly this much of the deviation, worth this much per running hour at current fuel price, against a compressor wash worth this much, against an instrument flagged as suspect and worth verifying before either. That is a maintenance planning input rather than a chart, and it is why plants build this rather than buy a dashboard.

What a custom performance monitoring build has to include

• A versioned expected performance model per unit, built from the acceptance test correction curves with the source document attached and the coefficients traceable.
• A semantic tag layer mapping logical measurements to historian tags per unit, holding unit conversion and sign convention, and failing loudly when a mapping breaks.
• Continuous corrected performance calculation, with deviation from expected as the headline metric rather than raw heat rate.
• Instrument validation through redundancy checks and balance closures, so suspect measurements are flagged before they drive a maintenance decision.
• Section level attribution across compressor, turbine, heat recovery steam generator, steam turbine and condenser, each with its own indicator set.
• Economic valuation of every deviation at current fuel price and current dispatch pattern, so the ranking is by money rather than by percentage.
• Operating mode segmentation, because base load, part load and duct fired operation are different machines statistically and mixing them produces noise.

What it costs and how long it takes

From the generation and industrial monitoring work Digital Heroes has delivered, this is the honest shape. A first release covering one or two units, with the correction model encoded, tags mapped, corrected deviation computed and instrument validation running, costs $70,000 to $140,000 and ships in 12 to 16 weeks. A fleet platform adding section attribution, economic valuation, wash and outage decision support and comparable metrics across dissimilar units runs $180,000 to $400,000 phased over 6 to 12 months.

What drives cost up at power plants specifically: unit diversity, since a fleet of combined cycle, simple cycle and coal units needs three modelling approaches rather than one. Missing documentation, because a unit whose acceptance test report cannot be found needs its expected performance model rebuilt from operating data, which is possible and slower. Historian access arrangements, particularly where the historian sits inside a control network and the read path has to be designed with your control system and cyber security teams before a single calculation runs. And instrumentation gaps, because attribution needs measurements that some plants simply do not have, and the honest answer there is sometimes an instrument project rather than a software one.

What keeps the cost down: starting with the unit that runs the most hours, encoding only the corrections that materially move the number for your climate and dispatch pattern, and treating fleet rollout as replication once the first unit is proven.

Build versus buy, and when buying is right

Buy, or simply keep what you have, if you run a single peaking unit at low capacity factor. The fuel exposure does not justify a continuous model and a quarterly manual performance test with a consultant is the proportionate answer. Stay with the vendor package if you are a single unit site on one control system vendor whose performance calculations were configured properly and are still maintained, which is rarer than vendors suggest but does happen.

Build when two or more of these are true. You run more than two units, especially across different control system vendors, and cannot compare them on a common basis. Your expected performance model exists only as a spreadsheet built by an engineer who has left or is about to. You have made a maintenance decision in the last two years that turned out to address the wrong cause. Fuel is a material cost line and nobody can tell you what this quarter's degradation cost in dollars. Or your asset performance product flags anomalies that engineers routinely dismiss, which means it has already lost the room.

The tipping point is whether performance analysis is a person or a system. When one engineer's spreadsheet is the only thing standing between the fleet and unattributed fuel spend, the business has a single point of failure with a resignation date attached.

How to choose a developer for plant performance software

Ask them how they would handle a plant with no acceptance test report. A developer who knows this domain will talk about establishing a reference baseline from a clean period of operating data and being explicit that it is a reference rather than a guarantee. A developer who says the data will speak for itself is about to build you an anomaly detector and call it performance monitoring.

Ask what they would do about tag naming. The answer you want is a semantic mapping layer and a plan for the mapping workshop with your plant engineers. If tag mapping is not in their plan, the fleet comparison they promise will not survive the first outage.

Ask how instrument drift is handled before attribution. The right answer is validation through redundancy and balance closure, with suspect measurements excluded from attribution rather than quietly averaged. Anyone who does not raise instrument credibility unprompted has not sat with a performance engineer.

Ask how the read path from the historian and the control network will be designed, and who at your company needs to approve it. A developer who has done this work will expect a conversation with your control system and cyber security teams in week one, not week ten. And settle ownership of the code and the cloud accounts in writing before kickoff, which at Digital Heroes means the client owns the repository from the first commit. Start by asking what your unit's expected heat rate is right now at today's ambient. If the answer requires opening a spreadsheet somebody built years ago, you have found your first scope.