Solar Farm Asset Performance Anomaly Detection

Preview

This is an AI-assisted simulation project built to develop familiarity with the processes, methods, and terminology used in solar asset performance management. Key objectives included detecting and classifying synthetic fault events using three statistical methods, and quantifying their financial impact through Performance Ratio analysis.

‍

Technologies & Domain Concepts

‍

Project Report: Solar Asset Performance Anomaly Detector

Purpose and Design Goals

This project simulates the end-to-end analytical workflow of a solar asset performance team. The goal was to build familiarity with the terminology, methods, and decision patterns used in analytics developer roles at solar asset managers, by constructing every stage from scratch rather than using pre-built frameworks.

The core analytical loop at a solar asset manager looks like this:

1. Weather data
2. Expected output
3. Compare with measured output
4. Detect underperformance
5. Rank severity
6. Identify cause
7. Quantify financial impact
8. Prioritise O&M action
   

Each stage of this project maps to one node in that loop.

‍

Stage 1: Data Ingestion and Simulation

The data source

Weather data comes from NASA POWER (Prediction of Worldwide Energy Resources), a public API that returns gridded satellite-derived climate data for any lat/lon without authentication. Two variables are used:

• ALLSKY_SFC_SW_DWN: Global Horizontal Irradiance in kWh/m²/day. This is the total solar energy reaching a horizontal surface — the fundamental input to any energy model.
• T2M: Air temperature at 2m, used for the panel temperature correction.

Why not use hourly data? Daily aggregation is standard for asset performance monitoring. Single-inverter failures, soiling, and curtailment events all persist for days to weeks — sub-daily resolution adds noise without improving detection for these fault types. Hourly data becomes important for curtailment detection (a grid signal that arrives and clears within hours) and for production forecasting, but not for the multi-day anomaly detection this project focuses on.

The physics model

Expected output is calculated as:

E_expected = GHI × panel_area × efficiency × temperature_correction

Where temperature_correction = 1 + (−0.004 × (T2M − 25)), clipped at 0.85.

Three design decisions here worth understanding:

Decision 1: GHI not POA (Plane-of-Array) irradiance.

In real asset management, irradiance is measured at the panel surface angle (POA). A fixed south-facing panel at 30° tilt receives more annual energy than a horizontal surface because it's angled toward the sun's arc. POA is 10–20% higher than GHI for a well-oriented system. This project uses GHI because the NASA API provides it without needing tilt/azimuth transposition. Real performance models (PVSyst, SAM) always use POA.

Decision 2: No PR term in E_expected.

The expected output formula intentionally excludes the 0.80 baseline PR. E_expected represents what the panels could produce given the available light and temperature — it is a physical ceiling, not an operational forecast. Performance Ratio is then the measured ratio of actual to expected, and it naturally settles near 0.80 for a healthy farm. If you included PR in E_expected, you'd be building 0.80 into both sides of the fraction and PR would always equal 1.0.

Decision 3: Temperature coefficient −0.004/°C.

Standard monocrystalline silicon panels lose about 0.4% of output per degree above 25°C. This makes a meaningful difference: in summer at 35°C, the correction is 0.96 (4% efficiency loss). At Okanagan's average T2M of 3.9°C, the correction is 1.084 — panels are nearly 9% more efficient than STC conditions on an average day. This is why E_expected > E_stc throughout the year at this cold site.

Fault injection

Three faults are hard-coded into the simulation with known windows, creating ground truth for later validation:

Why simulate faults rather than use real SCADA data? Because with real data, you don't know ground truth. You can't compute precision and recall on a real dataset unless you have manually validated fault logs. By injecting known faults, every detection can be evaluated as correct or incorrect. This is how detection systems are developed and tuned before deployment on real sites.

Additional simulated effects layered in:

• Daily Gaussian noise (±3%): Models day-to-day operational variance — cloud intermittency, temperature transients, measurement uncertainty.
• Linear degradation (0.5%/year): Industry standard for crystalline silicon panels. Degradation is subtle — over 3 years it accumulates to ~1.5% total PR loss, which is difficult to detect but meaningful financially.

‍

Stage 2: Anomaly Detection

Three detection layers run independently and are combined with OR logic. Each is designed to detect a different class of fault.

‍

Layer 1: Rolling Median Rule-Based Detector

PR_rolling_median  = trailing 30-day median of PR
flag_rule = (PR_rolling_median − PR_observed) > 0.10


Why median, not mean? A single severe day (say PR = 0.35 from a passing storm) would drag the rolling mean down, reducing the baseline and suppressing future flags. The median is resistant to this — one outlier in 30 days doesn't shift it. Median is the standard choice for robust baselines in control-chart applications.

Actual results:

• TP = 29, FP = 0, FN = 80
• Precision = 1.000 (no false alarms — anything it flags is a real fault)
• Recall = 0.266 (misses 73% of fault days)

The high precision / low recall profile tells you this detector is conservative. It only fires when the drop is large and rapid enough that the rolling baseline hasn't absorbed it yet. The 30-day window is both the method's strength (adaptive to seasonal baselines) and its critical weakness: soiling persists for 60 days, longer than the window. By day 30 of the soiling event, the rolling median has drifted down alongside the fault, so the apparent drop has shrunk below the 0.10 threshold. The soiling is mostly invisible to this detector.

Key insight: A rolling window method has a fundamental limitation — it cannot distinguish between "the baseline has genuinely changed" and "a fault has persisted long enough to alter the baseline." This is known as alarm masking by the reference. The longer the fault, the worse the masking.

Layer 2: Z-Score

PR_rolling_mean = trailing 30-day mean
PR_rolling_std  = trailing 30-day standard deviation
z = (PR_observed − PR_rolling_mean) / PR_rolling_std
flag_zscore = z < −2.5


Why only negative z-scores? Only downward deviations indicate faults in a performance context. A PR above the rolling mean is a good day; flagging it would produce meaningless alerts.

The z-threshold of 2.5: At 2.5 standard deviations, random noise (normally distributed) produces a false positive with probability ~0.6%. Over 1,095 days, that's about 6 expected false alarms — reasonable.

‍

Actual results:

• TP = 7, FP = 3, FN = 102
• Precision = 0.700, Recall = 0.064

‍

Recall of 6.4% means it detects almost nothing. Why? The same rolling window problem: during the soiling event, the rolling standard deviation widens because fault days contribute high-variance observations to the window. A wider standard deviation means the z-score stays closer to −2.0 even when the PR is genuinely low. The denominator grows as fast as the numerator, keeping z above the threshold.

The z-score is most effective for sudden, isolated step-changes — like an inverter fault that drops PR from 0.79 to 0.47 overnight. On the first few days of the inverter fault, the rolling std is still narrow (measured from the preceding 30 healthy days), so the z-score plunges sharply to −6 or lower.

Layer 3: CUSUM (Cumulative Sum)

deviation = (target_pr − PR_observed) − slack
S_t = max(0, S_{t-1} + deviation)
flag if S_t >= alert_threshold H = 0.20
# After alert: reset S to 0, suppress for 21 days (cooldown)


Why CUSUM is suited to gradual drift: The key insight is that CUSUM does not maintain a rolling reference. The target PR (0.79) is fixed. Every day where PR is below target-minus-slack adds to the cumulative sum S. Small deviations that look like noise to a rolling-window method accumulate silently in S until the total shortfall crosses the threshold.

The parameters and their meaning:

• target_pr = 0.79: Slightly below the 0.80 baseline to allow for healthy variation.
• slack = 0.01: Per-day noise allowance. Days where PR is 0.78 (1% below target) don't contribute to S — only genuine underperformance accumulates.
• alert_threshold H = 0.20: When cumulative deviations total 0.20 in PR-units, fire an alert. At −0.01 per day net deviation during mild soiling, this takes ~20 days to accumulate. For a severe inverter fault at −0.30 per day, it fires in less than one day.
• cooldown = 21 days: After firing, reset S and suppress alerts for 21 days. Without this, a persistent fault re-triggers CUSUM every ~3 days, flooding the alert log.

‍

Actual results:

• TP = 6, FP = 3, FN = 103
• Precision = 0.667, Recall = 0.055

‍

CUSUM appears to perform poorly on recall, but this is a measurement artefact. CUSUM fires once per fault episode (then resets with cooldown), while precision/recall counts every fault day as a separate observation. CUSUM's firing days are counted as single TPs, but there are 30 inverter fault days and 60 soiling days — CUSUM can only capture 1–2 of those as TPs per event. The correct way to evaluate CUSUM is at the episode level (Stage 3), not the day level.

‍

Combined detector

‍

flag_combined = flag_rule OR flag_zscore OR flag_cusum


Combined results: TP = 34, FP = 6, Precision = 0.850, Recall = 0.312.

The combined detector's 31% recall reflects the fundamental challenge of soiling detection: all three methods struggle to detect gradual, persistent drift that outlasts their reference windows or occurs between CUSUM reset cycles. The inverter fault (acute, deep) and curtailment (acute, moderate depth) are both well-detected. Soiling (gradual, 60-day duration) is largely missed.

This is not a failure of the implementation — it is a known limitation of these method classes. CUSUM is genuinely the best classical statistical tool for soiling. Machine learning methods (particularly LSTM autoencoders and Isolation Forest on multi-variate features including irradiance, temperature, and neighbour-site comparison) can improve recall significantly, but add complexity that's only justified at scale.

‍

Stage 3: Episode Grouping and Root Cause Classification

Why group days into episodes?

Day-level flags are operationally useless. An O&M team needs to know: "there is an event running from May 4–22, estimated cost $7,000, profile consistent with an inverter fault — dispatch a technician." Issuing 16 individual daily flags achieves nothing.

Gap-filling logic: Consecutive flagged days separated by ≤7 unflagged days are merged into one episode. The 7-day tolerance handles:

• Low-irradiance days in the middle of a fault window (PR = NaN, so no flag fires, but the fault is ongoing)
• Brief partial-recovery days in a soiling event where one rain shower temporarily cleans some panels before re-soiling

Actual episodes detected:

The two large, acute faults are perfectly detected and correctly classified. The soiling event fragments into 4–5 small episodes due to the CUSUM cooldown — when CUSUM fires and resets, it creates a detection gap that the gap-fill logic can't bridge (21 days > 7 days). Each small episode has a short duration and sharp consistency ratio, leading the root cause classifier to mislabel one as inverter_or_acute_fault.

Root cause classification heuristic

Two-tier decision logic based on episode shape, not just which layer fired:

Tier 1 — shape-based (for significant events):

The key signal is consistency_ratio = min_pr / mean_pr:

• A sudden, sustained step-down (inverter failure): PR drops sharply and stays flat at the new level. min_pr ≈ mean_pr, so consistency ≈ 1.0.
• A gradual ramp (soiling): PR drifts progressively lower.
  
  • min_pr << mean_pr, consistency well below 1.0.
• A cap (curtailment): Output is cut to a fixed level. Shape similar to inverter fault, but PR drop is moderate (0.10–0.20) rather than severe (>0.25).

Decision tree:

drop ≥ 0.25 AND consistency ≥ 0.90  →  inverter_or_acute_fault
drop ≥ 0.10 AND consistency ≥ 0.88  →  curtailment_or_partial_loss
duration ≥ 14d OR consistency < 0.88 →  soiling_or_drift

Why shape over layer dominance? For severe events, all three layers fire simultaneously — CUSUM, z-score, and rolling median all catch an inverter fault. Layer fractions are therefore similar across fault types for large events. Shape is more diagnostic because the physics of each fault type produces a characteristic signal.

‍

Stage 4: Loss Waterfall (recap in numbers)

The complete 3-year loss table for Site Alpha:

What this tells an asset manager:

The 2022 dip from 5,438 MWh (2021) to 4,821 MWh is explained entirely by the soiling + inverter events — 349 MWh of addressable losses in a single year. Both were one-off events; 2023 partially recovers (5,061 MWh).

The degradation trend (16 → 22 → 43 MWh/year) is small individually but compounding. Extrapolated to year 10, annual degradation loss would reach ~150 MWh/year — at that point it starts to rival the inverter fault. This is the driver for panel replacement planning at the 20–25 year horizon.

The residual category (55–61 MWh/year) is healthy — it represents noise within ±3% Gaussian variance. If residual were large and growing, it would indicate a systematic unmodelled loss (e.g., a persistent measurement offset, a shading obstruction not in the model, or sensor calibration drift).

‍

Stage 5: Fleet Benchmarking

Why specific yield, not PR?

PR (Performance Ratio) is irradiance-corrected efficiency — it tells you how well a site converts the available resource into output. Two sites with the same PR have the same conversion efficiency regardless of climate. But a site in California with 1.5× more irradiance produces 1.5× more energy per kWp, which matters enormously for revenue.

Specific yield (kWh/kWp/year) captures both: it is actual production normalised by nameplate capacity. It combines resource and efficiency into a single financial performance number.

Specific yield = E_actual / capacity_kWp

Fleet results:

Key fleet insights:

1. Beta produces 43% more specific yield than Alpha despite similar capacity. This is almost entirely irradiance — GHI of 5.45 vs 3.61 kWh/m²/day. Beta's hotter temperatures partially offset this (temperature losses reduce E_expected relative to E_stc), but the irradiance advantage dominates. California is simply a better solar resource than interior BC.
2. Alpha and Gamma are comparable (1,021 vs 1,054 kWh/kWp) despite Gamma having slightly higher mean GHI. Alpha's colder temperatures are a mild advantage (cold panels are more efficient). The two sites differ mainly in fault profile — Alpha had a severe inverter fault in Year 2; Gamma had a curtailment-dominated Year 3.
3. Year 1 is Beta's lowest-performing year (1,411 kWh/kWp) due to a 120-day soiling event beginning in spring (days 90–230). This is the highest-impact addressable loss across the fleet in a single year: 51 MWh lost, $3,338 revenue impact. For a real O&M manager reviewing the fleet, this would be the first investigation target.
4. Gamma's Year 3 P10 PR drops to 0.505 — the 10th percentile PR (the worst 10% of production days) is unusually low, indicating severe tail events. This is the curtailment window (days 730+55 to 730+95): on curtailment days PR = ~0.50. P10 is a useful fleet metric for flagging sites with extreme downside days even when median PR looks acceptable.
5. Portfolio revenue at risk: ~$40,000 over 3 years across three 5 MW sites. Annualised: ~$13,300/year. For a 100-site fleet at Clir's scale, this extrapolates to several million dollars per year in addressable losses — the direct commercial case for an analytics platform.

‍

Key Terminology Reference

‍

Design Decisions Summary

‍

Honest Limitations

1. Soiling detection is the main gap. Recall of ~30% on the combined detector means two-thirds of fault days are missed. The soiling event is largely invisible because all three methods rely on a reference that tracks the fault downward. An ML layer or a peer-comparison method (comparing to nearby sites) would substantially improve this.
2. Single-site Stage 4. The loss waterfall only runs for Alpha. In a production system, you'd run it for every site in the fleet and use the decomposition to rank O&M spend (e.g., "panel cleaning is cost-justified at Beta because annual soiling loss exceeds cleaning cost").
3. GHI not POA. The energy model systematically underestimates the irradiance available to tilted panels by 10–20%. This doesn't affect relative comparisons (PR is a ratio) but makes absolute specific yield figures lower than a real site would report.
4. No data quality layer. Real SCADA data has sensor outages, stuck readings, inverter data gaps, and timestamp errors. A production pipeline needs a data quality stage before any of this analysis can run.
5. Heuristic root cause. The two-tier classification is correct for 6 of 10 episodes in this simulation. In production with hundreds of fault types (partial shading, string outages, DC arc faults, tracking failures, snow cover), heuristics quickly become unmaintainable. ML classifiers trained on labelled historical events are the standard approach at scale.

‍