What your alarm system is not telling you about your operation

Every industrial operation generates thousands of data points per day. Your alarm system acts on a fraction of them — the ones that cross a line you set, once, probably years ago. Here is what is happening in the gap.

The gap between what happens and what gets flagged

Threshold-based alarms are designed to catch the failure after it has already started. A pump pressure drops below 4 bar and the alarm fires. But the deviation that caused the pressure drop — the slow change in bearing vibration, the incremental shift in temperature profile — happened hours earlier, invisibly, in a part of your data that no threshold was watching.

This is not a flaw in how your alarm system was configured. It is an architectural limitation. Static thresholds can only detect the symptoms of failure after the process has already crossed a line. They cannot see the pattern of behaviour that precedes the line being crossed.

The four alarms that were one failure

A pump system logged four separate alarm events in a six-hour window. Operators treated each as a separate incident. The root cause — a developing mechanical issue in a related component — was not identified until the asset failed completely.

When Eyer analysed the historical data, the picture was different. The four alarms were not four events. They were one correlated sequence, with the primary deviation appearing five hours and twenty-five minutes before the eventual failure. Every signal was in the data. No threshold was ever watching for the pattern.

Why operators stop trusting their alarms

The consequence of too many false or low-signal alarms is alarm fatigue. Operators in high-alarm environments develop unconscious filtering — they learn, from experience, which alarms to act on and which to ignore. This is not a failure of discipline. It is a rational adaptation to a system that cries wolf at low thresholds and stays silent at high ones.

The problem is that the filtering that protects operators from noise also filters out genuine early signals. The anomaly pattern that appears two hours before operational impact looks, to an alarm system, exactly like any other deviation below the threshold line. It never fires. Operators never see it.

What Eyer sees that your alarm system cannot

Eyer does not replace your alarm system. It operates earlier in the signal chain, on the same data, looking for something different.

Instead of asking 'has this value crossed a line?' Eyer asks 'is this value behaving the way it normally behaves, given how this asset has operated across its history?' The answer comes from three dynamic baselines per metric — a lower, central, and upper baseline, each learned from your historical data, each adapting continuously as your operation evolves.

When a deviation from those baselines appears, Eyer does not fire an alarm. It checks for correlation: which other signals are behaving differently at the same time, and in the same direction? If the answer is 'three related signals, all deviating in a consistent pattern', that is an alert — not a threshold crossing, but a behavioural anomaly that your operation has never seen before.

The early detection window

In a land-based salmon producer, Eyer detected a water chemistry anomaly pattern two to three hours before any operational impact was visible. No alarm ever fired during that window. The pattern was there, in the data, waiting to be read.

That window is not a technical curiosity. It is the gap between a problem that can be addressed and a problem that cannot. Two hours of warning on a water quality deviation in a RAS system is the difference between a preventable loss and a batch mortality event.

Your alarm system cannot tell you about what happens in that window. It was never designed to.