When one sensor fails, a fused system should degrade rather than fail as a whole

What it is

Once fusion binds several streams into one judgment, a common failure is one stream lifting off, running out of battery, or losing permission—and the whole feature going dark. Graceful degradation asks the system to keep producing a weaker, still-honest output on a subset, rather than working only when complete and either silencing or guessing when one channel is missing.

Why it happens

Many fusion graphs assume a complete observation vector at training time and impute the mean at inference, which treats “the sensor is dead” as “we measured the average.” The right object is a discrete state of sensor availability, with its own likelihood and output contract per missingness pattern: IMU only reports activity class, not heart rate; EDA gone stops stress adaptation. A Kalman filter can drop a failed row from the observation matrix; covariance grows, and that growth must reach the UI as “uncertain,” not a continued green light. Degradation is also product topology: which features may live on a subset, which must stop, listed at design time rather than left to exception handlers.

Studying it

Turn sensors off by combination (2^N is enumerable for small N) and measure accuracy, whether anything is still emitted, and whether output carries an uncertainty mark. Factors: missingness handling (drop / mean-fill / mode-specific model). Outcomes: dangerous false alarms (high confidence while failed), feature survival, whether users understand current capability. Field work should include permission revocation and charging interrupts, not only unplugging in the lab.

Where it stops holding

Some safety features must refuse to work without a critical channel (no degrading to “probably no fall”). The degradation path itself can be an attack surface: an adversary turns off the reliable channel to force a noisier subset. Missingness patterns never seen in training cannot be made safe by generic interpolation. Telling the user about the current subset matters more than maintaining a fake completeness, but telling too often becomes a new interruption.

Applying it

• Write a missingness table for each fused feature: stop, degrade to which output, how to signal.
• When a channel fails, widen the confidence interval or disable adaptation that depends on it; do not fire as usual after mean fill.
• Use a stable “partial sensing” state on the UI rather than a feature that blinks in and out with no explanation.
• Verify by unplugging or disabling each channel at runtime: no high-consequence action should still execute at high confidence in a failed mode, and the user should see that capability has dropped.

Related

• Same group: C9.08.1 Noise and blind spots of a single sensor can be offset by fusing other sensors · C9.08.2 Fusion must time-align sensors whose rates and latencies disagree · C9.08.3 Fusion raises confidence while widening the kinds of data collected and the privacy scope
• Adjacent: C4.25 Predefined Fallback Paths · C9.09 Wearable Fit and Signal Quality
• Search: graceful degradation · missing observation · sensor failure