Power Plant Performance Monitoring Software Problems: The 7 That Cost Fuel, and How to Avoid Them

Why does a fleet wide first release go wrong so often?

Because fleet comparison is the outcome everyone wants, so it becomes the scope, and it is the one thing that cannot be delivered first.

A fleet of combined cycle, simple cycle and coal units needs three modelling approaches rather than one. The correction curve set differs, the section decomposition differs, and the operating mode segmentation differs, because base load, part load and duct fired operation are statistically different machines and mixing them produces noise rather than insight. Quote a fleet as a unit count and you have priced a replication exercise that is actually three projects.

The second reason is that fleet comparison depends entirely on tag mapping being finished across every unit, and that work needs plant engineers who are also doing their day jobs. Sequence it wrong and the project stalls waiting on people who never agreed to be on it.

The fix is to start with the unit that runs the most hours, encode only the corrections that materially move the number for your climate and dispatch pattern, and prove the loop end to end. That is the $70,000 to $140,000, twelve to sixteen week first release in our delivery experience. Fleet rollout afterwards is largely replication and moves considerably faster, and by then you have a mapping method that survived contact with one real unit.

What goes wrong when the historian tag estate is mapped?

This is a data problem wearing an engineering costume, and it is where most fleet performance initiatives quietly died.

Tags at a plant built in stages over twenty years are archaeology. The same physical measurement is named differently on different units. Some descriptors carry engineering units and some do not. Sign conventions differ. There are duplicate tags left live after a control system upgrade re-pointed a signal, and the abandoned one is still logging and slowly diverging from reality, which means a calculation can pick the wrong one and be plausibly wrong for years.

The failure mode is writing calculations directly against tag names. It works until an outage, when somebody renames a tag as part of a control system change, and the calculation either fails visibly or, much worse, silently starts reading something else.

What holds is a semantic layer. 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. A broken mapping then fails loudly instead of producing believable wrong numbers. Budget a few weeks of a plant engineer's time per site for the mapping workshop, and treat that as the highest value few weeks in the project rather than as preparation.

Why do historian and control network read paths break after launch?

They break in three ways, and none of them are code.

The first is access design treated as a configuration detail. The read path from a historian sitting inside or adjacent to a control network has to be agreed with your control system and cyber security teams before any calculation runs, usually reading from a mirrored or replicated historian rather than the process network, with no write path in that direction. A developer who does not expect that conversation in week one has not worked in generation, and the discovery arrives as a schedule slip rather than a technical problem.

The second is change windows. A control system upgrade or a firmware change during an outage alters tag names, scan rates or compression settings, and compression is the subtle one: a historian configured to compress aggressively on a signal will hand you a shape that is fine for trending and wrong for a performance calculation. Record the expected scan rate and compression per mapped measurement and alert when the delivered data shape changes.

The third is credential and certificate expiry, which sounds trivial and takes a monitoring system offline for a week because the person who owned the account moved teams. Put the read path under the same alerting you would apply to a measurement, so a stopped feed is an incident with an owner rather than a dashboard that quietly stops updating.

What happens when instrument validation is not covered?

You build a very expensive machine for generating confident wrong answers.

Attribution decomposes a deviation across compressor condition, turbine section efficiency, heat recovery steam generator effectiveness, steam turbine section efficiency, condenser performance and cycle isolation. Every one of those indicators is computed from measurements, and a measurement that has drifted since its last calibration produces an indicator that moves for reasons that have nothing to do with the machine. Engineers already carry a private list of tags they distrust. A build that does not write that list down inherits none of it and loses it entirely when the engineer retires.

What validation looks like in practice: redundant measurements cross checked against each other, energy and mass balances closed wherever the instrumentation allows, and residuals tracked so a growing residual flags a measurement as suspect before it is used to justify anything. A suspect measurement should be excluded from attribution and named, not quietly averaged into it.

The related gap is instrumentation that simply does not exist. Some attribution needs measurements a given unit was never fitted with, and the honest answer is an instrument project rather than a software one. A developer who promises full section attribution without asking what you actually measure is selling you a model that will infer its way around missing data and present the inference as a finding.

Should you build custom or configure what you already own?

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. Spend the money elsewhere.

Stay with the vendor package if you are a single unit site on one control system vendor whose performance calculations were configured properly at commissioning and have been maintained since. Emerson Ovation and its peers carry credible performance calculation packages. That situation is rarer than vendors suggest, because maintenance of those calculations usually stopped when the commissioning engineer left, but it does happen and it is worth checking before you fund anything.

Keep AVEVA PI System either way. It is an excellent historian and visualisation layer and a custom performance layer sits on top of it rather than replacing it. Similarly, GE Vernova APM and Hitachi Energy Lumada APM are built around asset health and failure mode detection, which is genuinely useful reliability work and a different discipline from corrected thermal performance. Owning both is normal.

Build when two or more apply: more than two units, especially across different control system vendors, with no common basis for comparison; an expected performance model that exists only in a spreadsheet built by an engineer who has left or is about to; a maintenance decision in the last two years that addressed the wrong cause; fuel as a material cost line nobody can attribute in dollars; or an anomaly detection product whose alerts engineers routinely dismiss, which means it has already lost the room.

How do hidden costs get into the quote?

Unit diversity rather than unit count is the first, and quotes almost always price the count. Ask for a per plant type price, because three plant types is three modelling approaches.

Missing documentation is the second. A unit whose acceptance test report cannot be found needs its expected performance model rebuilt from operating data, which is workable and slower, and the absolute numbers then carry a caveat your engineering team has to understand and accept. Check which units have their reports before anyone quotes.

Historian access arrangements are the third, and they cost calendar time rather than engineering hours. Plan the project around a read path design that involves your control system and cyber security teams, and treat a quote that assumes immediate access as optimistic.

Instrumentation gaps are the fourth and the most awkward, because the answer is sometimes a transmitter rather than a feature. The fifth is economic valuation, which sounds like a report and needs current fuel price and dispatch pattern feeding it continuously to be worth anything. And the sixth is ongoing model maintenance after a major overhaul, since a unit's expected performance legitimately changes when hardware changes and somebody has to own re-baselining it.

What separates a build that works from one that fails here?

The headline metric is deviation from expected, not raw heat rate. That single decision converts a number nobody can interpret into one that means something the moment it moves, and it is the difference between a performance system and a trend display. Ask what the front page shows.

The expected performance model is versioned with the source document attached and every coefficient traceable. When somebody asks in three years where a correction came from, the answer is a scan of the acceptance test page rather than a memory.

Attribution is ranked by money rather than by percentage, valued at current fuel price and current dispatch pattern, with suspect measurements named and excluded. That turns the output into a maintenance planning input: this much of the deviation attributable to condenser cleanliness worth this much per running hour, against a compressor wash worth this much and the cost of the window it needs. A percentage ranking cannot start that conversation.

Then two questions that separate people who have done this from people who have done enterprise analytics. Ask what they would do with a plant that has no acceptance test report, and listen for a reference baseline established from a clean period of operating data, described honestly as a reference rather than a guarantee. Ask how the read path will be designed and who has to approve it. And settle ownership of the code, the models and the cloud accounts in writing before kickoff. At Digital Heroes the client owns the repository from the first commit, and the correction models belong with the units they describe.