Solar Farm O&M Software: What Breaks at 300 MW and What to Build Instead

Why solar farm O&M software makes or breaks a fleet operator

Picture the stack at a typical 300 MWac independent operator: 26 sites across ERCOT, PJM and MISO. The 2018 and 2019 assets report into AlsoEnergy PowerTrack. Two 2023 builds sit in Huawei FusionSolar because the EPC bought Huawei inverters and the OEM warranty requires their portal. One acquired asset still phones home to a Sungrow portal nobody has the admin password for. Work orders live in UpKeep. Availability lives in a workbook a performance engineer named Dana maintains, and the quarterly lender report is a PowerPoint with screenshots pasted into it.

Here is what that costs on a specific Sunday. At 06:40 the DAS reconnects after the overnight comms drop and PowerTrack fires 312 alarms in four minutes, because every inverter at every site logs "communication restored" and every site logs "irradiance below threshold" at dawn. Buried in that flood is inverter 7 of 12 at a 22 MW site in Ward County, tripped on a DC ground fault at 02:10. Nobody sees it until Thursday, when a tech happens to be onsite for vegetation and notices the block is dark. Eleven days at roughly 15 MWh a day is about 165 MWh, or $7,400 at a $45 PPA. That number alone does not scare anyone. Then you find eleven more of them across the year, and then the asset manager sends a Q3 report claiming 96.8% energy availability against a 98% guarantee, and the liquidated damages line is $210,000, and Dana's workbook says 98.4% and cannot prove it.

That gap between "we know the plant is fine" and "we can prove it in the language of the contract" is where solar O&M money is actually made or lost. Nothing in the OEM portals was built to close it.

Problem 1: The alarm flood buries the fault that costs real money

Your morning triage is a person scrolling an inbox. Every device state change is an alarm with equal weight. An SMA fault 3501 and a Sungrow fault 043 and a Power Electronics stack alarm all mean roughly "check the DC side," but they are three different strings in three different portals and no human holds the mapping in their head at 7am.

PowerTrack and FusionSolar cannot fix this because they alarm on device state, not on money. They do not know your PPA rate. They do not know that a tracker controller fault at Site 11 costs $180 a day and an inverter block at Site 4 costs $700 a day. And they are per-portal, so there is no single ranked queue.

What a build does: poll everything into one time series store (Timescale hypertables, or a tag map onto an existing PI historian if you already run one), normalize every OEM fault code into a fault taxonomy you own, and score every open event in dollars. Expected energy comes from POA irradiance and cell temperature against your PVsyst P50 model and the block's PR baseline; actual comes from the revenue meter or the inverter AC output; the delta gets priced at the contract rate. The queue sorts by dollars per day, not by timestamp. The AI piece that matters: an event classifier trained on your own three years of closed tickets that predicts self-clear, remote reset, or truck required. It works because it learns your fleet's resolution history, not a generic model. In our builds this is consistently the highest-return model in the system, and it is the one that stops you sending a technician for a fault that was going to clear itself.

Problem 2: You cannot prove availability the day the LD invoice lands

The dispute is never about the data. It is about definitions. Is availability time-based per inverter or energy-based weather-adjusted at the plant meter? Are ISO curtailment hours excluded, and capped at how many? Does a grid outage upstream of the POI count against you? Does a 40% inverter derate count as available? Is the measurement interval 1-minute or 15-minute, because that alone can move the number by half a point.

PowerTrack computes availability its way. Your O&M agreement defines it its way. If you have 14 assets you probably have nine different definitions, and no off-the-shelf portal will let you encode nine of them.

What a build does: treat the contract as configuration. Each agreement gets an availability profile: numerator and denominator definition, measurement interval, exclusion rules bound to actual data sources (the grid outage flag from the RTU, the curtailment setpoint from the site controller or the ISO feed, declared force majeure windows), the derate threshold, and the makeup energy formula. Every excluded minute becomes an auditable row with evidence attached: the SCADA tag, the timestamp, the operator note, the switching order, the photo. When the independent engineer challenges Q3, you export a ledger with 4,100 evidenced exclusion rows, not a workbook. We have watched one of those exports end a six figure argument in a single call.

Problem 3: Crew dispatch across 26 sites is a whiteboard and a memory

Three crews, 700 miles of driving, and a Monday plan built from what the O&M manager remembers. Annual PM windows, IR thermography season, tracker greasing intervals, vegetation cycles, module washing after the soiling rate crosses your threshold, plus the reactive queue. Twice a quarter two techs drive past the same site on the same day.

UpKeep, Fiix and Salesforce Field Service can schedule, and they schedule blind. They do not know the 72-hour POA irradiance forecast, so they will happily book an outage at 13:00 in July. They do not know that this site is medium voltage and that tech is not qualified to switch it. They do not know that a preventive maintenance visit is already due at the site the reactive ticket is at.

What a build does: a dispatch engine that prices every job two ways, cost to send now versus lost energy if deferred, and slots outage work into forecast low-irradiance windows. It bundles reactive tickets with PM due at the same site inside the same window. It enforces qualification: NFPA 70E training currency, medium voltage switching authorization, site-specific orientation, all checked before a job can be assigned. It generates the switching order and the energized electrical work permit populated with real equipment IDs, and it caches everything offline, because the tech is standing in a field in Pecos County with one bar. AI here is forecasting and proposal: the system drafts next week's plan, the manager approves or drags things around, and the model learns from the overrides.

Problem 4: Warranty and spares money walks out the gate

Year six, a Power Electronics power stack fails. The extended warranty is 10 years, so this should be free. The serial number is on a photo in a WhatsApp thread from commissioning. The OEM requires the fault log pulled within a defined window and it was not. You eat $28,000 and a four-week lead time.

No monitoring portal holds your asset register at serial level with warranty terms, because that is your commercial data, not the OEM's. So it lives in a spreadsheet that was last accurate at COD.

What a build does: an asset register down to the serial, module strings by pallet, combiners, inverters, power stacks, tracker motors and controllers, each with install date, warranty term, OEM contact, and RMA history. When a qualifying fault fires, the system auto-attaches the last 30 days of fault log, the IV curve trace if one exists, and the thermography image, then drafts the RMA packet inside the OEM's window. Document extraction is what makes the register affordable: commissioning reports, as-builts, the IE report and the OEM warranty PDFs get parsed into structured records, so the register gets built from documents you already have instead of an intern typing serials for six weeks. On acquisitions this is the difference between a two-day onboarding and a two-month one.

Problem 5: The quarterly report eats a week of your best analyst

The asset manager wants one format, the lender wants another, the tax equity partner wants a third. Multiply by 26 sites and four quarters. Dana spends the first week of every quarter screenshotting charts, and the two FusionSolar sites get done by hand because the export schema is different.

What a build does: a report engine sitting on the same normalized data. Per-counterparty templates: weather-adjusted PR against the PVsyst P50 using actual POA and cell temp, the availability ledger with exclusions, the event list with root cause codes, open work orders by age. Generated on schedule, reviewed by a human, exported to PDF and XLSX. The AI writes the first draft of the narrative ("PR of 0.79 against 0.82 expected, driven by soiling at Site 4 and the 17-day transformer outage at Site 11, grid-excluded per Section 8.3") and the analyst edits it. A week becomes a morning.

What this costs and how long it takes

Framed only as Digital Heroes delivery experience across 2,000+ projects. A focused first release, meaning alarm normalization across your portals, the dollar-ranked event queue, work orders, and an offline-capable field app, typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. 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.

What pushes price up in this category specifically: the number of distinct data sources, because the AlsoEnergy API, the FusionSolar API, and a raw Modbus TCP poll over a cellular modem are three unrelated engineering problems and each one is real weeks. Ingest volume, because 26 sites at a few thousand tags each on 1-minute intervals runs into tens of billions of rows a year and needs continuous aggregates and a retention policy designed on day one, not bolted on in month eight. Contract variety, because three templates is a week and fourteen bespoke agreements is a quarter. Offline-first mobile, which roughly doubles the field app effort and is not optional. And NERC registration on any asset, which changes hosting, access control, and audit logging for the whole system.

Build vs buy: take the portals seriously, then build above them

Buy is genuinely right if you are under about 50 MW, on a single inverter OEM, with one contract structure and no availability guarantee that has teeth. PowerTrack plus UpKeep costs less per year than one performance engineer and it will do the job. Building in that situation is vanity.

The signals that it is time to build: you are running three or more monitoring portals and nobody can produce one fleet view. You carry availability or PR guarantees where a single definitional dispute is worth more than the entire build. You employ someone whose actual job title should be "the availability spreadsheet." You are acquiring assets and every acquisition adds a portal. Or you sell O&M to third-party owners and your pitch is cost per MW, in which case the software is the product.

The position worth stating plainly: do not rebuild the DAS. The most expensive mistake we have watched solar operators make is deciding to replace AlsoEnergy or FusionSolar outright, which means owning protocol drivers, device commissioning, and an OEM warranty compliance fight, for zero commercial gain. Keep the portals for device-level monitoring and warranty obligations. Build the layer above them: normalization, contract logic, dispatch, warranty, reporting. That layer is where every dollar you are losing actually lives.

How to choose a developer for solar O&M software

Hand them your availability clause before you hand them a budget. Give a shortlisted firm the actual availability section of one O&M agreement and ask how they would represent it in the data model. If the answer contains the phrase "an availability percentage field," end the conversation. The right answer talks about exclusion rules as first-class evidenced records and contracts as configuration.

Make them show time series work at your volume. Tens of billions of rows a year is not a Postgres table with an index on timestamp. Ask what they use for continuous aggregates, how they downsample 1-minute to 15-minute for reporting, and what their retention policy looks like at year three. Ask what happens when a cell modem drops for six hours and the RTU backfills out of order, because it will.

Interrogate the protocol layer. Modbus TCP register maps, DNP3, OPC-UA, SunSpec, and vendor API rate limits are the actual work. Ask which of those they have shipped against, and ask specifically about how they handle an OEM changing a register map in a firmware update, which happens and which will silently corrupt six weeks of data if nobody planned for it.

Settle ownership and hosting in the contract, not the kickoff. You should own the repository, the infrastructure accounts, and the data outright, with no runtime dependency on the developer's platform. If any asset in the fleet is NERC registered, hosting region, access control and audit logging are contract terms, not implementation details, and a firm that treats them as details will find out the hard way during your first audit.