When we started building Watsynq's sensor fusion architecture, the first design decision we had to make was also the one with the most downstream consequences: how do you align sensor streams that run at fundamentally different timescales when the whole point is to detect correlations between them?
Acoustic emission sensors capturing stress wave bursts at 500 kHz. Triaxial accelerometers sampling at 25.6 kHz. Lube oil particle counters running a measurement cycle every 15 minutes. Thermal cameras or RTDs updating every 5–10 seconds. These aren't just different sample rates — they represent different physics operating on different timescales. A bearing defect generates an acoustic stress wave in microseconds, a vibration amplitude change over minutes, a particulate pulse in the oil stream over hours, and a thermal signature over hours to days. Fusing these into a single condition state requires solving several non-trivial problems simultaneously.
This article walks through the architectural choices we made and why, including the ones we changed after the first production deployment taught us things the design docs hadn't anticipated.
The timestamp alignment problem
The naive approach to multi-sensor fusion is: collect all streams, resample everything to a common interval, run a model across the resampled matrix. This approach breaks down at the edges that matter most.
The problem is that the leading signals in bearing degradation — the ones that appear earliest in the P-F interval — are the high-frequency ones: acoustic emission impacting, ultrasonic structural noise. If you resample those down to a 15-minute interval to align with oil particle count, you've discarded the temporal information that makes the AE signal useful. You know something happened in a 15-minute window; you've lost the burst pattern, the inter-arrival time distribution, and the frequency content that distinguish machine-normal stress wave activity from crack propagation initiation.
Our architecture instead maintains each stream at its native resolution and aligns at the feature level rather than the raw-sample level. AE is processed into feature vectors — burst rate per unit time, median burst amplitude, frequency centroid, ring-down count distribution — computed at a 1-minute cadence. Vibration is processed into spectral features — overall RMS, crest factor, bearing defect frequency band energy, harmonics of defect frequencies — also at 1-minute cadence. Oil particle count is carried forward at its native 15-minute resolution with linear interpolation between readings for the purposes of joint state evaluation. Thermal data is processed into residuals against a load- and ambient-compensated predicted temperature, at a 5-minute cadence.
The fusion layer operates on these feature vectors, not on raw sensor samples. This decouples the alignment problem from the resolution problem: you can have 500 kHz native AE resolution and 15-minute oil sample resolution in the same model because neither is being resampled — they're both being represented by features at a common decision cadence.
Failure-mode weighting: not all signals carry equal weight for all failures
Different failure modes in rotating equipment have different sensor signatures, and the architecture needs to reflect that.
For outer race spalling on a rolling element bearing, the first detectable signal is almost always acoustic emission — stress waves from the initial surface fatigue crack. Vibration follows, with BPFO sidebands appearing in the spectrum as the spall grows. Oil particulates follow some time later as debris enters the lube stream. Thermal signature is a lagging indicator, appearing only when the damage is advanced enough to generate frictional heat. For this failure mode, the fusion model should weight AE highest at early degradation stages and shift weighting toward vibration and thermal as the failure progresses.
For lubrication starvation, the signature is different. AE rises (metal-to-metal contact from inadequate film), temperature rises (friction), but defect frequencies in vibration may not show characteristic patterns until actual surface damage develops. Oil particle count may actually look clean — starvation doesn't generate debris until damage occurs. For this mode, AE and thermal together are the primary signals; oil particulate count is a lagging confirmation, not a leading indicator.
For bearing overload or misalignment, vibration is typically the primary signal — amplitude increase across the spectrum, elevated sub- and super-synchronous components, bearing defect frequencies may or may not be present. AE may be elevated if there's surface contact, but often less dramatically than in spalling-driven failures.
The architectural implication: the fusion model can't use static feature weights across all failure modes. We maintain a failure mode classification layer that runs ahead of the RUL estimation layer. Based on which signal combination is driving the anomaly, the model selects the appropriate weighting for the downstream RUL calculation. An AE-dominant anomaly with clean vibration and oil gets routed through the lubrication or early surface fatigue model. A vibration-dominant anomaly with specific defect frequency signatures gets routed through the bearing spall model. This isn't magic — it's pattern recognition built on the physical understanding of what different failure modes produce in different sensor modalities.
Handling asynchronous data loss
Industrial IoT deployments don't run in clean laboratory conditions. Sensors go offline. Network connectivity drops. Oil sample cycles get skipped because the auto-sampler ran dry or a maintenance tech disconnected it during an inspection. Any architecture that assumes all sensors are always delivering data will behave poorly in production.
Our approach: each sensor stream has an explicit data presence state — current (within expected interval), stale (last reading beyond expected interval but within degraded operation window), and absent (beyond degraded window, treat as missing). The fusion model runs at each cadence cycle using whatever streams are current or stale; absent streams are dropped from the feature vector and the model is evaluated with reduced feature dimensionality. The confidence output is attenuated when streams are absent — not zeroed, because the available streams still carry information, but the confidence band widens to reflect the reduced information state.
The degraded-mode behavior needs to be correct for a specific asymmetric failure. If the acoustic emission sensor goes offline and the bearing is actually early-stage failing, the model should not conclude "AE stream is quiet, no AE anomaly" — it should conclude "AE stream is absent, cannot evaluate AE-based failure modes, confidence reduced." The former produces false negatives in the worst case. The latter produces wider uncertainty bands and, if the absent state persists, an availability alert to the maintenance team.
Edge processing versus cloud processing: where we landed
This is a design choice with no universal correct answer. The right split depends on connectivity reliability, latency requirements, and the available compute budget at the edge.
We run feature extraction at the edge — the 1-minute AE feature vectors, vibration spectral features, and thermal residuals are computed locally on the sensor node or on a local industrial gateway. This serves two purposes: it reduces the bandwidth required to send data to the cloud (feature vectors are orders of magnitude smaller than raw waveforms), and it preserves the ability to generate local alerts if cloud connectivity is lost.
The failure mode classification and RUL estimation run in the cloud. The models are too large for the edge hardware we currently deploy against, and the historical context required for RUL estimation — comparing current degradation trajectory against the distribution of trajectories from previous failures of the same mode — requires access to the full training history that doesn't fit at the edge.
The latency implication: our earliest-stage alerts, based on edge-processed AE feature vectors, can fire within 2–3 minutes of the triggering AE event. RUL updates, which require the cloud round-trip, run at 15-minute cadence. For an early-stage bearing degradation developing over days to weeks, 15-minute RUL update cadence is more than sufficient. The 2–3 minute edge latency matters for acute events — a sudden onset of high-amplitude impacting that might indicate a lubrication failure in progress rather than gradual surface fatigue.
The normalization question: per-asset versus fleet-wide baselines
Should the model define "normal" relative to this specific asset's historical behavior, or relative to the population of similar assets in the fleet? Both have appeal. Per-asset baselines capture the idiosyncratic characteristics of a specific machine — manufacturing tolerances, installation variations, operating history effects. Fleet baselines enable comparison across assets and can provide a prior for newly commissioned assets that don't yet have individual history.
We use a hierarchical approach. New assets start with a fleet prior, weighted toward the historical behavior of similar asset types and sizes. As the asset accumulates operating history, the model blends increasing weight toward the per-asset baseline. After approximately 90 days of continuous operation, the model is predominantly per-asset with a fleet prior acting as a regularizer to prevent the baseline from drifting unrealistically.
This matters in practice for the Phoenix deployment context. A motor running at a desert facility has a different healthy signature than the same motor type running in a Pacific Northwest facility — ambient temperature effects, cooling cycle behavior, and seasonal load patterns all differ. A fleet-only model that normalizes against a mixed-climate fleet will set baselines that are wrong for either extreme. The hierarchical approach lets the per-asset baseline capture the local operating reality while the fleet prior prevents the baseline from absorbing slow degradation trends as "normal."
What we'd do differently
The feature cadence choice — 1-minute AE features, 15-minute oil — worked but created bookkeeping complexity in the fusion layer. In retrospect, a more principled approach would be to define fusion cadence as the minimum interval at which the slowest-updating stream provides meaningful new information, and let all faster streams produce multiple feature vectors per fusion cycle with a summary statistic (e.g., maximum burst amplitude over the window, rather than just the most recent). This preserves more temporal information from high-frequency streams without requiring every fusion evaluation to re-read the full high-frequency history.
The failure mode routing layer also started simpler than it needed to be, and grew more complex with each additional failure mode we added support for. If we were starting today, we'd invest earlier in making the routing layer explicit and configurable rather than encoding the routing logic into the model weights themselves. That would make it easier to add support for new failure modes — which turn out to be more site-specific and equipment-specific than we initially assumed — without retraining the entire fusion model.
These are the kinds of architectural lessons you learn when your test environment is a production plant rather than a bench rig. We'd make both changes in the next major architecture revision.