When a Solar Plant Changes, Its KPIs Move

Synthetic example. The numbers are made up, the mechanics are not.

On 1 June, someone corrects the DC capacity of a plant in the portal from 9.6 to 10.0 MWp. The performance ratio was 84.0 % in May. In June it is 80.6 %. Nobody touched the plant, and the sun was no different.

Performance ratio divides the energy by the sunlight and by the size of the plant. Make the plant 4 % larger on paper, and the ratio drops by 4 %. Whether that is right depends on a question nobody asked when the field was changed: did the plant change, or did the record?

A change or a correction?

The same edit can mean two opposite things:

• A change. The plant really grew: 0.4 MWp of modules were added on 1 June. Then 9.6 is right until 31 May and 10.0 from 1 June. The new modules produce more energy, so the performance ratio stays where it was.
• A correction. The plant always had 10.0 MWp, and 9.6 was a typing error at commissioning. Then 10.0 is right for the whole history, and every past performance ratio was about 4 % too high. The reports already sent used 9.6, so record when the correction was made, or those reports can't be explained later. See Two Dates for Every Number.

A field that holds only the current value can't tell the two apart. Either way, it now says 10.0. Store a change as an overwrite, and every past month is computed with a plant that didn't exist yet. Store a correction as "from now on", and the chart shows a drop that never happened: the step from 84.0 to 80.6 %.

What moves which number

Why no alarm goes off

Alarms watch the plant, not its description. They compare what the plant does with what it should do. When the description changes, the yardstick moves with it. Nothing in the plant broke, so nothing fires. The KPI moves by 4 %, and the only trace is a field that now says 10.0 instead of 9.6.

Where the record falls behind

Plant data is rarely lost in one go. It falls behind at the handovers:

• Commissioning. The documents describe the plant as designed. Changes on site make it into the as-built version, or don't.
• The first repair. A replacement inverter goes in on a Tuesday and the ticket is closed. The master data is updated weeks later, or never.
• A new O&M contractor. The new team inherits a portal, a folder and whatever the old team wrote down.
• A sale. The data room holds the plant as it is. The history of its changes often isn't part of it. See Taking Over a Solar Plant.

Doing it yourself

1. Keep plant data as rows with a valid-from date, not as fields you overwrite. A swap is a new row. The old row stays for the time before.
2. Mark every edit as a change or a correction. For a correction, note when it was made and why.
3. Use one definition of capacity for every plant, for example the DC nameplate from the as-built module list. When the plant changes, the value changes from that day on. The definition stays.
4. Record each change when it happens: what changed, on which device, valid from when, entered when, by whom, and from which document.
5. Compute every month with the plant data valid in that month.

A spreadsheet with a valid-from column works for a few plants. The hard part is getting every change reported, by every contractor, on time.

Or let us do it

Our platform keeps master data with validity dates: a meter swap is a new row, not an edit, and every number carries the master-data state it was computed with. Your plant data stays in your own project, where your team can edit it and see who changed what. The KPI audit starts with one plant and one month, and asks for anything that changed in it.

See also

• Two Dates for Every Number
• A Solar KPI Audit You Can Repeat Yourself