Why Choose TiPS?

LogMate is the most reliable, proven software solution since 1990

    • Leadership Participation in Alarm Standards Committees
    • Dedicated Alarm Management Focus
    • Comprehensive Alarm Management Software Solutions
    • Adaptable Services Model
    • Flexible and Extensive Software Connectivity Portfolio
    • Broad Industry Experience

Introduction to Alarm Management

Joseph Alford, Ph.D.

In automating a new batch plant or retrofitting an existing one, does the following situation sound familiar?

1. The team generating a plant’s alarm philosophy document and/or automation system specifications spends almost no time considering  alarm records, assuming that whatever DCS and historian that is chosen will contain whatever functionality is needed.

2. Facility alarm rationalization and/or design teams have plant operators in mind as customers and do not solicit input from users of historized records.

3. Alarm records are configured to include default types of information provided within the vendor’s system; e.g., a cryptic equipment specific descriptor (that only process/automation engineers understand), calendar time, and value of the PV and alarm set point.  Little, if any, batch process context is included (e.g., lot number, batch step/phase identifier).

4. Alarm records accumulate in the historian and are seldom reviewed or analyzed. Given the limited record tag information included and/or lack of relevant software utilities in the historian, the effort to extract information and knowledge content from alarm records is too manual and time consuming.

For plants subject to FDA approval (e.g., most pharmaceutical and biotech plants), now consider the frustration of plant technical service (often scientists) and quality control personnel that are required (by cGMPs) to identify and evaluate all process deviations potentially affecting product quality that may have occurred during a batch run. This must be done before product from the batch lot can be released for sale. The identification and results of evaluating such deviations are typically contained in the official production batch report.  Many, if not most, batch process deviations can be identified by alarm records, especially if such records are appropriately tagged so as to facilitate efficient querying, sorting, and analysis. Unfortunately, most batch alarm records are not so tagged, resulting in significant manual effort to obtain the information necessary for deviation incident analysis. E.g., the fact that a temperature alarm occurred at 10:15 AM on a certain date (i.e., calendar time)  may or may not be important and does not, by itself, imply a process deviation.

Rather, if the alarm is identified as having occurred 32 minutes into the sterilization phase of a batch process (i.e., relative time), this clearly implies a process deviation and provides more relevant information to personnel investigating such deviations. 
If users of batch alarm records (e.g., technical service and quality control personnel) have the opportunity to influence the plant alarm philosophy and automation system specifications, they might typically request that alarm records include a plain English descriptor (e.g., glucose feedrate – fermentor 101 and not FIC101), the alarm class (e.g., product quality, safety), the batch lot number, the step/phase within the batch for which the alarm occurred, and relative time (time since the beginning of the batch step/phase).  (Note: relative time could either be included in the tag or automatically determined via historian software utilities). This would allow personnel to quickly identify product quality deviations for a particular batch, with records containing information to assist in deviation analysis, and which provide data for direct insertion in the formal production batch report.  If such a specification were generated up front in a project, the design team might have sufficient project time to create the appropriate type of records, seek customization by the automation system vendor, or consider use of third party products (e.g., alarm loggers, e.g., LogMate®).

Conclusion:  Users of process data and alarm records can be important customers of a plant automation system. Include them when generating system functional requirements. Let users indicate how process data and alarm records will be utilized and use this information when designing and configuring the system. Note that batch processes are different from continuous processes (the primary focus of most commercial automation systems) in several respects and some of these differences can affect the alarm system design.

More detailed information on batch process alarm management can be found in ISA TR 18.06, (Alarm Systems for Batch and Discrete Processes), available from ISA.  This is a technical report developed in support of the ANSI/ISA 18.2 Standard on Management of Alarms for the Process Industries.

About the author:
Dr. Alford is semi-retired, having spent most of a 35 year career at Eli Lilly and Co. in automating their life science processes. He is a co-author of the ANSI/ISA 18.2 standard on alarm management, was co-chair of the ISA committee that developed and published the technical report (Alarm Systems for Batch and Discrete Processes) and is currently co-chairing the ISA committee creating a technical report on Alarm Management when Utilizing Packaged Systems.  He has also authored several journal articles and book chapters on various automation and computer validation topics, including alarm management.   He is currently an independent automation consultant in the pharmaceutical industry and guest lecturer at several universities. He is an AIChE and ISA Fellow and a member of the Process Automation Hall of Fame.