Alarm Health reads your alarm journal, measures it against ISA-18.2 and EEMUA 191, and turns each problem into a finding with the evidence and the configuration change that fixes it.
Each finding comes from an analyzer on the gateway, with default thresholds you can change per playbook.
| Problem | Flagged when | Proposed change |
|---|---|---|
| Chattering | 3 or more activations within 60 seconds | A 15-second clear delay, plus a 2 % deadband on a setpoint alarm whose deadband is smaller |
| Fleeting | At least half of 5 or more occurrences clear in under 5 seconds | A 5-second clear delay |
| Stale | Still active at the end of the window, for longer than 24 hours | Reviewed by your team |
| Duplicate | Two alarms on the same equipment activate within 2 seconds of each other on 80 % of occurrences | Reviewed by your team |
| Priority | The low, medium and high split is 15 points or more away from 80, 15 and 5 percent | Reviewed by your team |
| Flood and rate | More than 10 alarms in a 10-minute period, or more than 6 an hour on average | Reviewed by your team |
Each of these is a finding with the journal rows behind it and, where Ignition has a property for it, the change written in that property’s name. The scenarios are illustrative.
When an instance inherits the alarm from a UDT type, Artekis proposes the change on the type and states its reach: how many instances inherit the alarm, how many are in this area, and how many show the problem, with examples. Your templates stay templates. When a setpoint comes from a UDT parameter, the proposed deadband follows each instance’s own setpoint.
Each finding opens with its evidence and proposed change. Your engineers record a verdict: confirm, known issue, dismiss, or wrong. Nothing is applied by Artekis. After your team applies a change, the next run shows whether the problem cleared, and the finding resolves itself when it has.
Every run also builds a KPI document before the model is called, so the figures come from the journal, not from the model.
The KPIs feed the Alarm KPIs view in Perspective and an 8-page PDF report rendered by the Reporting module in about a second, ready to schedule to your team.
Weekly is typical, over a 7-day window. It can also run on demand, or over a longer window such as 30 or 180 days when you first install it.
No. It proposes the change, in Ignition’s own property names, and your team applies it under your change control. A re-run after the change shows whether the finding cleared.
An alarm journal profile holding the alarms you want analyzed, and a context model naming the plant area’s alarms. The PDF report also needs the Reporting module.
Guided setup puts Artekis on your own alarms in one remote session. Tell us about your gateway and we will reply.
Contact us →