At least two universally accepted principles characterize alarms. Alarm systems should be designed to alert, inform and guide operators to help them do their jobs better. An alarm should represent an abnormal situation that requires a response [1-3]. Similar to alarm systems in other industries, in the pharmaceutical industry these systems typically include some focus on safety and environmental targets as defined by OSHA, EPA, corporate EH&S and local government permits. [3]

However, pharmaceutical and biotech companies are also beholden to the FDA, whose primary concern is with product quality. FDA expects that the processes and systems involved in manufacturing a drug to be qualified/validated and to comply with current Good Manufacturing Practices (cGMPs). These include alarm systems.

Unfortunately, alarm systems in the batch-oriented pharmaceutical industry, as with other industries, are often a source of concern. It’s not unusual for a manufacturing facility to average over 1,000 alarms per month, and many operators in the industry are frustrated by both the number of nuisance alarms they receive and the total number of alarms.

In optimizing alarm systems and their management, it is important to consider several key questions:

• Is the process being considered truly in control?
• Do alarms for batch manufacturing operations reflect the batch nature of such processes?
• What automation systems validation issues does the alarm system pose?
• Has sufficient attention been paid to rationalizing and configuring alarms?
• With off-the-shelf systems, have the vendors provided sufficient functionality for the given application?

This paper will address these questions, offering broad perspectives on how a drug manufacturing facility’s alarm management can be improved.

Is the Process in Control?

It is well known that quality cannot be tested into a product but must be built into the systems that make the product. In other words, the determination that a manufactured lot of product is acceptable to market assumes that it has been made using a formally validated process, as well as having passed certain in-process and/or final product tests.

A validated process is one that is “in control” and reproducible, while meeting expectations that it will produce a safe and effective product. If you were an FDA inspector and saw that a plant was generating over 1,000 alarms per month, would that raise a concern as to whether the plant was “in control?” Would seeing only 500 alarms per month be a concern?

Any system in which operator display consoles constantly show active alarms, or in which the historian shows a high total number of alarms per batch can be red flags to FDA inspectors that the process may not be in control. They’ll usually prompt further investigation. Thus, it is important to audit systems to ensure that they reflect a state of control.

Matching Alarm Systems to Batch Processes

Most automation technology, including process control computer systems and data historians, originated in continuous steady-state processes, such as petrochemicals processing. Only in the last few years have systems started to accommodate the additional requirements of batch processes (e.g., with batch historians), which are common in the pharmaceutical industry.

However, functionality gaps still remain with many commercial systems. First, consider the basic differences between batch and continuous processes. Batch processes are typically comprised of a sequence of many steps/phases with few, if any, steady-state characteristics. For example, control of a fermentation process will typically require the following sequence:

1. Fermentor CIP
2. Fermentor media filling
3. Fermentor sterilization
4. In-line probe calibration (e.g. pH and dissolved oxygen, DO₂)
5. Inoculation with live cells
6. Cell growth phase
7. Induction (shift from cell growth to product production)
8. Product production phase
9. Harvest

Most batch process alarms are functions of the process/step/phase. Therefore, alarms, their limits and other attributes, activation and deactivation, should be configured as a function of the batch step or phase. In addition, whenever possible, the process step or phase should be included in the alarm record tag when logging alarm events.

Some batch-step control parameters may be time varying, so automation systems need to allow for time-varying calculated control loop setpoints and alarm limits.

Think Batch Time, Rather than Calendar Time

Operators, scientists and engineers who work with batch processes tend to think of their processes in terms of relative batch time, so that Time = 0 indicates the start of the batch or batch step.

However, almost all automation systems collect, display and store process data, including alarm records, in calendar time. This causes significant inefficiency when analyzing such data, as users must constantly translate calendar times to batch-relative times to provide the appropriate context.

Pharmaceutical manufacturing professionals also often desire to analyze process data based on batch lot number. This allows them to compare one particular lot to another, facilitates the generation of batch reports and allows them to access information relating to specific abnormal situations that may have occurred during a batch. Unfortunately, many commercial automation systems do not include lot number in their process data or alarm record tags.

The challenges and nuances of batch processes are so numerous that ISA developed S-88, to define standard terminology as well as the many “states” within a typical batch process (e.g., running, holding, pausing, aborting and stopped). The majority of automation logic is not associated with the normal running of a batch process, but rather with the other possible states of a process and the transitions between them. This suggests that alarms and their attributes also can be configured as a function of the process “state.”