ArraySignal

Solar telemetry arrives as measurements over time, which makes ordering matter. The analysis has to distinguish one unusually low measurement from several, from a persistent trend, from a repeating daily pattern, from missing telemetry, from an abrupt change, and from gradual degradation.

Each interval is classified against an underperformance threshold. A rolling window then asks how many recent intervals were abnormal, whether they were consecutive, whether the condition persisted during valid production periods, and whether enough valid data existed to trust the answer. A rolling buffer makes this affordable on long series, because each new observation updates the window without reprocessing the whole history.

Data-quality checks run before any diagnosis. The gate considers missing measurements, invalid timestamps, duplicate records, impossible values, stale telemetry, missing expected-production inputs, and insufficient history.

The governing principle is that a missing telemetry stream and a healthy stream reporting zero power look similar on a chart and mean entirely different things. Equipment is not diagnosed before the data is checked, and a site that fails the gate produces a data finding rather than a fault.

Raw device power cannot be compared across devices of different ratings, so output is capacity-normalized: measured power divided by rated power. A 50 kW inverter producing 45 kW and a 100 kW inverter producing 90 kW both normalize to 0.90.

The peer baseline uses the median of comparable devices rather than the mean. Given peer values of 1.00, 0.98, 1.01 and 0.41, the mean is dragged toward the failing unit while the median stays representative of the healthy group. Relative device performance and an estimated per-device energy impact follow from that baseline.

I explored where machine learning might help classify fault patterns, and deliberately did not design it to replace the rule-based system. The architecture supports physics, deterministic rules and ML together rather than ML instead of the others.

A candidate deployment strategy is shadow mode: the rule-based result is what the user sees, while an ML result is recorded privately for comparison. That would let a classifier be evaluated against real cases before it influences anything a customer reads.

The part I find most interesting is avoiding data leakage during evaluation. Measurements from the same underlying failure event should not appear in both training and test sets simply because they occurred at different timestamps. The independent unit is the event or the site case, not the telemetry row, which makes group-aware evaluation and probability calibration part of the method rather than refinements to it.

This is a direction I investigated, not something the running application does.

A second direction I investigated works on a different time scale entirely: is a system gradually producing less over several years?

That is a different problem from detecting a short-term fault. Long-term analysis has to separate gradual decline from outages, equipment replacements, capacity changes, meter changes, configuration changes and sensor drift. A sudden step downward should not be read as an annual degradation trend.

I explored year-over-year approaches alongside ordinary least squares as a transparent cross-check, reported with a confidence interval, and treated change-point awareness as part of the method rather than an afterthought. What this taught me is that a trend estimate without uncertainty and change-point awareness can sound far more certain than the underlying data justifies.

This is the least complete part of the project and the one I care most about.

The approach I want to use is to test the models against independent real operating cases and record, case by case, where they are reliable, where they fail, and where the software should abstain rather than guess. Operator feedback feeds that record, because the operator is the only party who finds out what the fault actually was.

No systematic validation has been completed. No accuracy, precision, recall, detection-rate or false-positive figures exist for ArraySignal, and any such figure appearing anywhere should be treated as an error.

Expected-production modeling depends on site configuration data that may be wrong or missing, and a wrong expectation produces confident false findings. Irradiance data quality bounds everything downstream of it.

Clipping, curtailment and maintenance can all imitate faults. Device comparison needs enough comparable peers for the baseline to mean anything, and a two-inverter site barely has a peer group. Degradation estimates over short histories are weak regardless of estimator.

Rule thresholds are engineering judgements that have not yet been calibrated against real outcomes, and the machine-learning work is an exploration that sits outside any customer-facing path.