Reading the Plant Floor: Sensor Fusion for Operational Decisions

Walk onto almost any plant floor we've worked and you'll find a control room with more screens than the shift has people to actually watch them — a SCADA trend scrolling on one monitor, a vibration monitoring tool on another, a thermal camera feed on a third, and a fourth showing whatever the CMMS decided was worth surfacing that morning. Every one of those screens is individually correct. None of them, on its own, tells an operator what to do in the next ten minutes. That gap — between signal that's accurate and signal that changes a decision — is where most plant-floor analytics investments quietly stall out, and it's rarely a sensor problem. The plants we work with are usually not short on data. They're short on a place where that data gets to argue with itself before it reaches a person.

More sensors made the dashboard problem worse, not better

The instinct, when a plant wants better visibility, is to add instrumentation: another vibration sensor on the gearbox that's been acting up, a thermal camera on the panel that runs hot in summer, a tighter PLC polling interval so the SCADA historian catches transients it used to miss. Each addition is defensible in isolation. Collectively, they produce a control room where an operator has to hold four independent trend lines in their head and manually infer the thing none of the four screens states directly — that a slow rise in bearing temperature, a subtle shift in vibration frequency, and a PLC fault code logged forty minutes ago are three views of the same developing failure, not three unrelated events. We've sat with operators who caught that correlation anyway, from pattern recognition built over fifteen years on the same line. We've also watched a changeover shift miss it, because the correlation lived in someone's head and not in the system, and the plant ran the asset to an unplanned stop that a fused view would have flagged two shifts earlier.

Raw dashboards fail to change behavior for a specific, fixable reason: they present evidence and leave the inference to the viewer, under time pressure, shift after shift, and assume that inference will be made correctly and consistently every time. It won't be. Not because operators aren't skilled — because that's an unreasonable amount of correlation to ask a human to perform in real time across sources that were never designed to talk to each other.

Fusion means picking the decision before you pick the data model

The projects that work start from the opposite end of where most sensor initiatives start. Instead of asking "what can we build from SCADA, vibration, and thermal data," we ask what decision the floor actually needs to make — hold the line, flag the asset for inspection, adjust a setpoint, escalate to maintenance now versus next planned downtime — and then work backward to which signals, fused at what latency, actually inform that specific call. That ordering matters more than it sounds like it should. Vibration data fused with PLC fault history to support a bearing-replacement decision needs frequency-domain features and a maintenance-history join; the same vibration stream fused with thermal imaging to catch an electrical fault needs almost none of that and instead needs tight time-alignment between two very differently sampled sensors. Treating "sensor fusion" as one generic data-engineering task produces a system that's mediocre at every decision it's asked to support, because the underlying join logic, sampling alignment, and feature set are genuinely different problems wearing the same name.

What actually changed operator behavior

The version that worked on the floor didn't add a fifth screen. It replaced three of the four with one recommendation, stated in the operator's language — "Line 3 bearing showing early-stage wear consistent with the fault pattern that preceded last April's failure; recommend inspection within 48 hours" — with the underlying SCADA trend, vibration spectrum, and thermal frame one click away for whoever wanted to verify it before acting. The fusion did the correlation work up front, continuously, instead of asking a person to do it under pressure once a shift. Trust came slowly and had to be earned against a specific asset's failure history before operators would act on the recommendation without checking the underlying signal first — and that verification step, once trust was established, dropped off almost entirely. That's the actual measure of whether fusion worked: not how many sources you combined, but whether the person on the floor stopped needing to check.

The single pane of glass is a UI goal, not an engineering one

It's worth saying plainly: "single pane of glass" gets sold as a fusion outcome, and it's really a display outcome. You can put every sensor on one screen without fusing anything — that's aggregation, not fusion, and it doesn't reduce the cognitive load we started with. Real fusion is judged by what disappears from the operator's job, not by what appears on their screen.