Rethink Batch-Manufacturing Alarm Systems

You can avoid common failings and improve performance.

By Joseph S. Alford, consultant

Share Print Related RSS
Page 1 of 5 « Prev 1 | 2 | 3 | 4 | 5 View on one page

 

Related articles

Avoid alarm blunders

Process management: Raise an alarm about alarms

Executing alarm management

Do operators sing the praises of your plant’s alarm system? No? Well, do they at least agree that generated alarms represent real abnormal situations requiring a response and that the automation/control system presents alarms in a timely, accurate and reliable way? No again? Well why not? Aren’t operators the primary customers of your alarm system? Perhaps it’s time for an alarm remediation project.

Operators’ hopes and expectations for a plant’s alarm system include:

  • minimal nuisance alarms;
  • alarm annunciation and displays unencumbered with notifications (i.e., routine messages not representing an abnormal situation requiring a response);
  • clear prioritization of alarms to indicate what’s most important during alarm floods;
  • no information overload or unnecessary multiple/redundant alarms during abnormal situations;
  • availability of sufficient information in easy-to-access and easy-to-understand form as to what the alarm is, where it’s occurring, and any other relevant supporting material; and
  • guidance about the expected response.

These expectations accord with universally accepted principles that characterize alarms — namely, an alarm should represent an abnormal situation that requires a response [1–3] and alarm systems should aim to alert, inform and guide operators to help them deal with abnormal situations [1].

If helping operators do their jobs isn’t incentive enough in implementing an effective alarm system or remediating existing ones, consider the perspectives of quality control groups and plant management.

If you were a quality assurance representative, regulatory inspector or a plant manager and saw that a plant was generating more than 1,000 alarms/month, wouldn’t that raise a red flag about whether the plant was “in control”? Wouldn’t you be particularly interested in any alarms pertaining to safety, environmental compliance or product quality due to their possible regulatory/liability implications? Wouldn’t the number of alarms suggest high plant variability and resulting consequences involving queues, increased average cycle time, reduced product yield and plant throughput, and extra runs needed to evaluate new ideas in plant trials?

If a high number of nuisance alarms is a major factor, that raises other issues. It suggests that alarms weren’t appropriately rationalized by the process design team or weren’t configured properly into the control system. This, in turn, might cause some operators to lose respect for the alarm system and start ignoring alarm annunciations, possibly then missing real abnormal-situation alerts.

The current situation

It’s not unusual for a manufacturing facility to average more than 1,000 alarms/month (with some plants averaging far more). Many operators are frustrated by both the number of nuisance alarms they receive and the total number of alarms. Quality control personnel can be frustrated with a large number of abnormal situation incidents that must be formally investigated before product is forward-processed or released for sale. Plant management can be frustrated with an unacceptably high level of process variability caused by frequent abnormal situations.

A number of factors contribute to the current situation:

Increase in configured alarms. Plant personnel continue to add alarms to automation systems. The number of configured alarms per operator has dramatically risen during the past few decades (Figure 1). Some of this is due to the increasing implementation of smart sensors and valves. These devices communicate a large amount of information with the host process control computer — so automation engineers are tempted to configure alarms to much of this additional information. Always ask the question: Does this really represent an abnormal process upset requiring a response from the operator? If the answer is no, it’s not an alarm and shouldn’t be configured as one. Use the same logic for alarm remediation projects for existing systems.

Page 1 of 5 « Prev 1 | 2 | 3 | 4 | 5 View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments