Wednesday, August 19, 2015

An Alternative Approach for Viewing Data vs. Actionable Alarms

When bringing data from devices into the system, the following questions should be asked:
1. What information does the operator need in order to run the equipment?
2. How should the operator be properly alerted to abnormal situations without introducing a source of constant distraction? 

How these questions are answered will present an opportunity to rationalize alarms during the design process. This will ensure the operator is not overloaded with irrelevant information. Let’s look at an example of a pump motor at a processing plant. We want the operator to be alerted to issues pertaining to significant, temperature-related abnormalities. Any aberration in Voltage, Frequency, Speed, and Current can affect the motor, causing it to overheat. An overheated motor can be caused by a malfunctioning gear box, a drop in voltage, high frequency, high torque, and other factors, but the end result is heat. The motor temperature is detected by a PTC thermistor sensor. Motor temperature, in this example, is the only factor that should have a configured alarm, since heat is one of the main causes of permanent damage to the motor by melting the windings. So, we have identified a single critical situation (excessive motor temperature) that can be caused by a number of different factors. But the other data points can provide context and clarify the nature of the cause, or in this case identify it as auxiliary information. Data from boundaries such as Current, Frequency and other operational supplements are auxiliary information that should only be presented to the operator as supplementary information, not alarm events. When the alarm is triggered, the operator can readily discern the anomaly (temperature deviation from normal), then visualize the auxiliary information that provides context for the motor’s increase in temperature. If he does not see the relationship between the alarm and auxiliary data, he can notify the maintenance department to investigate this matter. The simple steps outlined here demonstrate a natural rationalization process that should occur for each alarm configured in the system.

Let’s outline these steps:
Step 1: Determine the end result of an anomaly Increase in the pump motor’s temperature.
A rise in temperature outside the specified range may lead to permanent damage. The Figure below shows a heating curve that identifies the point at which damage will occur depending on load and time.

Step 2: What impact does this occurrence have on my process?
Pump will shut down or output will be reduced. A pump shutdown or reduced output could impact production, for example by providing less cooling water to the process. The resultant impact to the process should determine the severity of the alarm. If this pump is the only pump for cooling the process, then a shutdown of the pump could lead to a complete plant shutdown, which would indicate the need for a critical severity alarm. If, however, this pump is one of six pumps in a set, and the process requires only three pumps for normal operation, then a low or medium severity alarm can be set. For this lower severity alarm event, the operator would have more time to respond to the occurrence.

Step 3: Identify possible causes of the anomaly
Auxiliary data helps the operator troubleshoot the causes of heat generated by the pump in question.  
It is a good practice to analyze all possible causes. Areas to investigate include the identification of data points to visualize these different conditions and their context in various scenarios. Determining which information is relevant to the operator can be extremely challenging. The knowledge for making such decisions may be shared across multiple disciplines, such as engineers, supervisors, operators and maintenance personnel. Further compounding the problem is the likelihood that the plant is in an early startup phase while these important decisions are being made. It is paramount to ensure that further validation of these decisions is confirmed and fine-tuned before they are implemented, in order to eliminate erroneous settings which may result in unnecessary noise for operators. Experience shows that failure to do this can be very costly, and even more costly to correct after the plant goes live.
                                                                                     
A guest blog post  by Rob Kambach.

Relate blog posts:

Read more: The Wonderware OEM Post and make sure to subscribe to get regular editions delivered to your inbox. For a limited time, subscribers also get a FREE white paper: “Actionable Alarming and how to achieve it in a simple manner”.