Renewable energy asset management

The two are usually named in one breath and they are not the same job. Operations and maintenance, written O&M, is the work of keeping the equipment running: watching the plant live, responding to faults, dispatching a technician, ordering the part, and closing out the work. Asset management is the owner's job: knowing what the portfolio delivered against what it should have, deciding where attention goes next, and being able to defend both answers to whoever is asking.

The boundary is easiest to see in the tools each job lives in. O&M runs out of the SCADA system at the plant and the manufacturer's own portal, both built for supervising one site's equipment in real time. Asset management runs across sites, across manufacturers, and across years, which is a different question asked of the same readings. A SCADA screen is very good at telling you the state of a turbine right now. It was never meant to tell you whether that turbine has been underperforming its siblings since the spring, or whether the availability figure in this quarter's report was computed the same way as last quarter's.

This page is about the second job, and so is Fleetera. The product reads from the control systems and meters you already run, over the protocols they already speak, and models what it reads, so the equipment that keeps the plant safe is not asked to change. It does not dispatch a technician, schedule the work, or hold the spares, which is what an O&M team and its maintenance system are for. The two jobs need each other: an owner's number is only as good as the work record behind it, and a maintenance team's priorities are only as good as the comparison that produced them.

A single-technology operator gets to build one mental model and reuse it. Every asset has the same failure modes, the same seasonality, the same definition of a good day, and the same vocabulary in every report. Adding a second technology does not add work in proportion. It adds a translation layer to everything that already existed.

The translation is needed in four places at once, and each of them is somewhere a mistake is easy to make and hard to see afterwards.

• Availability, which is defined against a different reference condition for each class
• Weather dependence, which is the dominant driver for two classes and nearly irrelevant to the third
• State, because storage carries a state of charge that generation has no equivalent of
• Aggregation, because ratios computed on different denominators cannot be averaged into a portfolio figure

None of this is exotic. Every operator running a mixed fleet already knows it. What tends to be missing is a data layer that knows it too, so the knowledge lives in the heads of a few people and in spreadsheets that reconcile the vendor portals by hand.

Availability sounds like a universal metric and behaves like three different ones. In every case it is asking whether the asset was ready to do its job, but what the job is, and what counts as a fair opportunity to do it, changes with the technology.

Wind

A turbine is available when it is ready to produce should the wind arrive. Producing little in light wind is correct behavior, not downtime, so the count is machine hours rather than energy, and a stopped machine on a calm day still counts against you.

Solar

An inverter is available when it is online during the hours that carried light. Hours are not interchangeable: the same outage costs nothing overnight and costs the whole afternoon at midday, so unweighted uptime flatters a plant that fails at the wrong time.

Storage

A battery is available when it can both absorb and deliver at rated power. That is two capabilities, not one, and state of charge constrains each of them independently: a full unit cannot take more in, an empty one has nothing to give out.

The consequence for tooling is concrete. An availability figure is only meaningful next to the asset type it was defined for, which means the definition has to live on the asset type rather than on a dashboard or in a report template. Define it once for a turbine model and it measures every turbine of that model you own, including the ones you buy next year. Define it in a spreadsheet and it measures whatever was pasted into that spreadsheet.

For wind and solar, the resource is the independent variable and output is the dependent one. A production number on its own carries almost no information about whether the plant is healthy, because a bad day and a calm day look identical in the output column. The number only becomes a performance statement when it sits next to what the conditions allowed.

This is why reference instrumentation matters as much as the machines. Hub-height wind speed and direction from a met mast or a nacelle sensor turn turbine output into a performance picture. Irradiance and module temperature do the same for an array. Those sensors are usually cheaper than anything else on site and are the first thing to be treated as optional, which is a decision that quietly removes the meaning from every performance number downstream.

Wind deserves one extra note, because it changes how much sensor quality matters. Power in the wind rises with the cube of wind speed, so a small error in the measured resource becomes a much larger error in the expected output you compare against. An anemometer drifting a few percent does not produce a slightly wrong performance number, it produces a confidently wrong one.

Storage sits outside all of this. Weather is not its independent variable at all: a battery's behavior is decided by how it is being operated and by the schedule it is running to. So on a mixed fleet, two of your three asset classes need reference conditions carried alongside their output to be interpretable, and the third needs its operating context instead. A monitoring layer that only knows how to do the first will make storage look either perfect or broken depending on the day.

Wind and solar assets are, from a data point of view, one-directional. They produce or they do not. Battery energy storage, usually written BESS, is the asset class that breaks that assumption, and most of what makes storage monitoring different follows from the same root: it has a state, and the state constrains what it can do next.

• State of charge, which no generating asset has an equivalent of, and which bounds both directions independently
• Two power directions, so a fault can affect the ability to charge, the ability to discharge, or both
• Cycling, where the pattern of use is itself a driver of how quickly the asset ages
• Round-trip efficiency, a ratio over a completed cycle rather than a value you can read at an instant
• Auxiliary systems, because thermal management and fire safety draw power and quietly decide the real efficiency
• Cell-level granularity, where one module out of family across a rack is the early warning

That last point is where storage stresses a data layer hardest. A wind farm has as many primary assets as it has turbines. A storage site has racks, and modules within racks, and cells within modules, and the interesting signal is often a single outlier among many near-identical siblings. The model has to be able to hold sites, assets, and sub-assets in a real hierarchy, or the outlier has nowhere to live except in an average that hides it.

Round-trip efficiency is also the clearest example of a number that cannot be read off a gauge. It is energy out divided by energy in over a completed cycle, which means it depends on detecting where the cycles were before it can be computed at all, and it moves as the asset ages. Storage is where Fleetera's starter KPI packs land first: round-trip efficiency, cycle detection, and capacity fade come as reviewed definitions for the storage asset type, in early access, and you approve them once before they measure every matching site.

Everything above is a statement about meaning, and meaning has to survive the trip from the equipment to the screen. On a mixed fleet that trip is harder than on a single-technology one, because a turbine controller, an inverter, a battery management system, and the metering at the connection point are four different vendors speaking four different dialects, and none of them was built expecting the others to be read alongside it.

The concrete version of this is familiar to anyone running turbines from more than one manufacturer. Three OEMs across a portfolio means three SCADA portals: three logins, three names for what is recognizably the same measurement, and three conventions for what an availability figure excludes. Nobody set out to build that. It is what buying the best available machine in three procurement rounds over several years produces, and the same thing happens again with inverters and with battery systems.

The cost lands on one desk. The owner's monthly report is assembled by exporting from each portal and reconciling the columns by hand, which is why it is late, why it is hard to audit, and why the answer to a follow-up question is another export rather than a query. The reconciliation is also where the errors live, because it is the one step in the chain with no record of how it was done.

In practice that resolves into four requirements, and a tool that misses any one of them pushes the work back onto people.

1. 1Reach every vendor over the protocol it already speaks, without asking the controllers to change
2. 2Keep recording at the site when the link drops, because renewable sites are remote and connectivity is not a given
3. 3Model each class as its own asset type with its own typed variables and units, rather than flattening all three into one shape
4. 4Keep a history long enough that a season-over-season comparison is a query rather than a project

Fleetera's runtime ships as a single binary per site with built-in drivers for OPC UA including subscriptions, Modbus TCP and RTU, MQTT, and REST, so a hybrid site with all three technologies behind one interconnection is one deployment rather than three. Its dual hot and cold buffer keeps recording through restarts and through a lost connection, and streams what it holds once the link returns. A gateway that cannot reach the cloud is still collecting.

On the modeling side, the point of separate asset types is that they stay separate. A turbine type carries turbine variables, an inverter type carries inverter variables, a storage rack carries state of charge and cell temperatures, and each of them is defined once and stamped across every matching machine. What makes it a fleet rather than a filing cabinet is that all of them live in one model, so a single screen can show generation, storage, and the interconnection together without anyone stitching three exports.

This is the question every mixed-fleet operator eventually asks, and the honest answer has two halves. Some quantities genuinely add up across the classes. Most of the interesting ones do not, and forcing them to is how a portfolio dashboard becomes something nobody trusts.

Energy adds up, because a megawatt hour is a megawatt hour wherever it came from. Counts add up: assets, sites, open alerts, machines currently faulted. Anything measured in the same unit against the same denominator can be summed and still mean something.

Ratios do not. Availability, performance ratio, and round-trip efficiency are all fractions whose denominators are defined differently per class, so an average of the three is a number with no referent. It cannot be checked against anything, it moves when the mix of the portfolio changes rather than when the assets do, and it hides the one class that is actually in trouble behind two that are fine. A single blended availability figure is not a summary of a mixed fleet, it is a way of not looking at one.

Unpack what operators are asking for and it is rarely a single score anyway. The useful portfolio view is one place to look and see which sites are producing, which assets are faulted, which signals have gone quiet, and where a class-specific number has moved outside its band, without opening three vendor portals to find out.

The mechanics above are deliberately general, because the argument is about what the classes have in common and where they diverge. The equipment-level detail is per class, and each one has its own page: wind farms, solar plants, battery storage, and hybrid plants that run more than one technology behind a single interconnection.

Wind farms

Turbine controllers, met masts and nacelle sensors, park controllers, and the substation behind them, across multi-vendor farms.

Solar plants

Inverters and combiner boxes down to string level, trackers, irradiance and module temperature, and the metering at the connection point.

Battery storage

Racks and modules with cell voltages and temperatures, power conversion, thermal and fire-safety systems, and the auxiliary load that decides real efficiency.

Hybrid plants

Wind, solar, and storage in one asset tree behind one interconnection, so generation, storage, and net export are visible together.

If your fleet is heading toward more than one of these, the ordering advice is the same as it is for any modeling exercise: get the asset types and their variables right on the class you know best, then stamp the second technology into the same model rather than standing up a second system beside it. The second system is always faster to reach and always the thing that has to be unpicked later.