Solar Farm O&M Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does replacing the data acquisition system get scoped so often?

It is the most expensive mistake we watch solar operators make, and the logic behind it is understandable. You are running AlsoEnergy PowerTrack for the older assets, Huawei FusionSolar for two 2023 builds because the engineering contractor bought Huawei inverters and the warranty requires their portal, and an acquired asset still phones home somewhere nobody has the admin password for. Three portals, no fleet view. The obvious conclusion is to replace all of it with one system.

That conclusion means taking ownership of protocol drivers, device commissioning and an argument with an inverter manufacturer about warranty compliance, for zero commercial gain. None of those things is where you are losing money. The portals do device-level monitoring competently and they satisfy warranty obligations that are not optional.

What is missing sits above them. One normalized time series store, one fault taxonomy you own, one event queue ranked in dollars, one availability engine that speaks your contracts. The scope that works keeps the portals for what they are good at and builds the layer that no vendor will ever build.

The practical test at scoping time: if a proposal includes writing drivers for inverter communication, ask what commercial problem that solves that a data pull from the existing portal does not. If the answer is architectural elegance, remove it from scope and put the money into the availability engine.

What goes wrong when you migrate five years of SCADA history?

Historical data is what makes the new system credible on day one, and it is also its own workstream rather than a copy operation. For a fleet of twenty to thirty sites at one minute intervals, plan on two to four weeks of dedicated work.

The specific failures are these. Backfills arrive out of order, because a cellular modem drops for six hours and the remote terminal unit pushes the gap later, so a naive loader either rejects the rows or writes them in a sequence that breaks aggregates. There is almost always at least one register map change buried in the history, from a firmware update somebody applied during a maintenance window. Meter data and inverter data disagree, sometimes by a lot.

The fix is to backfill through the same ingest pipeline the live data uses, so historical and live rows share one schema and one fault taxonomy rather than living in a separate historical table that later has to be joined. Include a reconciliation pass against the revenue meter as part of the migration acceptance because the revenue meter is the only number your counterparties recognise. And design the retention policy and continuous aggregates on day one. Twenty six sites at a few thousand tags each on one minute intervals runs into tens of billions of rows a year, and retrofitting downsampling in month eight is considerably more expensive than specifying it in week one.

Why do OEM portal and protocol integrations break after launch?

Every data source in this stack is owned by someone else and changes on their schedule. An AlsoEnergy API pull, a FusionSolar API pull and a raw Modbus TCP poll over a cellular modem are three unrelated engineering problems, and each one is real weeks rather than a connector you configure.

After launch they break in ways that do not throw errors. An inverter manufacturer changes a register map in a firmware update rolled out during a service visit, and your poller keeps reading the same register addresses and recording plausible values that mean something different. Six weeks of data are silently corrupted before anyone questions a performance ratio that drifted slightly.

The fix is validation on shape and plausibility rather than on connectivity alone. Alarm when a tag's value distribution moves outside a band you set, not just when it stops arriving. Version the register map per device with the firmware level recorded, so a change is a known event rather than a mystery. Keep the raw payload alongside the normalized reading so a corrected mapping can reprocess the affected period rather than losing it.

What happens when the contract availability definition is not covered?

This is the gap that costs the most and gets deferred the most, usually because it looks like reporting. It is not reporting, it is the commercial core of the system.

The dispute is never about the raw data. It is about definitions. Is availability time-based per inverter or energy-based and weather-adjusted at the plant meter. Are curtailment hours excluded, and capped at how many. Does a grid outage upstream of the point of interconnection count against you. Does a forty percent inverter derate count as available. Is the measurement interval one minute or fifteen, because that alone can move the number by half a point. If you hold fourteen assets you probably hold nine different answers, and a monitoring portal computes availability its own way for all of them.

The fix is to treat each agreement as configuration. An availability profile per contract: numerator and denominator definition, measurement interval, exclusion rules bound to actual data sources such as the grid outage flag from the remote terminal unit and the curtailment setpoint from the site controller, the derate threshold, declared force majeure windows and the makeup energy formula. Then every excluded minute becomes an auditable row with evidence attached: the tag, the timestamp, the operator note, the switching order, the photograph. When an independent engineer challenges a quarter, you export a ledger of evidenced exclusion rows rather than defending a workbook. We have watched one of those exports end a six figure argument in a single call.

Should you build custom or configure what you already own?

If you are under roughly 50 MW on a single inverter manufacturer, with one contract structure and no availability guarantee that has teeth, do not build. AlsoEnergy PowerTrack plus a low cost maintenance system such as UpKeep or Fiix will do the job for less than one performance engineer costs per year, and building at that scale is vanity. Configure the alarm thresholds properly, set up the preventive maintenance schedules, and spend the difference on technicians.

The signals that it is time to build the layer above: you run three or more monitoring portals and nobody can produce one fleet view. You carry availability or performance ratio guarantees where a single definitional dispute is worth more than the entire build. You employ someone whose real job title is the availability spreadsheet. Every acquisition adds a portal. Or you sell operations and maintenance to third party owners and your pitch is cost per megawatt, in which case the software is part of the product rather than overhead.

How do hidden costs get into the quote?

A focused first release covering alarm normalization across your portals, a dollar-ranked event queue, work orders and an offline capable field app runs $60,000 to $130,000 across 12 to 16 weeks in our delivery experience. A full platform adding the contract availability engine, the serial-level asset and warranty register, dispatch optimization and counterparty reporting runs $150,000 to $400,000 phased over 6 to 12 months. Five things drive it past an estimate.

Data source count is the largest and the least appreciated, because each portal API and each raw protocol poll is its own effort and they do not collapse into one connector. Ingest volume is the second, since tens of billions of rows a year needs continuous aggregates and a retention policy designed rather than added later. Contract variety is the third: three templates is a week of configuration work and fourteen bespoke agreements is a quarter. Offline-first mobile is the fourth and roughly doubles the field application effort, and it is not optional when a technician is standing in a field with one bar. The fifth is NERC registration on any asset in the fleet, which changes hosting region, access control, audit logging and change management for the whole system.

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

Ranking by money rather than by timestamp. At 06:40 the data acquisition system reconnects after an overnight comms drop and fires hundreds of alarms in four minutes, because every inverter at every site logs a communication restored event and every site logs irradiance below threshold at dawn. Buried in that flood is one inverter that tripped on a DC ground fault at 02:10 and will stay dark until somebody happens to visit. Eleven days of a block down is a number small enough to ignore once and large enough to matter twelve times a year.

The builds that work normalize every manufacturer fault code into a taxonomy you own, then score every open event in dollars: expected energy from plane of array irradiance and cell temperature against your model and the block's performance ratio baseline, actual from the revenue meter or inverter output, delta priced at the contract rate. The queue sorts by dollars per day. The builds that fail reproduce the alarm inbox with better styling.

The second separator is the asset register: a list down to the serial number, with install date, warranty term, manufacturer contact and repair history, so a qualifying fault automatically attaches the recent fault log and drafts the claim inside the manufacturer's window. Without it, a power stack failure in year six against a ten year warranty becomes a five figure write-off because the serial number is in a photograph in a message thread from commissioning. Document extraction from commissioning reports and warranty documents is what makes building that register affordable rather than a six week typing exercise.

When you interview a developer, hand them the actual availability clause from one agreement before you hand them a budget. If the answer contains the phrase an availability percentage field, end the conversation. Ask how they downsample one minute data for reporting and what the retention policy looks like at year three. Then settle ownership and hosting in the contract rather than at kickoff: you should own the repository, the infrastructure accounts and the data outright, with no runtime dependency on the developer's platform. At Digital Heroes the client owns all of it from the first commit.