Actionable Alarming: Make Alarms & Situational Awareness Your Closest Allies To Maximize Productivity & Minimize Downtime

Download as pdf or txt
Download as pdf or txt
You are on page 1of 16

Actionable Alarming

Make Alarms & Situational Awareness Your Closest Allies


to Maximize Productivity & Minimize Downtime

by Rob Kambach, Product Manager Wonderware Next Generation Visualization,


Schneider Electric

Executive summary
Effective and actionable Alarming has recently
become one of the most examined hot spots of an
automation system demonstrating extremely high ROI
and significant reduction in avoidable mistakes.

This paper discusses contemporary approaches


to effective alarm management and introduces
pragmatic methods to dramatically reduce the
volume of inconsequential, nuisance, and fleeting
alarm notifications.

By identifying and then better managing these alarms,


operator productivity increases, operator stress and risk
of distraction is reduced, and therefore mistakes, system
downtime, and catastrophic events are minimized.
Actionable Alarming

Introduction Alarm sub-systems serve a crucial function in the daily operation of a


production or management process. In a normal mode of operation, these
systems provide operators a snapshot of the current health of the equipment
and overall process performance. However, if operators are burdened with too
many nuisance alarms, a crucial alarm or event could be missed with potentially
damaging consequences. These damages might be felt environmentally and
economically, adversely affect equipment, and potentially endanger lives.

These unmitigated incidents can cause unplanned shutdowns, production loss,


and costly damages to equipment. Additionally, operations outside normal
or safe boundaries can create health and safety hazards, and risk lives. In
summary, the consequences of unaddressed alarm notifications can be severe.

In a recent survey 52% of respondents said they do not perform an analysis


of their alarm systems to identify its strengths and deficiencies.1 It is clear that
something needs to be done to improve alarm management.

In many cases a faulty alarm design, rather than an unstable process, is the
root cause of untrustworthy and nuisance alarm notifications. The presence of
large amounts of alarm ‘noise’ in the system leads to a lack of operator trust in
the system, resulting in genuine abnormal situations being ignored or obscured
by that noise.

This paper examines effective alarm management and methods to improve


operations through a well-planned alarm system design and execution of that
design.

Content in this paper is derived from guidelines and standards found in ANSI/ISA 2, EEMUA3,
NAMUR4, API5 and IEC6. These resources offer valuable information to those interested
in alarm management, but can lack practical examples of how alarms actually work in an
operation and the consequential results. Instead of quoting the guidelines, this paper will
guide you through practical examples and demonstrate situational awareness scenarios and
contemporary alarm management methodologies.

What Caused the The continuous evolution of automated control systems from relay boards to Programmable
Logic Controllers (PLCs) to smart devices has dramatically increased the number of configured
Increase in Alarm alarms and their visual impact to a system. Consequently, today’s typical control systems now
have up to five times the number of configured alarms for each operator to manage than just a
Notifications? few decades ago.

During the evolution of control systems technologies, the automation industry began
implementing concepts which expanded in scope to become what is now called the “Internet of
Things.” An aspect of this scenario is prevalent in the manufacturing world; nearly every device
added to a plant in the past decade is “smart,” with smart drives, smart transmitters, and smart
controllers in place.

1
www.automationworld.com/alarm-management-opinions
2
ANSI/ISA-18.2-2009 Management of Alarm Systems for the Process Industries - www.isa.org/
templates/one-column.aspx?pageid=111294&productId=116626
3
EEMUA 191 - Engineering Equipment & Materials Users’ Association “Alarm Systems, a guide to
Design, Management and Procurement” - www.eemua.org/News/Better-alarms-handling.aspx

Schneider Electric White Paper Page 2


Actionable Alarming

From a business perspective, going from “analog” to “smart” makes a lot of sense since, for a
relatively small investment, things like smart drives can save up to 50 percent in energy cost.
With that, additional data can be made available to the Process Visualization: Current, Torque,
Speed, Interlocks, Energy, Deviation, Frequency, Supply Voltage, Trip Alarms, Communication
Status, and Diagnostics.

But while this “Smartness” is good, it leads to increased volume of data from devices. Bringing
more information to the attention of the operator is not inherently bad, but a significant portion is
considered “auxiliary information” rather than actionable alarm information.

New System An Alternative Approach for Viewing Data vs. Actionable Alarms
Design When bringing data from devices into the system, the following questions should be asked:

Considerations 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:

4
NAMUR - Normenarbeitsgemeinschaft für Meß- und Regeltechnik in der chemischen Industrie - NA
102:2008 – Alarm Management - www.namur.net/nc/en/recommendations-and-worksheets/current-
nena.html?tx_nena_pi1%5Bda%5D=138
5
API - American Petroleum Institute - Pipeline SCADA Alarm Management – API RP 1167. - global.ihs.
com/doc_detail.cfm?&item_s_key=00562674&input_doc_number=API RP 1167
6
IEC – International Electrotechnical Commission - IEC 62682 Ed. 1.0 b:2014 - Management of alarm
systems for the process industries - webstore.iec.ch/webstore/webstore.nsf/ArtNum_PK/50243

Schneider Electric White Paper Page 3


Actionable Alarming

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 shows a heating curve that identifies the point at
which damage will occur depending on load and time.

Motor Heating Curve


600

Full Load Amps (%)


500

400 Motor Damage


Figure 1
300
Motor Heating Curve.
200

100 Allowable Operation Area


0
0 1 2 3 4 5 6 7 8 9 10 11 12
Time (minutes)

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.

Schneider Electric White Paper Page 4


Actionable Alarming

Under normal conditions, the goal of an operator is to optimize production. However, the more
What is a system veers off target due to abnormalities or disruptions, the more the operator will be
Situational diverted from that goal.

Awareness in
Context with
Actionable Loss of Life

Alarming? Deviation
From Target No Production
Operating Explostion
Region
Off Spec Product

Figure 2
Equipment Environmental
Deviation from a target against Damage Release
Increased Cost
operations goals

Operations Optimize Keep Operations Return to Establish Bring to Minimize Losses


Goals Production Normal Normal Control Safe State

The farther a system goes off target, the more the operators will have to balance and refocus
efforts to keep the system running. This diversion detracts from the primary goal to optimize
production.

Looking across the broad spectrum of modern operations, it is common to see alarm systems
performing poorly and causing the process to run in the “yellow” zone. Additionally, operators
who have to contend with such systems are faced with a daily battle to maintain normal
operations, or even just to stay on their production targets. As a result, the production system
consistently fails to achieve optimal or potential performance, producing a direct, negative
impact on the revenue and profitability of an operation. It should be no surprise that a poorly
performing alarm system can be very costly to an organization.

Situational Awareness
Situational Awareness involves having the appropriate level of awareness of what is happening
in order to properly interpret information and events, make decisions, and take necessary
actions that will impact goals and objectives. Situational Awareness can reduce the noise and
distraction in alarming events. By using Situational Awareness design elements, the time it
takes to recognize a problem is on average 38 percent faster than traditional approaches7 to
Process Visualization screen design. In many cases, diversions from normal operation can be
recognized and mitigated, or corrected, before an alarm condition ever ensues.

7
ASM Consortium case Study, www.asmconsortium.net/Documents/HFES2005BusinessJustificationfor
HFInterfaces-v100b.pdf

Schneider Electric White Paper Page 5


Actionable Alarming

Traditional HMI
What Happened? Critical
Alarm
Tool

Impact
Grid
Process
Tool
Trends
Knowledge Operational
Figure 3 SA Graphics Operator Limits
An operator’s reaction to an What is Happening? Knowledge Alarm
Operator Boundaries
anomaly and the tools used in order
to decide which course of action to
take to appropriately respond to the
event.
Interpretation Time
Alarm Time
-40%

In traditional Supervisory Control Systems, an operator uses several tools before making a
decision. This concept is depicted on the right side of the graph, in which the operator received
notification of a temperature alarm on a pump in an alarm data grid. Using the alarm data grid,
he located the graphic representing the pump. Note that in this example the operator only acted
the moment the event became an alarm, so his response was purely reactive.

Next the operator identified the process around the pump in order to understand the alarm
limits or operational limits. The quality of this analysis is usually dependent on the operator’s
knowledge and years of experience, or comes from standard operating procedures.

Another tool the operator used was historical trends that provided historical information on the
pump load. For example, he investigated the duration of this behavior. So far, the operator was
in three different sections of the control system to determine the nature of the alarm.

Situational awareness with actionable alarming


Now let’s take a look at the right side of the graph and analyze the difference using a situational
awareness approach with actionable alarming.

This approach is different in the sense that the data is always present in
Figure 4 context. This symbol unifies the following information: (1) the position of
A situational awareness graphic for the signal within the last five minutes, and (2) the direction the signal is
a flow controller which manages the now heading, as identified by the arrow. In this example, the downward
pump speed. direction indicates an abnormal rate of change.

The horizontal grey line represents the setpoint, and the light grey rectangle represents the
optimal range. For this system, we can immediately see the marker is about to go below the
optimal range, and if this signal keeps going down it will trigger an alarm. Knowing what might
occur, operators can take corrective action before an alarm is activated, all because this
information was shown in context.

Schneider Electric White Paper Page 6


Actionable Alarming

Another useful feature of situational awareness presented in this example is that alarm settings,
operational limits, direction of data, and historical information are all shown in one symbol. In
the traditional approach, the operator had to visit three screens to obtain the same data, and
also had to know or seek information on operational limits and alarm settings.

Introducing As part of the rationalization process, one must determine the impact that an alarm has on
operations and assign it a “severity” designation. It is strongly recommended that this severity
Severities to designation be made by someone with considerable knowledge of the process. Process

Categorize Impact
engineers and operators themselves should be consulted to eliminate doubt from the analysis of
alarm impact.

Figure 5
Example of severities applied to
alarms to categorize priority ranges.
It is advised to not use more than
four types of severities for alarm
conditions.

Severity Safety Risk Economic Risk Environmental Risk


Table 1
Critical > 0.1 $100,000 > 0.1
Attaching economic and risk values
to severities is important, since High > 0.01 $10,000 > 0.01
these values can have multiple Medium > 0.001 $1,000 > 0.001
impacts on the operation. Low > 0.001 $1,000 > 0.001

While these numbers might differ by plant, they affect operations in their own way.

Severity Response Time Impact


Critical < 5 minutes Total loss
Table 2
The risk and response times of High < 30 minutes Loss of an area
operations. Medium < 60 minutes Loss of equipment, loss of production
Low < 120 minutes Loss of equipment without loss of production

Applying these severities makes it easy for operators to know which type of response is
required for each condition. The consequences are also clear for each given alarm severity.
Properly using Situational Awareness Library symbols with Situational Awareness techniques
ensures nothing else in the system uses these colors, so operators will not be confused during
an alarm event.

A good rule-of-thumb is to configure the severity distribution of alarms as: 79 percent = Low, 15
percent = Medium, 5 percent = High, and 1 percent = Critical. This general distribution may vary
considerably depending on the industry and type of product or service delivered.

8
Severity/priority impacts are explained in the EEMUA 191 and API RP 1167.

Schneider Electric White Paper Page 7


Actionable Alarming

Another compelling reason to adopt this approach is that it does not interfere with alarm priority
usage. For example, if 100 represents maintenance and 200 represents production, it is still
possible to prioritize and route alarms to proper consumers. Implementing these four severity
types determines how a user group should respond to an alarm.

In accordance with best practices for Situational Awareness design, as shown in the Image
column of Figure 5, the graphical alarm severity representation uses “triple information coding”
to exploit shape, color, and a number to represent the information to the user at run time. This
makes it possible even for someone with impaired color perception to interpret the condition
correctly. In well-designed systems, according to the best practices encouraged by Situational
Awareness methods, the only bright colors that appear in Process Visualization Systems are
those used to represent alarm conditions. A powerful additional visual cue can be presented to
the operator in the form of an alarm border animation, which provides a conspicuous graphical
indication that particular part of the system is in an alarm state.

Using an alarm border focuses the attention of the operator directly


on the graphic itself and points out the critical area in a very clear
representation. The alarm border can also blink on and off when in an
Figure 6
unacknowledged state to create even more visual impact.
The alarm border and icon indicate
a severity 4 alarm on a level
controller. Alarm borders should be able to display in different colors to indicate the
proper severity. The indication icon uses color, shape, and number to
reflect the current state of the alarm, for example if an alarm is silenced
or disabled.

Figure 7
Examples of indication icons.

Critical High Medium Low Disabled Silenced

How Alarm A common practice of Process Visualization is to embed an alarm banner on each screen. The
intention is to always give operators high visibility of active alarms, regardless of the content
Aggregation Aids on the current screen. This design has its limitations, since there are typically more standing

in the Detection
alarms in the system than can be viewed in the alarm banner, which can result in the operations
team becoming desensitized to its content. What the operator needs is a system wide KPI
view of the most urgent alarms, and access to a graphic that conveys the proper situational
of Alarms awareness to take appropriate action.

Figure 8
A high level overview graphic that
includes KPI indicators for Reactor
R33.

Schneider Electric White Paper Page 8


Actionable Alarming

The Alarm ‘badge’ in the upper right shows four active alarms, with severity levels 2, 3, and 4.
The severity 2 and 3 alarms are active but acknowledged, meaning the operator is aware of
them. The upper left corner represents a blinking severity 4 indicator, the highest severity
level for an unacknowledged alarm as represented by its alarm border and icon. This prompts
the operator to drill down into the system to assess the situation, without needing to access a
detailed alarm banner for information.

In Figure 9, an operator can view details of the alarm event that was brought to his attention,
and then take the appropriate corrective action.

Figure 9
The detailed display of Reactor 33.

How Operations Alarm analysis software can significantly aid in implementing the rationalization process
on a running system. Major components of these analysis tools include: 1) a dashboard to
Can Use Alarm present alarm metrics and indicate progress towards these metrics, 2) reporting and analyses
capabilities to examine historical alarms, and 3) a predictive component to identify relationships
Analysis to between alarms.
Optimize an
Performance metrics
Existing System Performance metrics can be used to analyze the system. A good guideline to use is EEMUA
191, which advises that a system should not exceed 144 alarms per 24 hour period per
operator, or one alarm every 10 minutes, though these numbers can vary by production
process and industry.

One approach to optimization is to review the current situation, establish a baseline for that
situation by running this analysis, and accordingly define a plan for improvement. For example, if
the measured rate is 500 alarms per day, 200 alarms per day might be a good target goal to set
for starters in the first two months.

Figure 10 on the next page represents an alarm analysis software dashboard which displays
key metrics that help determine how a system is trending towards goals. Configurable Alarm
widgets, shown in the figure, clearly indicate how the system is trending towards the set metrics
and goals.

Schneider Electric White Paper Page 9


Actionable Alarming

Figure 10
Configurable Alarm
widgets clearly indicate how the
system is trending towards the set
metrics and goals.

Types of analysis reports


After a dashboard is set up to display overall system metrics, the alarm analysis tool can be
configured to run an analysis on designated patterns of alarm activity and generate charts and
reports for detailed examination.

Alarm activities are often categorized by alarm type:

•• Frequent Alarms occur most frequently.


•• Standing Alarms remain in an active state for a prolonged duration.
•• Fleeting (Chattering) Alarms remain in an active state for a short period of time.

A good Alarm analysis tool should analyze and categorize these alarms and present them in
reports to the user.

Total alarm analysis


Figure 11 on the next page is a total alarm report which shows metrics previously discussed,
including: severity distribution of alarms, alarm load over time, and acknowledgment rates. The
load on operators can be assessed based on the total alarm rates and operator response to
alarms. This report should be configured to present data by hour, day, week, month, and so
forth. Severity distribution is also usually included as a metric. Critical alarms should not exceed
1 percent of the total, High 5 percent, Medium 15 percent, and Low 79 percent. Alarms can
be properly categorized using these guidelines as a metric. Erroneously categorized alarms
can cause operators to react incorrectly to a lower level alarm, thereby distracting them from
appropriately responding to a higher level alarm, when it is most necessary.

Schneider Electric White Paper Page 10


Actionable Alarming

Figure 11
Total alarm report

Frequent Alarm Analysis


Frequent Alarm reports provide information on the most frequently occurring alarms, including
“bad actor” faulty alarms. Eliminating the top 10 or 20 frequent alarms often reduces the
alarm load significantly. When confronted with frequent alarm situations, it is valuable to
examine if alarm limits are set properly. This report will also tell how many times an operator
“Acknowledged” the particular bad actor, giving an indication of operator responsiveness. A
lower “Ack” rate could also indicate there are too many alarms for the operator to address.

Figure 12
Frequent Alarm report

Standing Alarm Analysis


Standing Alarm reports provide information on alarms that have remained in an active state for
a very long duration. These reports are often indicative of conditions caused by faulty alarm
limits, or systems that are either offline or were decommissioned, though the alarms were never
deactivated. A thorough analysis of the cause will often resolve many of these alarm issues.
Standing alarms often have high Ack rates since they are always present.

Figure 13
Standing Alarm report

Schneider Electric White Paper Page 11


Actionable Alarming

Fleeting Alarms Analysis


Fleeting Alarms reports provide information on alarms that appear for only a short duration of
time, for example 15 seconds, which does not give an operator enough time for an appropriate
response. The Ack rates of these fleeting alarms are usually low.

Figure 14
Fleeting Alarms report

Since these alarms can be the cause of a lot of noise in the system, the report can include
criteria on alarm duration (Chatter Time) to detect fleeting alarms. One method for eliminating
this category of alarms is to implement “bounce” and “de-bounce” timers set to exceed the
length of chatter time. It should be understood, however, that these reports should be empty;
chattering alarms should not exist.

Another useful type of report, the “consequential analysis” report, shows relationships between
alarms. This report type reveals whether obscure cause-and-effect relationships exist among
process areas and resultant alarms.

These various reports are identified and described in the EEMUA 191 standard.

We have reviewed alarm design considerations, how situational awareness and alarming are
Applying interrelated, that alarm severity requirements should be addressed during the design process
Rationalization instead of as an afterthought, and we have demonstrated the importance of a carefully considered
alarm design. In addition, we have examined the importance of alarm aggregation and the
methods various facets of alarm analysis such as alarm types, their characteristics, and examples of alarm
reporting. These are the foundation to understanding the process of analyzing alarms.

One of the final steps in this entire process is to improve the alarm design of the current system
in order to reduce the alarm load on operations and enable them to focus on the most critical
alarms and production optimization.

To determine which areas of the system require design improvements, individual alarms can
be examined. There might be several reasons why an alarm is no longer valid or is improperly
configured. A path for improving the design can be implemented using several techniques,
because at this point it is clear which pain points exist in the process.
The system should be designed to conceal many of the various types of alarms considered
to be noise. A lot of noise in a running system could potentially be caused by equipment that
is either not in production or is defective. For optimal alarm system management, the system
designer needs to understand the types of alarm states that can be attained by alarms, and how
these states are attained.

Schneider Electric White Paper Page 12


Actionable Alarming

An Alarm Acked. Was in Alarm. Disabled Shelved Silenced/


Un-Acked Returned to or Inhibited (Operator) Suppressed
Flashing Normal (Engineering) (Operator,
Figure 15 Un-Acked. Plant State)

Various alarm states. Transactions


Yes Yes Yes Yes Yes Logged
In alarm
Yes, tab
Yes Yes Yes No summary
shelved
display
Indicated in
Yes Yes Yes Yes Yes
alarm border
Aggregated/
Yes Yes Yes Yes Yes
counted

•• Enabled is the normal state of an alarm.


•• Disabled and Inhibited alarm states have similar meanings and are not typical for an
operator to see, but are typical for maintenance or engineering personnel. These states
are used for a device that is defective or not in operation.
•• Shelved is an alarm state attained when an alarm is “snoozed” for a period of time.
•• Silence / Suppressed is an alarm state usually attained after the execution of logic in the
PLC; it can reflect the production state of a particular area, unit or piece of equipment.
This state is often coupled with a plant state; for example: “In Production,” “Cleaning,”
“Filling,” “Maintenance,” and so on.

Understanding these alarm states helps the system designer rationalize and manage the
number of alarms within an operation. Since we understand how to use alarm analysis to
improve an alarm system design, managing alarms that have attained the aforementioned
states is the final step in making the alarm system more robust. The implementation of this
knowledge in practice will result in alarm noise reduction, by only showing alarms that are
currently important to the operation.

While any of these techniques can be used to reduce alarm loads, a good understanding of
the current situation and a design improvement plan should be in order. The plan might include
setting a goal as an organization; for example, to eliminate the top five bad actors from the
alarm analysis report each week. By implementing and refining the changes in this example,
the root cause found in three lists, multiplied by five bad actors, would result in tracking down 15
faulty alarms per week. This appears to be an achievable goal. After 10 weeks, 150 bad actors
that most likely are responsible for 80 percent of the noise would be eliminated.

The ISA/ANSI 18.2 standard refers to an “alarm life cycle,” and this is an important concept. The
The Approach management of alarms, design, runtime, and analysis can be an enormous task. This process
to Maintaining a is also ongoing; not a task that is executed only one time. Though this ongoing process can
appear tedious, ultimately it will result in more stable operations with higher throughput. What’s
Well-functioning more, operators can be freed to focus on other more productive activities.

Alarm System When the concepts introduced in this paper are executed in conjunction with effective
Situational Awareness practices, the result is a solid supervisory control platform that enables
the optimization of industrial operations.

Schneider Electric White Paper Page 13


Actionable Alarming

Activity begins with a new or old system and an analysis of the current situation, implementation
of the system, and alarm system philosophy. These activities are ongoing activities; monthly/
weekly activities are required to act upon report data, and to execute improvement plans such
as eliminating bad actors, implementing state-based alarm suppression, and/or adjusting alarm
limit settings.

Annual Monthly
Analysis of current situation Alarm Rationalization
Operator Alarm Active
Input Advisor When

Alarm Philosophy Alarm Design


Review Why Operational Plant State
Alarms Limits
Document Shelving
Figure 16
Proposed high level annual and
monthly operations activity plans.
Wonderware
Implementation
Standing
Software Suppression Eliminate Fleeting
Implement Noise Frequent
Bad Actors

Alarm Performance Assessment


Alarm Determine Fleeing
Adviser
Determine Frequent

Determine Standing

Determine Bad Actors

Conclusion The demands upon modern systems require a new approach to solving daily problems. At a
time when many organizations are confronted by challenges of an aging workforce and high
staff turnover, the systems we create need to be more stable and have the ability to present
data in context, as well as deliver actionable alarming. Adoption of some of the fundamental
approaches outlined in this paper can help many organizations improve their overall
performance. Actionable alarming is one of the areas in which many implementations fail and
systems that are delivered do not perform adequately. Improvements and investments in this
area have a high ROI, since investment costs are relatively low and the return rate is high in
gained productivity.

Schneider Electric White Paper Page 14


Actionable Alarming

Case Study by Schneider Electric


Salt River Project (SRP) is the third largest U.S. public power utility with 6,500 MW generated
and supplied to 900,000 customers; having an annual revenue of $2.5B USD.

The existing situation at the plant is characterized by the following comment:

“We were getting alarm “We were getting alarm horns all the time; at startup, shutdown and day-to-day operation. In
horns all the time; at one 18-hour period, operators were confronted with 5000 alarms, every one of which required
startup, shutdown and day- intervention of some sort, and 98 percent were designated top priority. The plant had to
to-day operation. In one designate an operator just for alarm management,” said Ron Bewsey, SRP I&E Supervisor.
18-hour period, operators
were confronted with 5000 After applying the techniques described in this white paper, these were the reported results at
the following facilities:
alarms, every one of which
required intervention of
Achievements at Santan:
some sort, and 98 percent
•• Startup time and effort is reduced from having 2 operators up to 4 hours, down to
were designated top 1 operator less than 2 hours.
priority. The plant had to
designate an operator just •• 40% of configured alarms and resulting nuisance alarms were identified and deleted.
for alarm management.”
Achievements at Navajo:
•• Initial priority distribution (Priority 1: 98%, Priorities 2 through 4: 2%) is updated to a final
priority distribution (Priority 1: 11%, Priority 2: 14%, Priority 3: 75%, Priority 4: Information
Only, Priority 5: Non-critical bad I/O).
•• 44% of the configured alarms and resulting nuisance alarms were identified and deleted.

The benefit of improving an alarm management system is that this process can be started at
any point during the lifecycle of a system.

All the methods and features in this white paper are delivered within the latest releases of
Wonderware® System Platform and Wonderware Alarm Adviser.

Assess Start here

Alarm
Figure 17 Optimize Management Design Start here
Alarm Management Lifecycle. Lifecycle

Start here

Implement Start here

Schneider Electric White Paper Page 15


Actionable Alarming

Further Wonderware System Platform, InTouch, and Alarm Adviser


All of the techniques described in this document are available out-of-the-box in a very easy to
Information use product set. These methodologies can be integrated into existing systems or used on the
design of new systems. Through the use of these techniques and Wonderware supervisory
control software, any business can experience world class industrial system performance with
minimal cost and fast return on investment.

For further information about these products, please visit: www.wonderware.com

Wonderware Alarm Adviser


Wonderware Alarm Adviser is web-based alarm analysis software that helps you discover
nuisance alarms in the process system through interactive visual analysis. Based on industry
recommended standard alarm management practices, Alarm Adviser provides a dashboard for
instant diagnosis of alarms, causes and consequences. It provides a single means of identifying
frequent, standing, fleeting and consequential alarms, which can help analyze plant upsets and
optimize system performance.

Wonderware System Platform


Wonderware System Platform surpasses all other platforms in engineering simplicity,
operational agility and information empowerment. It helps customers secure their future, protect
the operational integrity of their plants, enhance the operational insight of their people and
enables them to adapt easily and affordably to change.

Situational Awareness White Paper


“The Next Leap in Industrial Human Machine Interface Design.”

About the author


Rob Kambach is the Product Manager for Schneider Electric’s Wonderware Operations
Management Next Generation Visualization product. He has over 15 years of experience working
in the industrial automation industry, and has authored several publications on various industrial
control processes.

Schneider Electric Software


26561 Rancho Pkwy South, Lake Forest, CA 92630 Telephone: +1 (949) 727-3200 Fax: +1 (949) 727-3270 software.schneider-electric.com
© 2015 Schneider Electric Software, LLC. All rights reserved.

PN WW-4247 Rel. 07/15

Schneider Electric White Paper Page 16

You might also like