Rethink Batch-Manufacturing Alarm Systems

You can avoid common failings and improve performance.

By Joseph S. Alford, consultant

4 of 5 1 | 2 | 3 | 4 | 5 View on one page

Notifications aren’t alarms and, vendor software permitting, shouldn’t be configured to the alarm system. Instead, this information should be stored and displayed in a separate part of the Human Machine Interface (HMI). If this can’t be done with a particular automation system, then every effort should be made to display the information so that operators can distinguish notifications from alarms (for instance, using different colors or audio signals).

Use batch time rather than calendar time. Those 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 in analyzing the significance of an alarm.

While the value of displaying batch data in relative time has been known for decades, some vendors only recently have been providing such functionality in batch historian products. So, consider insisting upon this capability in the functional requirements for new systems and adding utilities to provide this functionality in existing systems.

Note the use of relative time in Figure 3.

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

At the start of a project’s life engineers and automation personnel clearly need to consider who’s likely to access and use alarm records and for what purposes. For instance, there’s often value in generating batch reports at the end of a run. Quality control groups may want to know about any and all product-quality-related alarms.

Other reports might highlight environmental excursions (i.e., potential violations of environmental permits) or safety incidents. Such reports can help plant personnel quickly focus on that part of plant operations they are responsible for and determine which abnormal events during a batch need to be investigated further.

So, if possible, tag alarm records with the batch lot number and alarm category/class, such as safety, environmental or product quality. If the tag can’t accommodate these details, make sure that software utilities such as dictionaries, etc., exist within the data historian to align alarm records with their appropriate lot number and category/class.

ISA’s S-88 Batch Standard. This standard was developed in the 1990s to address, in part, four basic problems that industry was encountering:

  1. lack of a universal model for batch control;
  2. difficulty in communicating batch processing requirements;
  3. obstacles in integrating solutions from different vendors; and
  4. trouble in configuring batch control solutions.

These problems led to expensive batch control systems that often didn’t meet the needs of users and were difficult to maintain.

The ISA S-88 Standard defines terms and provides a common framework for discussion of batch operations. It establishes some common models (e.g., procedural, physical and state) for understanding equipment and the sequences involved in batch operations.

One of many features of this standard is the separation of equipment logic from product recipe logic. Historically, when the code to run equipment and the code that defines a product recipe are in the same device (e.g., a PLC) the two different sets of code eventually can become indistinguishable and in some cases inseparable. So, changes to the product recipe or to process equipment can require excessive effort in software modification; documentation is then often difficult. This makes recipes resource-intensive and hard to maintain. Therefore ISA-S-88 provides a structure that separates recipes for making a product from the code specific to equipment in which the product is made. The value of this is especially apparent at batch manufacturing plants that use the same equipment to make several different products.

4 of 5 1 | 2 | 3 | 4 | 5 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments