Sensor Fusion: Why Multiple Weak Signals Can Produce Stronger Intelligence

One signal raises a question. Several independent signals that move together can answer it, and the math shows by how much.

Macro view of a small electronic sensor module with a domed lens on a yellow surface

A single sensor reading raises a question. Suppose a vibration level has crept up by a fifth. It might mean a bearing is wearing, or that the machine is running faster than usual, or that someone bumped the mount during cleaning. Two degrees of extra temperature might mean friction, or a warm afternoon. On its own, each signal is a weak clue.

Put several weak clues together and something changes. When vibration at a bearing's defect frequency rises, ultrasonic noise from the same housing rises with it, and the temperature climbs while load and ambient conditions stay flat, the case for a lubrication or bearing problem becomes strong. That is the idea behind sensor fusion, and it is one of the most practical tools in machine health monitoring.

An old idea with a precise meaning

Combining measurements to get a better estimate than any single one could provide is not new. Rudolf Kalman's 1960 paper on linear filtering gave engineers a principled way to merge noisy measurements over time, and it went on to guide spacecraft and aircraft. By the 1990s the field had a broader framework: David Hall and James Llinas, writing in the Proceedings of the IEEE in 1997, described multisensor data fusion as a discipline in its own right, with architectures, algorithms and known pitfalls.

In condition monitoring, fusion means using signals of different physical types, each sensitive to different aspects of a machine's state, to reach a judgment that is both more sensitive and more reliable than any one signal allows.

Why different signals help

The benefit comes from complementarity. Each sensing modality sees some faults clearly and others poorly, and each has its own sources of noise.

Vibration is the strongest general indicator of mechanical condition in rotating equipment, but it is affected by speed, load and structural resonances. Acoustic and ultrasonic sensing picks up friction, impacts and electrical discharge, sometimes earlier than vibration, but it is exposed to background noise from neighboring machines. Temperature is slow and late for many mechanical faults, yet it is the clearest sign of a loose electrical connection. Electrical measurements see inside motors and drives, but not into the pump they are turning.

Because the weaknesses differ, the modalities rarely fail in the same way at the same time. A noise source that fools a microphone usually does not raise the temperature. A load change that raises vibration also changes current, which tells the system the change is operational rather than a fault. Agreement between independent signals is evidence; disagreement is information too.

Three places to fuse

The literature distinguishes three levels at which signals can be combined, and the choice shapes the whole system.

Three panels describing data-level, feature-level and decision-level sensor fusion and their trade-offs
Fusion can happen on raw data, on extracted features or on separate decisions. Each step up trades detail for resilience to a single bad signal.

Data-level fusion combines raw measurements before analysis. It preserves the most information, but it is hard to do well across different sensor types because their sampling rates, units and time scales differ widely.

Feature-level fusion extracts features from each signal, such as band energies, RMS, kurtosis or temperature rise above ambient, and feeds them together into one model. It is the most common choice in machine health work because it captures relationships between signals without forcing raw waveforms into a common format.

Decision-level fusion lets each signal reach its own conclusion and then combines the votes. It is simple, tolerant of a failed sensor, and easy to explain, but it discards the subtle cross-signal patterns that a joint model can learn.

The level also decides where the work happens. Data-level fusion needs every raw stream in one place, which pushes it toward a central server. Feature-level and decision-level fusion can run on a device at the machine, because features and decisions are small. For equipment on constrained networks, that is often the deciding factor.

Practical systems often mix the levels: feature-level fusion for the main health model, with decision-level checks that can still act if one sensor drops out.

How much agreement is worth

It is easy to say that agreement increases confidence. It is more useful to see by how much. Take a deliberately simple example. Suppose 1 percent of machines in a fleet have a particular developing fault. Each of three sensors, working alone, catches 80 percent of those faults and falsely alarms on 5 percent of healthy machines. Assume, for now, that their errors are independent.

Bayes' rule then gives an uncomfortable result for a single alarm: only about 14 percent of machines that trigger one sensor actually have the fault. Most single-sensor alarms are false, simply because healthy machines vastly outnumber faulty ones. When two independent sensors agree, the probability rises to about 72 percent. When all three agree, it reaches about 98 percent.

Bars showing 13.9 percent with one alarm, 72.1 percent when two sensors agree and 97.6 percent when three agree, under stated assumptions
A worked example of Bayes' rule. The same sensors, the same thresholds; what changes is whether independent signals agree.

The assumptions matter. Real sensors are not fully independent. A loose mount can disturb both a vibration sensor and a microphone on the same bracket, and a heat wave can raise every temperature on a site. Correlated errors shrink the gain from agreement, which is why good fusion design pays attention to where errors come from, and not only to how many sensors there are.

Fusion and false alarms

The example also shows why fusion matters for trust. Alarm fatigue has ended many monitoring programs: when most alerts turn out to be nothing, people stop responding to all of them. A system that requires corroboration before it escalates can keep sensitivity high while cutting the false alarms that erode confidence.

The same logic helps with diagnosis. A rise in vibration alone says something is changing. A rise in vibration at a bearing's outer-race frequency, with matching ultrasonic activity and a temperature increase at constant load, says what is changing and roughly how far it has progressed. That difference turns a vague alert into an instruction a planner can use.

Where fusion goes wrong

Fusion is not automatically an improvement. Done carelessly, it can make a system worse, and the failure modes are well known.

Misaligned time. If two signals are stamped by different clocks, a cause can appear to follow its effect, and a model learns relationships that do not exist. Sensors on one device sharing one clock avoid most of this problem; sensors on different systems stitched together later often do not.

One bad channel dominating. A sensor that fails noisily, for example a loose accelerometer that rattles, can pull a joint model toward a false conclusion. Fusion designs need data-quality checks on every channel and a way to discount or exclude a channel that is no longer trustworthy.

Overconfidence. Counting two correlated sensors as two independent witnesses inflates confidence, as the worked example above warns. The fix is to model the shared causes explicitly, such as ambient temperature or load, rather than to assume them away.

Models that do not travel. A fusion model trained on one machine can learn quirks of that installation. Applied to a similar machine with a different mounting or duty, it may misread normal behavior as a fault. Per-machine baselines, learned in place, are one way to reduce this risk.

Fault fingerprints across modalities

Fusion becomes concrete when you look at how different faults show up across different sensors. Take a centrifugal pump driven by an induction motor, monitored for vibration, sound, temperature and motor current. Each common fault leaves a different pattern across the four.

FaultVibrationAcousticTemperatureMotor current
Bearing defectDefect frequencies in the envelope spectrumUltrasonic friction and impactsRises late in the faultLittle change early
CavitationBroadband, random energyDistinct crackling noiseLittle changeFluctuating load
MisalignmentStrong twice running speed, often axialModest changeCoupling and bearing heatSmall increase
Broken rotor barPossible beating at running speedPossible hum modulationRotor heatingSidebands around supply frequency
Blocked impeller or closed valveChange at blade pass frequencyChange in flow noiseFluid heatingLoad drops

No single column separates all five faults. Vibration alone can confuse cavitation with a rough bearing in some conditions; current alone sees little of an early bearing defect. Read together, the rows look quite different from each other, and that difference is what lets a fused system move from detecting that something changed to suggesting what changed. The table is a simplification, since real machines blur these patterns, but it shows why a device that observes several modalities at once has more to work with than one that observes a single signal very well.

Designing for fusion from the start

The simplest way to avoid those problems is to design fusion in from the beginning rather than bolt it on. Signals need a shared time base, so that a spike in one can be matched with a change in another. Sensors on the same asset should be mounted so that they observe the same component. Operating context, such as speed, load and ambient temperature, should be recorded alongside condition data so the model can separate duty from damage.

That is the reasoning behind AFFERENT's choice to build several sensing modalities into a single NODE device and to treat fusion as a core part of multimodal machine intelligence rather than an add-on. One signal is a clue. Several signals that move together are evidence.

Sources

More in Research