Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparing sensor measurements with external data to detect issues #143

Open
williamhobbs opened this issue Jun 29, 2022 · 10 comments
Open

Comments

@williamhobbs
Copy link

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:

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:

Tagging @silverman since we recently discussed this.

@cwhanse
Copy link
Member

cwhanse commented Jun 30, 2022

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
Copy link
Author

@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):
IMG_5194

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

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

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

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.

image

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
Copy link
Member

cwhanse commented Jun 30, 2022

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
Copy link
Member

@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
Copy link
Author

@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
Copy link
Member

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

@kperrynrel
Copy link
Member

@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
Copy link
Author

williamhobbs commented Jul 1, 2022

@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):
image

Working sensor:
image

Difference between sensors:
image

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

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

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

@williamhobbs
Copy link
Author

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants