Home / Alarm Health Alarm Health

An ISA-18.2 review of your alarms, with the fix for each one.

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.

What it finds

Six kinds of alarm problem

Each finding comes from an analyzer on the gateway, with default thresholds you can change per playbook.

ProblemFlagged whenProposed change
Chattering3 or more activations within 60 secondsA 15-second clear delay, plus a 2 % deadband on a setpoint alarm whose deadband is smaller
FleetingAt least half of 5 or more occurrences clear in under 5 secondsA 5-second clear delay
StaleStill active at the end of the window, for longer than 24 hoursReviewed by your team
DuplicateTwo alarms on the same equipment activate within 2 seconds of each other on 80 % of occurrencesReviewed by your team
PriorityThe low, medium and high split is 15 points or more away from 80, 15 and 5 percentReviewed by your team
Flood and rateMore than 10 alarms in a 10-minute period, or more than 6 an hour on averageReviewed by your team
What each one looks like

On a real floor

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.


Fixes that respect your UDTs

The change goes where the alarm is defined

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.

Your engineers decide

Findings are recommendations

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.

The KPIs

The numbers behind every run

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.

Questions

Common questions

How often should Alarm Health run?+

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.

Will it change our alarm configuration?+

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.

What does it need?+

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.

Next step

Find out what your alarm journal says. Get in touch.

Guided setup puts Artekis on your own alarms in one remote session. Tell us about your gateway and we will reply.

Contact us →