Comparing sensor measurements with external data to detect issues

[williamhobbs]

Question:
Is identifying gradually worsening issues with sensors in-scope for PVAnalytics? For example, pyranometers with soiling or other sources of drift, or slowly detaching back of module temperature sensors:

VID_20190726_091653.mp4

Idea:
If the answer is yes, it seems that using external solar resource/weather data plus pvlib functions to estimate POA, module temperature, etc., could provide a useful reference beyond what can be done with, e.g., clear sky models. And PVAnalytics seems like a good home for tools to compare two (or more) measurement "channels" and flag alarming deviations. This could be done to better QC historical datasets and/or to check for sensor issues that need correction in "real time" (e.g., as part of weekly or monthly plant/site maintenance work).

On data sources:
Some users may have access to commercial near real time satellite data, and ERA5 could be valuable to anyone (with as little as 5 days of lag and going back to at least 1979). NSRDB PSM3 could work if the typical 6-18 months of lag is acceptable. Measurements from nearby PV plants or weather stations could also be an option in some cases. The tools could be agnostic to the reference data source, although results may vary based on site and data source.

Some relevant info on getting ERA5 or commercial satellite data into pvlib:

• Open pvlib pull requests with iotool functions for getting ERA5 and MERRA2 data: Add retrieval function for ERA5 reanalysis data pvlib-python#1264 and Add retrieval function for NASA MERRA2 reanalysis data pvlib-python#1274, .
• Discussion on getting ERA5 data: What to do about ERA5 and MERRA2? pvlib-python#1484.
• Discussion on getting SolarAnywhere data: Should pvlib have a get_solaranywhere function for fetching weather data? pvlib-python#1310.
• Issue on getting Solcast data: Integrate Solcast API into iotools pvlib-python#1313

Models/statistics to implement:
I don't have much to add here right now, other than some general ideas like:

• look at "normal" historical deviations to set bounds outside of which deviations could be flagged as "abnormal"
• allow for possible "normal" seasonal biases
• start with regular statistics, although some machine learning might later prove useful

What else has been done here:

• Add irradiance QC algorithm from Forstinger et al. #110 and QA methods for plane-of-array irradiance #123 are relevant, but I don't think they include trending measurements against independent modeled values (or measurements for totally separate but still nearby sensors)
• Maybe lots of other things I haven't researched well...

Tagging @silverman since we recently discussed this.

[cwhanse]

Short answer: I think sensor drift detection algorithms are within the scope for this repository. Due diligence: are there already capabilities in solardatatools or in rdtools?

Drift suggests slow variation in time, e.g., the sensor itself evolves away from its calibration set point. @toddkarin looked into this issue in a recent DOE project, without finding a satisfying answer, IIRC. The drift tends to be small relative to the signal magnitude and is easily lost in the seasonal and daily "noise".

The separation of the temperature sensor in the video suggests a different, more abrupt change. Perhaps the ruptures function could be helpful here.

[williamhobbs]

@cwhanse I haven't seen these capabilities in solardatatools or rdtools, although I am less familiar with solardatatools.

And to clarify on slow vs abrupt changes, I wouldn't want to exclude detection of abrupt changes - hopefully anything that can detect slow changes could do an even better job with abrupt ones. For the example video, I actually haven't looked back at at the data to see if there is an abrupt change, but there is another example that appears to be relatively slow, and some data are publicly available.

The EPRI Southeastern Solar Research Center (SSRC) in Birmingham, AL had multiple small (2.4kW) arrays, each with 2 back of module temperature probes.

Here's a photo of a similar sensor from the site (shown partially detached here):

The system was commissioned in March-April 2014, and initially the two sensors for the 1-axis tracking array were reporting similar values:

After 2 months, some drift is visually apparent in the data:

Then very obvious up until the sensor was repaired on Sept 26, 2014:

I'm showing non-public 1min data for individual sensors. I may have to get permission from EPRI to share that data (they plan to publish it soon), but 15 minute averages where the readings from the two sensors are averaged together are publicly available here https://dashboards.epri.com/ssrc/1767/pv-array-orientations for viewing or download.

POA irradiance is also available on the same page, and ambient temp and wind speed are available on another part of the dashboard, https://dashboards.epri.com/ssrc/1777/weather-station.

I can't find a photo of what the sensor looked like just before repair, but my recollection is that it was fully detached, possible hanging down a few inches, still partially supported by the strain-relief tape.

[cwhanse]

I wonder if a ruptures technique would detect an abrupt change in daily, daylit average temperature for the detached sensor. @kperrynrel thoughts on that?

[kperrynrel]

@cwhanse for abrupt changes, I would say ruptures is a good bet. The shift detection algo I put together was tuned for irradiance and power daily data, but could easily be adapted to temperature data (just for detection, not omission). I'd just need to put together the data set for temp data specifically and tune the parameters

[williamhobbs]

@kperrynrel Do you have details on the shift detection approach you've used? And would a version of the dataset I described above be helpful?

[kandersolar]

I believe the referenced method was just added in #142, and note the PVSC paper referenced in its docstring

[kperrynrel]

@williamhobbs I think a version of the above would be helpful--we can look at ruptures for abrupt shifts, and implement something more subtle (look at deviations) for gradually worsening issues

[williamhobbs]

@kperrynrel Here's 15min data from the public dashboard: SSRC_singleaxis_dashboard_data.csv. Back of module temperature is the average of two sensors (one working, one detaching). I'll work on getting you the 1min data that includes individual sensors.

Here's what some of the 1min data look like.

Faulty sensor (repaired 9/26/2014):

Working sensor:

Difference between sensors:

Difference, filtered to 11:00 to 15:00 local time:

Difference, filtered to 00:00 to 4:00 local time:

To my eye it looks like partial detachment starts happening after a few weeks, then full detachment probably happened mid-August.

[williamhobbs]

I suspect that the POA sensors (Licor LI-200 or LI-200r, I think) for the single axis tracker at the SSRC started drifting at some point as well (by ~2019). I haven't had time to look closely, but I'm mentioning it here in case someone wants me to revisit later.

[williamhobbs]

1-min SSRC data (which I used in plots above) were published by EPRI in November last year:

https://github.com/epri-dev/PV-Subhourly-Clipping