S-88 also provides guidelines on how to recover from abnormal events (which, of course, are typically associated with alarms). These guidelines include definition of procedural commands such as start, hold, pause, resume, restart, stop, abort and reset.
In addition, S-88 defines various states of a process (e.g., running, holding, pausing, aborting, etc.). This adds another dimension to the applicability and, therefore, configuration of a particular alarm — namely, the enabling of an alarm specific not only to a batch process step or phase but also to the process state. Managing states and transitions between states is a very important batch automation topic in that, for many processes, the amount of logic associated with these aspects of a process greatly exceeds that for the normal running of the process.
Vendor software off-the-shelf functionality
Most automation vendors’ roots are in the continuous process industries; they only recently have been addressing the unique needs of batch processes, including regulatory requirements for validation (such as electronic records and signatures).
Keep this in mind when starting a new automation project. The documented system functional requirements that typically are pursued near the beginning of a project may influence vendor selection or the need for customization of the system.
Often when a project engineering team has assumed that a vendor’s automation system will provide all the alarm (and other process control) functionality that will be needed, the end result has frustrated both automation engineers and users when it was discovered too late in the project timeline that the system didn’t provide all the desired functionality. Other project engineering teams have recognized alarm management limitations in commercial off-the-shelf software systems and, therefore, sometimes have chosen to interface third-party products (alarm loggers, paging systems, expert systems, etc.) with their core DCS/PLC/historian automation systems.
Other project teams have worked with automation vendors to customize their standard product offerings.
If your plant is struggling with huge numbers of alarms, take heart. Consider the total number of alarms that exist on an automobile. Although cars are complicated systems involving many different components, electrical circuits, frequent load changes and even critical safety operations, only a few alarms usually appear on most automobiles: e.g., low fuel level, unfastened seat belt, unauthorized entry, and engine maintenance needed. Each of these alarms represents an abnormal situation requiring a user response and presents information in a format that’s timely, accurate and easy to understand. A single alarm (not multiple alarms) warns of each type of abnormal situation.
This isn’t to say that a manufacturing plant should have very few configured alarms — but it does suggest that adherence to alarm management best practices can result in far fewer alarms than would otherwise exist. Indeed, it’s common for alarm remediation projects in industry to reduce total alarms by over 70%.
Take the crucial steps
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.
The following checklist can help plant project teams in avoiding some of the pitfalls in designing and implementing alarm management systems and in working more effectively with vendors.
- Identify desired alarm functionality when defining alarm management philosophy and system functional requirements — near the beginning of a project when there’s still time for customization (e.g., outputting alarm alerts to pagers). Don’t assume that vendor off-the-shelf products will provide all desired alarm functionality.
- Define in the early stage of a project what use will be made of alarm records. This can influence the determination of alarm attributes (e.g., categories and priorities) when designing/rationalizing individual alarms. It also can help identify the need for specific data mining and reporting software utilities.
- With minimal exceptions, configure alarms only for abnormal situations requiring a response. System permitting, use other areas of the HMI for informational/notification messages or use color and other graphical means to distinguish between alarms and such messages.
- When designing or rationalizing alarms determine and document expected operator response. Consider coding the expected response on-line. Remember that an alarm’s purpose is to alert, inform and guide.
- 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 individual alarm frequency, thereby helping engineers identify and focus on the situations generating the most alarms.
- Implement a monitoring program and pursue continuous improvement (including reduction of nuisance alarms).
- Maintain the mindset that nuisance alarms can be a major frustration for operators, may contribute to their missing real abnormal situations, and, if excessive, may call into question the qualification/validation of the system.
- Recognize that responsibility for alarm management typically is shared among process engineers (who should specify what alarms are required), automation engineers (who should implement the requested alarms) and operators (who are the primary customers). Assigning alarm management responsibility to only one or two of the above groups often is a formula for failure.
- Become familiar with ISA’s S-88  (for batch processes).
- Keep on eye out for ISA’s S-18 Standard on “Management of Alarm Systems for the Process Industries.” It likely will be published later this year. This standard builds upon the best guidance available in recent years — namely, EEMUA’s Publication 191 . It will define expectations for most key alarm-management activities during an automation system’s life cycle. Major sections will cover: philosophy/specifications; alarm rationalization/design; implementation/training; change management; and monitoring/assessment.
When working with vendors, keep in mind that they should be able to provide:
- configuration of all alarm attributes (rather than having them hard coded).
- change of alarm attributes as a function of batch process state, step/phase and process time/condition — with appropriate access security and audit trail functionality when manually making such changes on-line, as required for certain regulated industries (e.g., pharmaceutical and nuclear).
- several user-definable fields (such as lot number and batch step/phase) in alarm record tags.
- alarm configuration using all appropriate information in the automation system (for example, “if-then-else” rules). This often can lead to more intelligent on-line conclusions about a process versus just comparing a current value to a set point within an individual control loop.
- view of alarm information in relative time (i.e., from the beginning of the batch or batch step) in addition to calendar time.
- software utilities (such as Pareto charts) to help users analyze alarm information.
Joseph S. Alford, Ph.D., P.E., C.A.P., is a consultant in Zionsville, IN. He recently retired after a long career as an engineering advisor for a major pharmaceutical company. Reach him via e-mail at email@example.com.
- “Alarms Systems: A Guide to Design, Management and Procurement,” Publication 191, 2nd ed., Engineering Equipment and Materials Users’ Association (EEMUA), London, U.K. (2007).
- Hollifield, B. and E. Habibi, “The Alarm Management Handbook: A Comprehensive Guide,” PAS, Houston (2006).
- Alford, J., R. Stankovich and J. Kindervater, “Alarm Management: Regulatory Expectations and Selected Best Practices,” p. 25, CEP (April 2005).
- “Batch Control, Part 1: Models and Terminology,” ANSI/ISA-88.01, ISA, Research Triangle Park, N.C. (1995).