Wind Farm O&M Software: Stop Losing Availability Claims You Should Win

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

Your asset manager opens six browser tabs every morning. Vestas Online Business for the V110 fleet, GE Renewable Energy's Digital Wind Farm portal for the 2.x machines, Siemens Gamesa's WebWPS for the site you acquired last year, plus a Greenbyte or Power Factors dashboard that mostly works, plus IBM Maximo where work orders actually live, plus a shared Excel file called LostProduction_Master_v14_FINAL.xlsx that one person understands. None of these systems agree on what happened to turbine A07 last Tuesday.

Follow one fault and you can watch the money leave. Turbine A07 throws a pitch system fault at 02:14. SCADA logs a status code and a downtime timer starts. A technician gets to it at 09:40, resets it, and it runs for four hours before faulting again. The real fix takes a crane and a pitch bearing, which arrives eleven days later. Now your team has to answer: how many megawatt-hours did you lose, was it a warranty event or wear and tear, did it breach the 97 percent availability guarantee in your service agreement, and does the OEM owe you liquidated damages. The answer to that question lives in three systems that were never designed to talk to each other, so somebody reconstructs it by hand, in a spreadsheet, two weeks late, and the number they produce is defensible only until the OEM's asset manager produces a different one.

Across the fleets we have worked with, that reconstruction work eats 15 to 25 hours a week of a senior person's time, and the claims that never get filed because nobody had time to build the evidence pack are worth far more than the labor. At $40 per megawatt-hour, an outage of that length on a 2.5 MW machine in good wind is roughly $23,000 you simply did not ask for. Multiply by the number of events per year across 200 turbines and you understand why the CFO keeps asking why availability reporting is a manual process.

Problem: your production loss numbers are a story, not a ledger

Every service agreement, every warranty claim, and every lender report depends on one number: how much energy did we lose and why. The industry has a standard for this, IEC 61400-26 availability categories, and almost nobody implements it cleanly because doing so requires stitching SCADA ten minute data, fault code logs, work order timestamps, and a power curve reference together per turbine per interval.

What actually happens: the OEM portal reports availability using the OEM's own exclusion rules, which conveniently exclude grid curtailment, low wind, and anything the OEM calls scheduled. Your Excel model reports a different number using your rules. When you dispute a quarterly availability calculation, you are arguing methodology, not facts, and the party with the better data model wins. Usually not you.

Why Maximo and the OEM portals cannot fix this: Maximo has no concept of a power curve or a lost megawatt-hour. It knows an asset was down from timestamp X to timestamp Y. It cannot tell you that during those 264 hours the wind was blowing at 9.2 meters per second average and the neighboring turbines produced 620 MWh, so A07's expected production was roughly 590 MWh after wake correction. Greenbyte and Power Factors do compute lost production, but they compute it with their allocation logic on their category tree, and when you need to defend a specific claim you cannot see or change the arithmetic.

What a custom build does: a lost production engine that runs per turbine per ten minute interval. It takes SCADA power, wind speed, nacelle position, and status code, joins it to your contracted power curve and a neighboring-turbine reference method you choose, and writes an immutable row: interval, expected MWh, actual MWh, delta, IEC 61400-26 category, responsible party, work order ID, fault code. Every number on every report traces back to those rows. When the OEM disputes a quarter, you export the ledger and the argument ends in twenty minutes instead of three weeks. That single table is usually the highest-return thing we build in this category.

Problem: work orders and SCADA faults are separate universes

A technician closes a work order in Maximo with the comment "reset pitch fault, turbine running." A month later the same fault repeats. Nobody connects them because the fault code from SCADA never entered Maximo, and the work order text is free-form. Your reliability engineer wants to know how many pitch bearing failures you had on the V110 fleet in the last 18 months and the honest answer is: we would have to read 400 work order comments.

The workaround everyone runs is a technician typing a fault code into a Maximo description field, which fails within a month because it is unpaid data entry with no visible benefit to the person doing it. So you get "pitch fault" and "PITCH FAULT" and "pitch error 1046" and blanks.

Why the off-the-shelf CMMS cannot fix this: Maximo, Fiix, and UpKeep are asset-and-task systems. They can hold a custom field, but they cannot listen to an OPC UA stream or an OEM API and auto-create a work order when fault code 1046 persists for more than 30 minutes on the same turbine. They have no turbine component hierarchy out of the box, so the gearbox, the pitch system, the yaw drive, and the converter are not distinct maintainable objects with their own failure history.

What a custom build does: fault-to-work-order automation. A rules engine watches the SCADA feed per turbine. When a status code crosses a persistence threshold you define, it opens a work order pre-populated with the turbine, component, fault code, downtime start, and current lost MWh accruing. The technician's mobile app shows the fault history for that exact component on that exact turbine before they climb. When they close the job, the app forces a structured failure mode selection from a taxonomy you built, not free text, and the closure automatically stops the downtime clock and stamps the production loss ledger. Now "how many pitch bearing failures on the V110 fleet" is a query, not a research project.

One AI application here is narrow and verifiable: run a model over 18 months of your closed work orders and technician comments to auto-classify historical failure modes into your taxonomy. We have done this on backlogs of 8,000 to 30,000 work orders. It gets you a clean reliability history on day one instead of asking a human to read them, and a human spot-checks 200 rows and accepts or corrects the mapping before anyone relies on it.

Problem: warranty and availability claims expire before you file them

Your full service agreement has a claim window. Often 30 or 60 days from the event. The evidence you need is the fault log, the downtime duration, the lost production calculation, the work order with parts and labor, and proof the failure was not caused by your operation. Assembling that pack takes hours, so it only happens for the obvious big-ticket events. The medium-sized ones, the $8,000 to $30,000 claims, quietly expire.

Why the OEM portal will never fix this: it is the counterparty's system. It is not going to build you a tool that automates claiming money from the counterparty. That is an alignment fact rather than a criticism, and it is the single strongest structural argument for owning your own data layer in this category.

What a custom build does: a claim pipeline. Any downtime event whose category and duration match your contract's claim criteria auto-generates a draft claim: the SCADA fault trace, the lost production ledger rows, the work order with parts and labor cost, the availability impact against the guarantee, and the contract clause reference. Your asset manager reviews and submits. A countdown against the claim window sits on the dashboard, so nothing expires silently. On the AI side, contract clause extraction is genuinely useful: feed it your service agreements and it pulls out the availability guarantee percentage, the exclusion list, the claim window, and the liquidated damages formula into structured fields, so the rules engine is configured from the contract rather than from somebody's memory of the contract. A lawyer or asset manager verifies the extraction once per agreement.

Problem: technicians work offline, at height, in gloves

The turbine is 90 meters up in a field with no LTE. The technician needs the fault history, the torque spec, the wiring diagram, the lockout-tagout checklist, and a way to record what they found. What they actually carry is a printed work order and a phone with a dead signal, and the data entry happens at 5pm in the truck from memory.

Why generic field service tools cannot fix this: ServiceTitan, Jobber, and the trades-oriented field service platforms assume a van, a customer address, and an invoice at the end. There is no customer at the end of a turbine job, there is a compliance record. Salesforce Field Service can be bent into shape, but you will spend more on the configuration and licenses than a purpose-built app costs, and it still will not handle a full O&M manual set offline or an LOTO sign-off chain with two signatures.

What a custom build does: an offline-first mobile app with local storage and conflict-safe sync. Everything a tech needs for today's assigned turbines downloads at the shop over wifi: component history, torque values, the specific manual sections, the last three work orders on that turbine. Structured capture at the point of work, including photos tagged to the component, torque readings against spec with out-of-tolerance flags, and an LOTO checklist that will not let the job close without the isolation record. It syncs when signal returns. The compliance record builds itself as a side effect of the work, which is the only way it ever stays accurate.

Problem: you cannot see a failure coming, so every crane is an emergency

A main bearing replacement with a mobile crane on emergency mobilization is a very different number from the same job planned into a scheduled campaign with a crane already on site for two other turbines. The difference is often six figures per event, and it is entirely a scheduling problem created by not knowing what was about to fail.

Your CMS vendor sends a monthly PDF flagging elevated vibration on a handful of drivetrains. It arrives as a document, gets read, and gets forgotten, because the alarm lives in a PDF and the work planning lives in Maximo and nothing connects them.

What a custom build does: pull condition monitoring alarms, oil analysis results, and SCADA-derived indicators like gearbox oil temperature rise against power output into the same asset record as the work orders. A component with an open CMS alarm shows that alarm on its record, and it enters the campaign planner. The planner is the real feature: it groups predicted major-component work by site and by crane requirement, so your team can see that three drivetrains on the north site are all trending and one mobilization covers all three. On forecasting specifically, be honest about scope. A model that predicts a specific bearing failure date is a research project. A model that ranks your fleet by probability of a major component event in the next 90 days, trained on your own CMS and SCADA history, is achievable and is what actually changes the crane schedule. We build the ranking, not the crystal ball.

What this costs and how long it takes

These are Digital Heroes delivery bands from 2,000-plus projects, not industry averages. A focused first release, meaning the turbine and component asset model, SCADA ingestion for one OEM, the production loss ledger, fault-to-work-order automation, and availability reporting, typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding multi-OEM ingestion, the offline technician app, warranty claim automation, condition monitoring integration, and campaign planning runs $150,000 to $400,000 phased over 6 to 12 months.

What drives price up in this category specifically. First, the number of distinct OEM data sources. Each additional OEM is a new protocol, a new status code taxonomy, and a new normalization mapping, and it is genuinely 3 to 6 weeks of work each, not a config toggle. Second, historical data migration: ten years of ten minute SCADA data across 200 turbines is billions of rows, and getting it queryable is an engineering problem with a real cost. Third, contractual complexity: if you have four different service agreements with four availability formulas and four exclusion lists, the rules engine has to model all four. Fourth, if the platform reports to lenders or to an ISO, the audit trail and data lineage requirements add real work. What does not drive price much: the number of turbines. 80 or 800, the software is the same.

Build versus buy, and where the line actually sits

Buy is genuinely right in three situations. If you run under about 60 turbines on a single OEM under a full service agreement where the OEM carries the availability risk, you are paying for someone else's problem, and the OEM portal plus a decent CMMS is the correct answer. If you are a developer who flips projects at COD and never holds long-term operations, buy. If you have no internal person who owns data, a custom platform will rot within 18 months, and Power Factors or Greenbyte with their support team is safer than an unmaintained bespoke system.

Here are the signals it is time to build, and they are concrete. You have more than one OEM in the fleet. You have moved off full service agreements to self-perform or ISP, so availability risk is now yours. Someone on your team spends more than a day a week reconstructing production loss in Excel. You have lost an availability dispute in the last two years because you could not produce the underlying data. Or your platform vendor's roadmap does not include the one report your lender demands, and you have been waiting three quarters for it.

The position I will take: the production loss ledger should be yours, always, even if everything else is bought. It is the number your contracts, your claims, your lender reports, and your acquisition diligence all run on, and renting it from a vendor whose allocation logic you cannot inspect is the mistake I see most often. Build that, integrate the rest, and you have a defensible asset for the price of the smaller band.

How to choose a developer for wind farm O&M software

Ask them to whiteboard the asset model before you talk price. The right answer separates the site, the turbine, and the maintainable component, with the component carrying its own serial number and failure history that survives being swapped between turbines. If they draw a flat asset table with a "location" column, they have built facilities software, not wind software, and the serial number problem will bite you the first time a gearbox is refurbished and reinstalled elsewhere.

Ask what they have actually integrated. The credible answers name protocols and pain: OPC UA, IEC 61400-25, Modbus TCP for the older machines, SCADA historians like OSIsoft PI or Canary, and the reality that OEM APIs are rate-limited and status code taxonomies do not map cleanly across manufacturers. If they say "we will use their API" with no follow-up questions, they have not done this before.

Ask how they handle time series volume. Ten minute data across a few hundred turbines for a decade is not a Postgres table you query naively. You want to hear about a time series store, or at minimum partitioning, continuous aggregates, and a considered retention policy. Vague answers here mean a system that is fast in the demo and unusable at year two.

Ask about the compliance and audit surface, and get it in the contract. NERC CIP obligations if any of your assets are in scope, cybersecurity boundaries between the SCADA network and the business network, immutability of the production loss ledger, and full data lineage from a report figure back to the raw SCADA interval. Also settle code ownership and source repository access in writing before kickoff, because in this category the data model is the asset, and a vendor who owns it owns your leverage in every future dispute.