My RSS feeds pointed me to a great ChemicalProcessing.com article on batch manufacturing alarms. The article, Rethink batch-manufacturing alarm systems, was written by Joseph Alford.

He opens with provocative questions:

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.

Many with continuous processes would agree that their alarm strategies implemented inside their automation systems need work. The complexity is amplified in batch processes because unique operating conditions are created within all of the numerous steps along the way.

The article boils down the crucial steps to take:

The key considerations in achieving effective alarm systems include defining objectives early in a project’s life (i.e., in a plant’s alarm philosophy or a system’s functional requirements), adhering to the definition of an alarm, and implementing alarm-management best practices.

I ran this article by Todd Ham, a senior principal engineer in Emerson’s Life Sciences industry organization. You may recall Todd from earlier posts.

Todd agrees completely that a successful alarm strategy begins in the functional requirements stage of a project. The project teams work with pharmaceutical and biotechnology manufacturers early on in a project to document their alarm requirements.

Todd stressed that a good strategy examines not only what conditions require an alarm–typically an adverse effect to personnel, product, or equipment–but also what is the desired response. Is alarm annunciation sufficient? Does this require a device interlock? Should this put the batch in hold? Does quality assurance (QA) need to be notified? This is called exception handling.

In a batch process, the requirements may differ based on the process step. For example, the alarm may be critical during processing, but not important during cleaning. Further, the alarm may only need to be monitored once the process is at steady state. In these scenarios, the control strategy developed by the project team will selectively enable/disable alarms at the appropriate point in the sequence.

Todd cautions that this is not a “one size fits all” exercise. The project team and manufacturer’s staff must step through each process unit/system and ask a series of questions to arrive at a solution where alarms are both appropriate for a particular operating state and relevant for alerting operators to abnormal situations.

Todd agrees with the author that this work must be done up front, or the alarm flood, nuisance alarm scenario described in the article will be the result. You can’t wait until the end of the project to think about alarm management. When you come right down to it, it’s just as important as defining the control requirements for the project.