What Field Data Hide: Hidden Signs of Failure and Predictive Maintenance

A LiDAR anemometer recorded 3.2 m/s continuously for 72 hours. The value was plausible for the site — within the historical range, without a physical limit flag, without a communication alert. The time series reached the system, was marked as "available" and integrated the availability calculation with 100% profit. Only in the monthly analysis — when the engineer plotted the rose of the winds and saw an impossible distribution — was that the failure appeared: the sensor had stopped.

Three days of null data disguised as real data. In a period of strong wind, with presence of relevant lightning events for site classification. Unrecoverable.

The problem is not uncommon. It is by far the most expensive category of error we find in campaign reviews: faults that pass in the check range, pass in the check completeness, and are only detected — when they are — at a time when the intervention window has already closed.

Three categories of hidden signal

The failures that escape basic detection fall into three patterns, each with different origin and different impact on the quality of the analysis.

1. Sensor freezing (stuck value)

The sensor records the same value — exactly the same, up to the last decimal place — by N consecutive records. Anemometers lock by ice, by dirt on the head, by communication failure in the Modbus protocol, by firmware bug. Pyranometers lock when the A/D converter locks or when there is signal conditioner failure.

The locked value is almost always a "real" value — it is the last valid value before failure. So it passes at any physical range check. Detection requires a criterion of persistence:

stuck_flag = True  if  len({ x[t-N : t] }) == 1  and  N ≥ threshold
# Example: 6 records identical to 10 min → 1 h brake → flag

The threshold depends on the variable and the temporal resolution. Wind speed stopped for more than 30 minutes (3 records at 10 min) is already suspect — atmospheric turbulence makes it impossible to reach the same values on a tens of minutes scale. Solar radiation can be legitimately constant (zero) at night, so the threshold needs to consider the time.

2. Slow drift of calibration or dirt

The sensor works — it is not locked, the values vary naturally — but the signal is being attenuated by dirt accumulated in the dome of the pyranometer, or derives from calibration in the anemometer transducer. The data seems normal. The anomaly only appears when compared to a reference: another redundant sensor, the clean sky model, or the instrument's own history.

The most effective technique for piranometers is the clean sky index κ_cs: ratio between the irradiance measured and that predicted by a radiative transfer model (PVLIB, REST2, Ineichen) for clean sky conditions. In consecutive periods without cloud, κ_cs should remain close to 1.0 for a clean sensor. A continuous drop trend is dirt signature.

For anemometers, the comparison reference is the redundant sensor (when available) or the model of reanalysis (ERA5, MERRA-2) for the detection of persistent offsets. The methodological difference is important: the model of reanalysis has uncertainty of the order of ±10% in the short term, then only detects large systematic deviations (>15%). The redundant sensor detects deviations of 2-3% — the relevant range for AEP.

3. Gaps with systematic time pattern

The third standard is the most insidious because it does not appear as a sensor failure — it appears as a lack of data, which already has treatment in the standard (IEC 61400-12-1 and IEC 61724-1 define minimum availability criteria).The problem is when the gaps are not random: they always occur at the same time, every day.

Common causes: data logger restarting by watchdog at 14:00 (loss of 10 min/day at peak irradiance time), unmapped obstacle shadow projecting on the pyranometer between 11h and 13h, radio interference of a nearby equipment that enters into operation at 08h. In all cases, the daily availability is high (>98%), but the missing data is correlated with the period of higher production — which generates a systematic bias in the resource estimate that is not captured by the percentage availability criterion.

The detection uses self-correlation analysis of gaps: if the interval between successive gaps has peak self-correlation in 24 hours (or 12 hours, or any daily harmonic), there is a temporal pattern that needs to be investigated before advancing in the analysis.

Why these failures go unnoticed

The trap is structural: the three patterns pass in the most common quality checks because standard checks check ♪ what the dice is ♪No, no, no. How the dice behaves in time.

* Only if the two sensors do not share the same data logger — otherwise the systematic gap affects both simultaneously and the comparison crosses as "both unavailable".

The practical implication: a QA/QC system based only on range checks and availability is blind to the most expensive failures. Persistence checks and slopes need to be part of the automatic flow, not the monthly manual review.

The cost of the detection window

The impact of each failure grows in a nonlinear way with time until detection. The three critical windows are: automatic detection in hours, weekly review, and monthly review — with completely different consequences.

T+1h detection costs essentially log revision time and reboot execution — the impact on availability calculation is hours, not days. T+7d detection already creates a gap that, depending on the period (seasonal peak wind, clean sky day), may not be recoverable by interpolation — and requires explicit documentation in the technical report of the impact on uncertainty. T+30d detection is the most expensive scenario: the data from this period are compromised, there is a risk of bias in seasonality, and reprocessing may require a new report — which directly impacts the bankability schedule and, in projects with funding deadlines, may delay decision making by months.

Implications for the useful life of the asset

The visible cost of undetected failure is invalid data. The hidden cost is the degradation of the instrument that the failure reveals — and that, without detection, continues to occur.

A piranometer with accumulated dirt that generates 0.15%/day is not only producing inaccurate data: it is operating in a state that increases the risk of damage to the dome and the temperature sensor. If the dirt includes corrosive materials (foiling, sea salts at coastal sites), the dome's silicon begins to be attacked — and the dome's replacement cost is significantly lower than the entire sensor's replacement cost. Detection on day 14 allows a field cleaning before dirt causes physical damage; detection on day 60 may already be late.

For LiDAR anemometers, the signal freezing can indicate the accumulation of ice in the optical head — which, if it persists, causes damage by thermal expansion to the ice/ice cycle. The detection in T+1h allows the heating system to be activated or a field intervention to be scheduled before structural damage. The detection in T+7d can find the head already compromised.

The logic, ultimately, is the same as the industrial predictive maintenance: the sensor that is failing continuously and silently—degrading gradually—is the most expensive to replace, because it only manifests when the component has already reached total failure. Early detection converts total failure into scheduled maintenance.

How to structure monitoring

The implementation of effective monitoring follows three layers, in increasing order of sophistication:

– Layers 1 and 2 are implemented in the data logger itself or in the campaign analysis software (BORA for wind power, NT.10 For solar flow via SOLANO). Layer 3 requires processing of an accumulated data window — at least 7 clean days for the slope κ_cs, and at least 4 weeks of data for the autocorrelation of gaps to be statistically robust.

The result of each layer should generate a structured flag — not just a generic alert, but a record with: affected variable, period, type of anomaly, estimated severity and recommended action. NT.05A project with documented and resolved flags has more credibility than a project without flags — the absence of flags in a 12-month campaign is suspicious, not reassuring.

The availability chain discussed in NT.01 For campaigns LiDAR assumes that the data marked as "valid" are actually valid. The three fault categories discussed here violate exactly this assumption: they count as available data without being available. The availability calculated with stack values included is not availability — it is transmission availability, which is a different metric and substantially less useful for bankability.