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:
- Meet the villains of your process alarm system
- What caused the increase in alarm notifications?
- Why alarms are a double-edged sword?
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”.
No comments:
Post a Comment