Question: Do frequent operator alarms indicate a process that is well understood or in control?
No. Frequent alarms, instead, represent a "red flag" to FDA inspectors. Yet, sophisticated IT, "smart" instrumentation and the low cost of configuring more alarms to each Input/Output may be leading to an explosion of pharma plant alarms at some pharmaceutical plants today.
As usual, the "golden rule" should apply, and systems designers must put themselves in plant operators' shoes. How could any operator be expected to respond to over one thousand alarms per system, the typical number for many drug manufacturing plants?
Our next issue will include an article on alarm systems and their management by Joe Alford, who retired last year after an illustrious 35-year career in process control and process analytical technologies (PAT )with Eli Lilly. As he mentions, alarms are meant to instruct and guide operators, and are only supposed to indicate problems that require responses.
If any engineers defend the need for thousands of alarms, he suggests, ask them to look at their own cars. The number of real "alarms" on any automobile is typically five, and they're distinct and easy to read and respond to. Pharmaceutical plant alarms should be prioritized, to reflect key product quality/safety variables as well as Environmental, Health and Safety issues.
Unfortunately, operators at most pharmaceutical facilities are still deluged with alarms---some of them are just nuisance alarms, but they still require a response (and may, in the process, distract an operator from a real emergency).
In some cases, simple notifications (e.g. "The process is completed) are sent via the alarm system, which should not be the case.
Stay tuned to the article next month. But in the meantime, here is a quick checklist of tips from Mr. Alford:
- Consider desired alarm functionality when defining Functional Requirements (near the beginning of a project) when time is available for any customization needed (for example, to output alarms to pagers).
- Do not assume that off-the-shelf products will provide all desired alarm functionality
- Define the "end in mind" (near the beginning of a project) regarding what use will be made of alarm records. This will influence the selection of alarm categories, priorities, etc. when designing / rationalizing individual alarms.
- With minimal exceptions, configure alarms only for abnormal situations requiring a response. Use other areas of the HMI / MMI (system permitting) for informational messages, or use color and other graphical means to distinguish between alarms and informational messages.
- Determine and document the expected operator response when designing / rationalizing alarms. Consider coding the expected response on-line. Remember that an effective alarm Alerts, Informs, AND GUIDES.
- Include tools in historians (or third-party products such as alarm loggers) to allow for the querying, sorting, charting, and batch reporting of alarm records.For example, a pareto chart could be used to depict alarm frequency.
- Implement a monitoring program, to include operators, in which continuous improvement is pursued (including reduction of nuisance alarms).
- Maintain the mindset that nuisance alarms can be a major frustration for operators, may contribute to them missing real abnormal situations, and, if excessive, may call into question the state of validation of the system.
- Consider developing a more "risk based" change control procedure to expedite minor changes to automation logic. (e.g. it should not take weeks to administer the adjustment of an alarm deadband value to reduce the incidence of a chattering alarm).
- Recognize that alarm management is really a shared responsibility between:
