Event correlation eliminates alert fatigue in industrial condition monitoring.
Alert fatigue is the #1 complaint in industrial condition monitoring. The cause is structural, not operational.
A typical manufacturing plant with 50 monitored assets generates 200 to 500 threshold crossings per day. More than 95% of these are noise: oscillation around thresholds, transient spikes during startup, brief excursions that self-correct within minutes. Operators learn to ignore alerts entirely — or worse, they disable alerting altogether. When a real failure develops, the signal is buried in an avalanche of meaningless notifications.
The root cause is not bad thresholds. The root cause is that traditional threshold-based alerting treats every violation as independent. Cross a threshold? Fire an alert. Cross it again 5 minutes later? Another alert. The same capacitor bank degrading over 3 days generates 50+ separate alerts — each one indistinguishable from the first.
This is not a configuration problem you can tune away. Even with hysteresis bands and dead-zones, the fundamental issue remains: without temporal context, there is no way to distinguish a new problem from a continuation of an existing one.
IAES v2.0 introduces temporal condition awareness — the ability to distinguish onset from escalation from recovery within a single incident lifecycle.
Instead of treating each threshold crossing as a standalone alert, IAES tracks the state of each (asset, rule) pair through a deterministic state machine. A single incident — identified by a unique correlation_id — progresses through well-defined phases. Only phase transitions generate events. Everything else is suppressed.
Onset: The first threshold violation for an (asset, rule) pair. Creates a new correlation_id. Emits an asset.health event with condition_trend: "worsening". This is the only time a new incident is created.
Escalation: The same incident, but severity has increased (e.g., medium to high). Same correlation_id. An event is emitted only when severity actually changes — not on every reading that exceeds the threshold.
Suppression: The same incident, same or lower severity. No event is emitted. This is where 95% of the noise disappears. The threshold is still violated, but the operator has already been notified. Repeating the alert adds no information.
Recovery: N consecutive OK readings after an active incident. Emits an asset.health event with condition_trend: "improving" and severity: "info". Same correlation_id, closing the incident lifecycle.
Prevent phantom incidents from threshold oscillation
Each stage of the IAES pipeline dramatically reduces event volume while preserving every actionable signal.
actionable incidents instead of 500 alerts. Each incident is a complete timeline with correlation_id linking all related events.
A power factor drop at a manufacturing plant — from onset through repair to recovery. 3 events instead of 50.
First threshold violation for this asset and rule pair. A new correlation_id is created. IAES emits the onset event:
The threshold is crossed 47 more times. Severity remains at medium. Zero events emitted. The incident is already tracked. Repeating the alert would add no information — only noise.
Severity changes from medium to high. Same correlation_id. IAES emits the escalation event:
Five consecutive readings above 0.95 with 2% margin. Same correlation_id. Incident lifecycle is closed:
Between Day 1 and Day 4: The threshold was crossed 47 more times. IAES emitted exactly 3 events (onset, escalation, recovery) — not 50. The operator saw one incident timeline, not a wall of repeated alerts.
Multiple sensor types, one incident. The correlation_id unifies cross-parameter events into a single timeline.
Vibration RMS exceeds the 4.5 mm/s threshold according to ISO 20816-3 limits. A new incident is created with a fresh correlation_id. IAES emits an asset.health event with condition_trend: "worsening" and severity: "medium".
Temperature rule shares the same correlation_id because it targets the same asset during an active incident. Severity escalates to high. Instead of separate vibration alerts plus temperature alerts plus threshold re-crossings — dozens of notifications — the operator sees one escalation on the existing incident.
Vibration oscillates between 4.2 and 5.1 mm/s. Temperature holds at 78-83°C. The maintenance team has been notified and a work order is scheduled. Zero additional events emitted.
Five consecutive readings for both vibration and temperature are within normal limits with the required 2% margin. IAES emits the recovery event with condition_trend: "improving". The incident is closed. One complete timeline instead of dozens of scattered notifications.
IAES v2.0 defines the open pattern for event correlation: onset, escalation, suppression, and recovery as state transitions identified by correlation_id. The implementation described here — IncidentStateTracker with hysteresis parameters (recovery_count, recovery_margin_pct, min_incident_duration_s) — is part of the open specification. How you build intelligence ON TOP of correlated events — diagnosis, risk scoring, remaining useful life prediction, capital allocation optimization — is your choice. IAES provides the foundation. What you build on it is yours.