 |
Process Condition Model
|
Identification. What is and isn't an alarm? How do you know whether you should alarm an input from the field? ISA-18.2 provides clear guidance. It defines an alarm as "an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a response. The italics underscore an important alarm- management principle: if an operator doesn't need to respond, then don't provide an alarm! Pretty simple… Following this cardinal rule will eliminate a large portion of potential alarm-management problems.
Many sources -- e.g., process and instrumentation drawings (P&ID), operating procedure reviews, process hazards analysis (PHA), safety requirement specifications (SRS), hazard and operability studies (Hazops), incident investigations and quality reviews -- can help identify candidate alarms. You also can use alarms to indicate process performance boundaries such as off-target or pre-upset (Figure 1).
What it means. Identification involves determining what might merit an alarm and what should trigger it. Many process control systems allow configuring five or more alarm conditions (high-high, high, low-low, low, rate-of-change…) per input/output (I/O) point; this contributes significantly to alarm overload. Analysis may determine that only one alarm condition (such as "high") is necessary for a temperature input to keep a process safe and under control. Exercise engineering judgment to identify exactly what conditions require alarms and why rather than enabling every alarm condition available in the system.
Rationalization. Here, a cross-functional team from operations, process control, maintenance, safety, etc. analyzes each potential or existing alarm to make sure it meets the definition of an alarm. Does it indicate an abnormal condition? Does it require an operator action? Is it unique or do other alarms indicate the same condition?
Alarms that pass this screening are analyzed further to define their attributes such as alarm priority and alarm limit. Results are documented in a master alarm database that contains information such as:
• basis for the alarm;
• consequence of a deviation;
• expected operator action;
• time for the operator to respond;
• alarm class and priority; and
• alarm type and setpoint (limit).
What it means. The information documented in the master alarm database has value throughout the lifecycle. For example, many plant operations/engineering teams are afraid to eliminate an existing alarm because "it was obviously put there for a reason." With the master alarm database, you can look back years afterward to see why a specific alarm was set up and evaluate whether it should remain. It's also a good practice to make this valuable information accessible to operators — particularly the consequence if they don't correct the problem and how they should respond.
