Alarm management
Alarm management measured against ISA-18.2, not against opinion.
In-Sight ingests alarms and events directly from your OPC UA server, measures the alarm system against the ISA-18.2 and EEMUA 191 benchmarks, finds the floods, the chatter, and the bad actors, and correlates every alarm with what the detection layer saw on the same equipment at the same time. The alarm system becomes a measured asset rather than a source of fatigue.
The KPIs the standard asks for, computed continuously
ISA-18.2 and EEMUA 191 define what a manageable alarm system looks like: an average of one alarm per ten minutes per operator, fewer than ten alarms in any ten-minute period, no more than one percent of time in flood, and a short list of standing alarms. In-Sight computes those KPIs continuously from the raw alarm and event stream, per console and per shift, and shows where the plant stands against each benchmark.
- Average and peak alarm rate per operator position, per ten-minute window
- Percentage of time in flood and the duration of each flood
- Chattering and fleeting alarms, by tag, with rate of occurrence
- Standing and stale alarms, with age
- Priority distribution against the recommended 80/15/5 split
- Top contributors: the ten tags that generate the largest share of annunciations
Bad actors, ranked by contribution
Most alarm rationalisation effort should go to the small number of tags that generate most of the load. In-Sight ranks them by their share of annunciations, chatter rate, and standing time, and lets an engineer drill from the ranking into the tag's alarm history and the process trend underneath it. The rationalisation team starts with the list rather than building it.
Correlated with findings, never merged
An alarm is what the control system was configured to say. A finding is what the data actually shows. In-Sight keeps them distinct and correlates them: when a finding is raised on a tag, the alarms on the same equipment in the same window are attached to it, and when an alarm floods, the findings the detection layer raised in the lead-up are attached to the flood. An engineer sees both in one timeline and can tell whether the alarm system warned early, late, or not at all.
Confirmed alarm limits become a limit tier of their own, alongside engineering limits from datasheets and statistical baselines, so the platform knows which limits the control room already enforces and does not duplicate them.
From alarm analytics to action
Every KPI and ranking is a live dashboard tile and a report section. Alarm rationalisation outcomes, such as a changed setpoint, a suppressed nuisance alarm, or a re-prioritised tag, are recorded as dispositions and tracked for recurrence, so the team can show that the flood that used to happen at every start-up no longer does. The learning loop closes on the alarm system the same way it does on the process.
Alarm management capabilities
OPC UA A&C ingestion
Native Alarms and Conditions subscription, with historical backfill and gap tracking.
ISA-18.2 and EEMUA 191 KPIs
Rate, flood, chatter, standing, and priority distribution, per console and shift.
Flood and chatter detection
Detected as they happen and attached to the process findings from the same window.
Bad-actor rankings
By annunciation share, chatter rate, and standing time, with drill-down to the trend.
Correlate, never merge
Alarms and findings stay distinct and appear on one timeline.
Alarm limit tier
Confirmed alarm limits sit alongside engineering and SPC limits in the limit model.
Questions we are asked
- Which alarm sources does In-Sight support?
- OPC UA Alarms and Conditions is the primary source. Alarm and event histories exported from the DCS or SCADA historian can also be loaded as files for backfill and analysis.
- Does In-Sight change alarm configuration in the control system?
- No. It measures, ranks, and correlates. Changes to alarm configuration are made by the site's control engineers through their own management-of-change process, and recorded in In-Sight as dispositions so the effect can be tracked.
- What is the difference between an alarm and a finding in In-Sight?
- An alarm is raised by the control system according to its configured limits. A finding is raised by In-Sight's detection layer from the data: a baseline breach, a multivariate anomaly, a model prediction, or an engineering limit breach. They are correlated on one timeline and never merged.
- Can the KPIs be reported per operator position?
- Yes. KPIs are computed per console and per shift, which is what the ISA-18.2 benchmarks are defined against.
See your alarm system measured against the standard.
Connect the OPC UA alarm stream from one console and we will show you the KPIs, the floods, and the bad actors in one session.