JAN-FEB 2019

Issue link:

Contents of this Issue


Page 32 of 55

INTECH JANUARY/FEBRUARY 2019 33 AUTOMATION IT discussed more extensively in TR6. Dynamic cause analysis and guid- ance: State-based alarming can often provide appropriate alarms at the right times and help avoid nuisance alarms. But there are occasions when the cus- tomary level of operator guidance (pro- vided by typical human-machine inter- face systems) can be inadequate. TR4 provides an overview of how an extra layer of logic can be added to the alarm system to dynamically analyze abnor- mal situations and dynamically provide recommendations to the operator on how best to respond. Alarm routing: Sending alarms to the right person can sometimes be difficult in large or complex plants. Simply send- ing alarms to a central control room is not always effective, as operators could be distributed through the plant, roam on foot, or even be located offsite. TR4 provides guidance and the pros and cons of several alarm routing techniques. Use of alerts: ISA-18.2 defines alerts as notifications that share some of the char- acteristics of alarms but do not meet all of the criteria of alarms (e.g., may not rep- resent abnormal situations or may not require a timely response). TR4 provides guidance on nonalarm notifications, as it is important to understand their relation to, and distinction from, alarms. Application to alarm management life- cycle work processes: TR4 also discusses how the use of enhanced and advanced alarming methods fits within the vari - ous alarm management life-cycle work processes. If used, enhanced/advanced alarm methods have to be integrated throughout the alarm management life cycle—including testing/training, man- agement of change, monitoring, and audit—to preserve the investment in the alarm system and to assure continued alarm system integrity. TR6: Batch and discrete processes Batch processes and discrete manufac- turing present several unique challenges when it comes to implementing effective alarms. TR6 provides guidance for how to design and implement effective alarms for batch and discrete processes. The special recommended alarm practices for many batch and discrete processes become apparent when un- derstanding how most batch processes differ from more traditional continuous processes. Most batch processes consist of a sequence of time-varying steps, of- ten representing a mixture of manual and automated operations. The existence of multiple time-varying steps (and phases), coupled with the need to start up, shut down, and occasionally to stop, pause, hold, and sometimes even abort the pro- cess, requires a different approach for alarming. Batch processes often consist of several different unit operations, each with its own equipment. The use of pack- aged equipment with batch processes is also very common. Batch processes often have special re quirements for logging and recordkeep- ing. In addition to typical process log- ging, alarm records often need additional de tails (e.g., lot number) to facilitate alarm record sorting, undertake alarm analysis, and prepare batch lot reports. When rationalizing and designing alarms for a batch process, alarm settings often need to be dynamic, so the control system can automatically change alarm attributes and which alarms are active, based on the current step of the batch process. Dynamically changing alarm set- tings can be done based on the current step, a recipe, or even time elapsed into a batch step. An example based on the sys- tem state/step is shown in table 1. Alarm routing is commonly used in batch processes, since process operators may be out on the plant floor and not in the central control room. For complex pro- cesses, a technical services group—which may not even be located in the same build- ing—may also need to receive alarms. TR6 also discusses how the ISA-88 batch control standards can be helpful when implementing alarms in batch-based systems. ISA-88 has both a procedural (recipe-based) model and an equipment model, which together, provide numer- ous software objects to which alarms can be attached and dynamically modified. In particular, TR6 provides several examples of how alarms can be implemented in the equipment model, and then how the pro- cedural model can be used to dynamically change alarm attributes. How alarms are tagged, logged, and presented to an operator presents some interesting challenges with respect to batch processes. In many industries, there is a need to also associate lot num- bers, time since start of batch, recipe name, and other attributes with alarm records. This can be challenging to do in some control systems. Including auto- mated linking support in the alarm sys- tem, such as attaching such data directly to the alarm records when they are cre- ated, can greatly reduce the effort to find, for example, all "product quality" classi- fied alarms for a particular process step in a particular batch. Also, special alarm classes may need to be configured so alarms can be sorted and/or grouped in various ways as needed. Alarm management nuances exist for discrete processes as well. For example, it is usually not practical to alarm ev- ery defective widget when hundreds or thousands of widgets per hour are being manufactured. Therefore, for discrete processes, alarms are often generated as the result of a statistical analysis of large numbers of samples (e.g., viewing thousands of widgets manufactured on System state Temperature controllers TIT1 low-temp alarm TIT1 high-temp alarm OFFLINE Manual mode suppressed by design suppressed by design Initial tank warm-up (System startup) Ramp-up to 70ºC suppressed by design suppressed by design Normal at 70ºC Hold at 70ºC TIT1 < 65ºC TIT1 > 75ºC Normal-to-sani Temperature ramp-up Ramp-up 70 to 85ºC TIT1 < 65ºC suppressed by design Sani at 85ºC Hold at 85ºC TIT1 < 80ºC TIT1 > 95ºC Sani-to-normal Temperature ramp down Ramp-down 85 to 70ºC TIT1 < 65ºC suppressed by design Table 1. Example batch system that uses state-based alarming (Hot purified water system with nightly hot sanitization cycle)

Articles in this issue

Archives of this issue

view archives of InTech - JAN-FEB 2019