How to Add an Alarm

Procedure

1. 1

   Answer the rationalization questions

   What condition, what causes it, what happens if no one acts, what the operator must do, how long they have, what class it belongs to. If there is no operator action, stop here and configure an event instead. Write the answers down; they go in the database at the end.

2. 2

   Set the setpoint and its basis

   Choose the value from something defensible: a permit limit less a margin, a manufacturer limit, the operating envelope from a trend, a physical constraint. Record the basis. For a pre-alarm and alarm pair, set both here with different times to respond.

3. 3

   Set the deadband

   The amount the value must recover past the setpoint before the alarm clears. Typically 1 to 5 percent of range, larger on a noisy signal. Without it, a value sitting at the setpoint generates an alarm every few seconds.

4. 4

   Set the delays

   An on-delay so a transient does not alarm: seconds for a pressure, tens of seconds for a level, longer for a slow analyzer. An off-delay if the alarm should not clear on a brief recovery. Delays are tuning values and are recorded with the alarm.

5. 5

   Assign priority

   From the matrix, using the consequence and time to respond decided in step 1. Not from how important the equipment is.

6. 6

   Build the detection in the controller

   Compare the value to the setpoint with the deadband, through the on-delay timer, and gate it on the signal being valid: a bad-quality input must not generate a process alarm, but must generate its own. Latch the result into a dedicated alarm bit with a clear name. Add any state-based suppression from step 1: the low flow alarm is inhibited when the pump is commanded off.

7. 7

   Add acknowledgment handling if the platform needs it

   Some systems acknowledge in SCADA only; others carry an acknowledge bit back to the controller for local indication or a horn. Build what the site standard requires, and nothing more.

8. 8

   Configure the SCADA alarm

   Create the alarm record on the alarm bit: priority, area or group, and the message. The message states the equipment, the condition, and the action in a form that reads at a glance. Set the notification rule if the alarm calls out.

9. 9

   Test end to end

   Drive the real condition where it is safe, or inject the signal at the field terminals. Confirm the alarm appears with the correct priority and message, that the on-delay holds, that the deadband works on recovery, that acknowledgment behaves, that suppression inhibits it when it should, and that the notification path delivers it to the on-call phone. Test the bad-quality case by disconnecting the input.

10. 10

    Record it

    Enter the alarm in the master alarm database with every answer from step 1 and every setting from steps 2 to 8. Update the loop sheet or the I/O list. Tell the operators, and add the new alarm to the training record.

What the message should say

Where alarms should be detected

Detecting the alarm in the controller, rather than as a SCADA limit on a tag, is the general rule. The controller evaluates the condition every scan with the real value, it can gate the alarm on signal quality and process state, it keeps working when SCADA or communications are down, and the same bit can drive a local horn or a hardwired dialer. SCADA limit alarms are acceptable for information alarms on values that exist only in SCADA, such as a calculated total, and for quick temporary alarms during commissioning. They should not be the permanent home of a process alarm.

Verification

• The alarm appears on the operator screen and in the summary with the intended priority and message when the condition is driven from the field.
• The on-delay and deadband behave as configured on both edges.
• A bad-quality input produces the signal alarm and not the process alarm.
• State-based suppression inhibits and releases correctly.
• The notification path delivers and escalates as configured.
• The master alarm database has the complete record.