SCADA Is Not The Same As Solar Data Performance Analysis

SCADA Is Not The Same As Solar Data Performance Analysis

By: Adam Baker

Solar data performance analysis helps answer the “why” of low site performance.

Solar DataThree distinct systems work together to give you different types of visibility and
solar data points into your PV plant:

  • Controls
  • Performance analysis

I like to think of them as action, monitoring, and investigation, respectively.

Of all three pieces to the system, performance analysis is often left out of initial engineering design. But it’s arguably the most important piece, as it provides the insight on how to critically analyze your site performance.

But to understand the value of performance analysis, you have to understand the distinct differences between all three components.


Control: The Action Component

A control is a device (usually a PLC, Intelligent Datalogger, or RTAC, but sometimes a software environment) that sits in a rack, with no monitor. As programmed intelligence, a controller runs by itself with no need for human interaction, except to receive updated set points from the SCADA system. It runs at very high speeds (100 milliseconds), runs in real time, and doesn’t store historical data (except in rare occasions where it requires reference data to perform commands.)


SCADA: The Monitoring Component

SCADA acts as the visualization of solar data through an HMI. It allows a user to enter set points for control components, and is connected to multiple PLCs, processes, and devices. SCADA logs/collects/monitors control data, and annunciates alarms flagged by controls. Because it is created for human interaction, it has a slower response rate than control, typically in the range of tens of seconds. In a well-designed system, if SCADA is shut off, controls will still run, but the user will not have the ability to change set points.

SCADA is not conducting performance analysis
Although SCADA can have some capabilities to generate reports and plot trends, it’s not doing analysis.

Because SCADA is a real-time application, it conducts real-time trending, or historical trending when connected to a historian. Usually, the trends it plots are a linear graph of plant output vs time. A user can scale the graph to as few or as many days as they want to see, but the graph will simply show a single line of output over time. Days over time do not overlap, so it’s difficult to compare or see subtle differences from day to day.

solar-data-output-over-timeFor example, if you command your inverters to run at 100%, and they run at 90%, it might be because of clouds, blown fuses, soiling (dirt building up on module surface) or other external factors. It’s nearly impossible to program all the logic required in a SCADA system to determine if underperformance is caused by natural causes or something that should be generating an alarm. That differentiation is why performance analysis is crucial to utility-scale solar farms.


Performance Analysis: The Investigation Component

I like to think of performance analysis as the investigation component to the data collected from the controls by SCADA. It helps answer the “why?” by analyzing solar data historized by the SCADA system (via a historian and/or SQL database) and allows the user to answer questions such as:


  • Was there downtime yesterday?
  • What does a comparison of yesterday (Thursday) to last Thursday look like?
  • What does a comparison of yesterday to the same day a year ago look like?
  • What components underperformed?


Performance analysis can even get as detailed as comparing a day with similar weather conditions (ambient temperature and insolation), while factoring in the number of daylight hours, and time in inverter clipping to normalize watt hours. By using that formula, you’d be able to see that yesterday you made 45.2 MWh, but based on another day with similar weather, and sunlight, you were able to produce 47.2 MWh. Thus, you can conclude yesterday underperformed by 2 MWh, even though the day was shorter.

Stop relying on canned reports, start ad-hoc reporting
Performance analysis allows users to run two types of reports, both of which are often challenging to compute in a SCADA system alone: canned and ad-hoc. Canned reports tell you what happened, and ad-hoc give you the ability to answer why it happened.

A typical canned report might compare monthly revenue to how well the plant is running (MWh vs Wh of irradiance) for the previous month, and be automatically generated and emailed to operations on the 1st of the new month. They’re a simple way to understand how much a solar farm will be paid by a utility each month because a correlation exists between money earned, and sunlight. For example, you might expect to generate 5 MWh per kWh irradiance, translating to a ratio of 5,000. But if your ratio was 5,100 last month, a canned report doesn’t explain why your plant is performing worse than last month.

An ad-hoc report is the most powerful part of performance analysis because of its ability to drill down and investigate why. Ad-hoc reporting goes deep into the details of factors that could cause performance decrease. It’s not an automatically generated report, but created as the user investigates differences in component performance from one time period to another.

Solar Data

Say for example, you want to plot the combiner output of a single CBX from every inverter at a site from 6:00 AM to 7:00 PM each day of the previous month, with the condition that you exclude days that had more than 30% cloud cover. An ad-hoc report takes the values of a starting and ending point, and plots them together on the same graph to show comparative values, and makes it easy to see the values consistently less than others, even with intermittent dips from clouds that cover the site from time to time.


Case Study: the Value of Performance Analysis in Solar Data

When I worked with a large solar module manufacturer/EPC as a SCADA engineer, I spent a lot of time interacting with the performance engineering department. I was asked to look into a problem with a 290 MW site under construction. The site (only 30 MW at the time) was underperforming its energy prediction by 1.5%, and there were concerns the plant wouldn’t perform as expected after it was fully built. We were making the power we needed, but not the energy.

Through the historian reporting tool, I was able to easily plot the output of every inverter on a clear sky day, and though the inverter’s plots were the same shape, the ‘max output’ of about 1/3 of the inverters was ‘shorter’ than the rest, indicating they weren’t reaching their commanded output.

Using the data, I suspected the command reference to the inverter (a 4-20 milliamp signal) was coming up short. A field technician verified the command was correct, but the inverter was not reaching the command being sent. Based on the information, and field verification, we biased up the command signal by 1.5% to make all inverters run at maximum output again.

Because there was more AC capacity than was required at this site, the power commanded was meeting the expectation, but the energy lost due to inverters not doing what was expected was adding up.

It would have been nearly impossible to solve the problem with just SCADA data based on the information presented to operators at the time. In the big picture, we were making the power as expected, but the energy loss itself had gone unnoticed, and there was nothing available in the real-time data to suggest a problem existed.


Why Aren’t More Solar Farms Conducting Performance Analysis?

When considering solar data, not many do performance analysis well. They’re great at canned reports to determine monthly revenue, but don’t monitor or analyze possible site issues.

I’ve found there are five factors into why ad-hoc performance analysis is often neglected.

1. Ownership differs across controls/SCADA and performance analysis
Performance analysis is typically owned by operations, while controls/SCADA are owned by controls engineers. The only time performance analysis gets involved with the other team is when a SCADA/control upgrade happens, and they want to ensure name tags remain consistent.

Both groups should support each other. If performance was more integral within the controls/SCADA group, they would ask controls for more data, which would allow controls to add new points/instrumentation to their process to give performance analysis the data necessary for further evaluation. There can be such a thing as too much information, but performance engineers should have a DEEP understanding of the data needed for effective analysis.

2. It’s not included in the scope
In the solar industry, controls and SCADA are always included in the scope of work during construction. Performance analysis never is. It’s left to the owner to decide how to do reporting. The owner may or may not have created a budget for performance analysis. The owner may end up with several different SCADA platforms, and may lack data availability from one platform to another if the “requirements specification” does not spell out what data should be collected. I’ve never seen a SPEC that did a good job spelling it out.

3. Lack of deep understanding on how solar farms work
To do performance analysis well, you must understand (in minute levels of detail unknown to most of the world) how a solar power plant REALLY works. How are strings connected to harnesses connected to combiners? How much energy loss could occur due to spring pollen generated by trees near the site? Could you detect the effect of one leaf landing on one module? It is actually measurable.

Most owners don’t have this detailed level of knowledge.

4. Data is expensive
When it comes to analog data in SCADA and a historian, a good rule of thumb is ~$10 per data point. That can get pretty expensive, particularly if you try to keep everything. (See: Avoiding the Too Much Data, Not Enough Information Scenario) If the site has trackers, there may be more data available from the trackers than the rest of the site hardware put together. However, if you have a performance engineering team that knows what data affects your processes, you can pick and choose more efficiently.

5. No performance engineering team
If you don’t have a performance engineer to maximize the revenue for your plant, hire someone internal to your company or a third party consultant who really understands solar performance. This consultant should be concerned, not with power from the site, but factors that affect the MW hours per month, and the related plant inputs that can be tweaked to increase revenue.

The analytics to calculate performance are not always obvious. Irradiance is the biggest player, but humidity, rainfall, soiling, wind speed, temperature, and other external factors will affect performance. Some subtly, some not so subtly.


Start Differentiating Between Controls, SCADA, and Performance Analysis

Remember that in the grand scheme of your plant, it’s the WHY’s that matter. Just because your inverters reach maximum output does not necessarily mean you’re making all the energy you could be. Once a problem shows up, even a small one, you will live with it until you can identify it. The better the toolset to find the issues, the sooner you will be able to recover that lost revenue.

For context, consider if you were to lose a half a string of modules over the entire site. That translates to a loss of 30 kW an hour during generation, which translates to more than $200,000 over the life of the plant (30kW x $0.07/kWh x 11 hr/day x 365 days/yr x 25 yr). That’s at least enough to justify some investigation…


Adam Baker - Affinity EnergyAdam Baker is Senior Sales Executive at Affinity Energy with responsibility for providing subject matter expertise in utility-scale solar plant controls, instrumentation, and data acquisition. With 23 years of experience in automation and control, Adam’s previous companies include Rockwell Automation (Allen-Bradley), First Solar, DEPCOM Power, and GE Fanuc Automation.

Adam was instrumental in the development and deployment of three of the largest PV solar power plants in the United States, including 550 MW Topaz Solar in California, 290 MW Agua Caliente Solar in Arizona, and 550 MW Desert Sunlight in the Mojave Desert.

After a 6-year stint in controls design and architecture for the PV solar market, Adam joined Affinity Energy in 2016 and returned to sales leadership, where he has spent most of his career. Adam has a B.S. in Electrical Engineering from the University of Massachusetts, and has been active in environmental and good food movements for several years.