Upload
schneider-electric
View
661
Download
1
Embed Size (px)
Citation preview
Make the most of your energySM
Smart Alarming Management Part of an Advanced DMS
Summary
Executive Summary .................................................................................... p 1
Introduction ................................................................................................ p 2
Smart Alarming Management ...................................................................... p 4
Schneider Electric’s ADMS Smart Alarming infrastructure ........................... p 5
Graphical User Interface ............................................................................. p 8
Smart Alarming features ............................................................................. p 10
Logging and storage: Historian System ....................................................... p 15
Conclusion .................................................................................................. p 16
Executive summary
Smart Alarming Management
White paper | 01
An electric grid alarming management system that works with real-time data is
vital for optimizing network performance and safety. This system also must have
the ability to finely tune alarms, to assure reliable event and condition notifications
without overloading control room operators and reducing alarming effectiveness.
Schneider Electric’s Smart Alarming Management solution works seamlessly with
the Schneider Electric Advanced DMS solution to put real-time data to work in the
most effective and efficient manner. The robustness of this solution is due to its
application to both database and system alarms. Configurable tools enable fast
and reliable identification of event severity and specific filtering, prioritization and
suppression. This approach assures that operator screens communicate what
is needed, when needed. Displays provide comprehensive summaries of alarm
status and actions performed that add to efficiency.
In particular, the Schneider Electric solution supports alarming management for
defined areas of responsibility. Focusing on alarm capabilities at the AOR level
optimizes both control and security for the network as a whole.
Smart Alarming management makes the most of the utility’s investment in its
real-time information infrastructure. Together, they provide vital and relevant
network information that enables operators to respond promptly and effectively to
changing network conditions.
Introduction
Smart Alarming Management
White paper | 02
Alarm management is a key element in the day-to-day operations of an
electric utility. An Advanced Distribution Management System (ADMS) system
automates and controls a very large number of functions in transmission or
distribution operations; inefficient alarming detected and/or issued by the ADMS
can lead to catastrophic damage to the electric grid — along with serious
injuries and risks to personal safety.
It is vital, then, that an Alarm Management system:
• Speed response to critical and uncommon events
• Filter nuisance alarms and take automatic actions
• Decrease errors and waste
• Minimize time spent troubleshooting grid problems
• Automatically generate reports
• Allows operators/dispatchers to focus on meaningful alarms
Schneider Electric’s Smart Alarming Management solution for ADMS speeds
operator response, reduces errors and ensures the right function is executed
at the right time. This document provides a summary of the key characteristics
and components of this solution.
Smart Alarming Management
Smart Alarming Management
White paper | 04
Smart Alarming Management
An intelligent alarming sub-system — such as
Schneider Electric’s InstAlarm application — is
critical to responsive SCADA operations. For
example, InstAlarm offers the advanced capabilities
of both Alarm Disturbance Mode and Alarm
Suppression. With Alarm Disturbance Mode, alarms
can be configured so that lower priority alarms
are suspended during peak alarm periods. The
configurable Alarm Suppression function suppresses
alarms in a hierarchical manner to prevent large
numbers of alarms from cluttering an operator’s
display when they are triggered as the result of
a single device going into alarm. Control Initiated
Suppression prevents similar alarm aggregation due
to operator-initiated commands.
The InstAlarm application is a specific module of the
OASyS DNA SCADA Realtime services and provides
an API to insert ‘custom’ alarms. This structure allows
extended applications — such as Schneider Electric’s
SimSuite Pipeline, Distribution Management System
and Responder Outage Management System, or
third-party applications, to generate alarms with the
same or similar information as a RealTime Database.
This design enables utilization of third-party tools
with Schneider Electric’s secure and reliable ADMS
infrastructure.
Smart Alarming Management
Alarm TypesInstAlarm manages both database and system
alarms. Database alarms signal an abnormal status in
the telemetered values. System alarms include those
caused by an operator’s failed actions; devices such
as printers; low space in hard drives; problems with
servers and workstations; and other situations. Of
course, system alarms also include those announced
by Schneider Electric’s ADMS functions such as
Load Flow, State Estimation and Performance Indices
when there are overloaded elements or elements that
are close to or at their maximum allowed temperature
limits.
For telemetered numeric point types such as analog
measurements and rate accumulators, high- and low-
alarm limit checking can be enabled or disabled. For
each numeric point, a high-alarm limit, a low-alarm
limit and an alarm deadband value can be specified.
A high/low alarm is declared when a point value
becomes greater than the high alarm limit or less than
the low alarm limit.
For a return-to-normal condition, the alarm limit is
modified by the deadband value. If the point is in
the high-alarm state, a return-to-normal condition is
declared when the value becomes less than or equal
to the high limit minus the deadband. If the point is
in the low-alarm state, a return-to-normal condition
is declared when the value becomes greater than or
equal to the low limit plus the deadband.
The system administrator can define up to four pairs
of High/Low alarm limits. Other alarm conditions for
numeric point types are:
• Instrument Failure alarm limits (reasonability limits)
• Rate of Change (ROC) alarms
• Creep Detection alarm - declared when a point
value becomes greater than the initial setpoint value
plus the creep value, or when it becomes less than
the initial setpoint value minus the creep value
• Flat alarm - declared when a point value does not
change within a specified time period (time-out)
• High/Low Instrument Fail alarms - declared when
the input value at the remote terminal unit (RTU) is
outside of the field instrument’s measurable range
• ADC (Analog to Digital Conversion) monitoring
The operator can independently enable/disable each
kind of alarm, but it should be noted that each alarm’s
annunciation is independent only on a point basis.
For telemetered discrete point types such as two-
state, four-state or multi-state digital inputs, each
individual state can be declared as a normal or
abnormal status. OASyS DNA RealTime service
declares an alarm condition for status points if there
is a telemetered change to any state that is not the
result of an issued command. Changes to normal
states will generate a ‘Return-to-Normal’ alarm
message.
The host computer can be asked to check for
command failures issued to any device capable of
receiving digital commands or analog setpoints. If
command failure checking is enabled by the system
administrator and a commanded point does not
change to the commanded state before the time-out
period expires — or, simply, if the command request
is invalid or it doesn’t receive a proper response from
the RTU — a command failure alarm is declared.
White paper | 05
Schneider Electric’s ADMS Smart Alarming infrastructure
Smart Alarming Management
White paper | 06
When communication with an RTU fails or is restored,
RealTime service declares an alarm condition.
A communication failure is declared only after a
certain number of communication retries have been
attempted. The retry limit is specified on a ‘per
communication line’ basis. On the first successful
communication after a failure, the system declares a
‘communication restored’ condition. In the case of a
‘no reply’ RTU condition, a separate time-out value
might have been defined to prevent the occurrence of
nuisance alarms. After the number of identified retry
attempts, the RTU is marked as ‘no reply’ and the
event is logged; however, no alarm is generated until
the time-out value specified for the RTU has expired.
Alarm life cycleFigure 1 shows the life cycle of an alarm generated
for the abnormal conditions described in the previous
section.
Alarm severityFor each point in alarm, the user can configure the
level of severity, or priority. This value not only affects
how the alarms are sorted in the Alarm Summary list
but also dictates other characteristics such as:
• Color code of the alarm indicator
• Optional audible tone, message or sound
An example of color coding, which is fully
configurable, is shown in Figure 2.
Change to abnormal condition
Change to normal condition
Change to normal condition
Operator acknowledgement
Operator acknowledgement
Remove Alarm
Unacknowledged and ActiveAlarm – Blinking ON
Abnormal Condition
Event is stored in Historian system
Unacknowledged and inactiveAlarm – Blinking ON
Acknowledged and ActiveAlarm – Blinking OFF
Sustain COS alarm
Yes
No
Figure 1. Life cycle of database or system alarm under InstAlarm management.
Figure 2. The user configures the color of alarms to provide quick identification of the severity of the alarm.
Severity Level
Color
Critical Magenta
High Red
Major Orange
Medium Yellow
Low Green
Minor Cyan
Smart Alarming Management
White paper | 07
Configurable alarm messagesOASyS DNA infrastructure provides the system
administrator the ability to customize Messages
for the more common system alarms. This feature
improves the system customization capabilities.
Cleared alarmsBecause of the high number of alarms presented on
operator screens, some utilities appreciate having
an Acknowledge and Clear feature added to the
alarm summary page. This two-step functionality
allows the operator to clear alarms from the display
so attention can be focused on new alarms coming
in. The Acknowledge function of this feature will stop
the alarm from flashing and will inhibit the associated
.wav file (sound) annunciation; the Clear function will
remove the acknowledged alarm from the viewable
summary. The Alarm Summary display lists all cleared
alarms, allowing the operator to select a previously
cleared alarm for recovery.
Integration of services within ADMS infrastructureThe InstAlarm alarm management system allows
extended applications that share the OASyS
DNA alarm repository to take advantage of the
functionalities described above. Figure 3 shows how
Schneider Electric’s DMS services and user interface
share alarms with the SCADA Realtime Services.
DM
S R
T (A
pplic
atio
n se
rvic
e)O
ASyS
DN
ARe
altim
eN
etw
ork
Mod
elD
B
Net
wor
kM
odel
Mgm
t
Calc
ulat
ion
Engi
ne
CoreFunctionService
NetworkDynamics
Service
ReportAlarms/Events
Omnicomm(polling engine)
ReportAlarms/Events
ArchiveAlarms/Events
RTDB
Events, ...
ReportAlarms/Events
DMD ReportAlarms/EventsAcknowledge
Alarms
Retrieve Alarms/Events
Retrieve ArchivedAlarms/Events
MS
SQL
Serv
er
ModelTopology
Service
CalculationEngine
Figure 3. SCADA/DMS common alarm repository.
Smart Alarming Management
Schneider Electric’s ADMS User Interface (HMI)
presents alarm messages in the Alarm Summary
display, an ordered list in which both system and
database alarms are sorted first by priority and then
chronologically so that the newest, highest priority
alarms top the list. The display, an example of which
is shown in Figure 4, includes the alarm date, time,
mnemonic code, point description and logging text.
All Alarm Summary displays are filtered by the user’s
area of responsibility and can be further filtered by
alarm category and the disturbance mode threshold.
Alarm summary displays are dynamic; the number
of display pages varies from a single page, up to
as many as required to display all of the entries.
Sufficient buffer space is provided to handle the
number of alarms possible in worst-case system
operation, and in no case are alarms lost due to
overflow.
Filtering alarmsThe default Filters panel on the Alarm Summary
allows the user to filter the display to show:
• only the points in alarm
• only the points not in alarm
• only acknowledged alarms
• only unacknowledged alarms
• alarm filter by Remote
• alarm filter by Category
The Filters panel on the Alarm Summary can be
configured to add filters as needed by the user’s
operation.
White paper | 08
Figure 4. Alarm Summary screen.
Graphical User Interface
Smart Alarming Management
White paper | 09
Newest Priority AlarmsThe Newest Priority Alarms display, typically located at the bottom of the
dispatcher desktop, lists only the unacknowledged alarms or events generated on
the system, with the latest alarm listed at the top of the first page. Operators can
acknowledge alarms directly from this window.
If there are multiple alarms listed, the most severe are listed first. If there are
multiple alarms of the same severity level, those alarms are listed in the order
received. Three additional icons are present on the Newest Priority Alarms display,
for:
• Silencing alarms
• Showing Alarm Summary
• Changing the Disturbance mode
When an operator silences alarms in a specific workstation, current alarm
announcement is temporary turned off in that console until a new alarm is
declared. Alarm announcement in other network consoles is not affected.
Silencing an alarm does not constitute alarm acknowledgment.
ActionsThe Alarm Summary display enables the operators to:
• Acknowledge individual alarms
• Access history of alarms, or Event Summary
• Acknowledge all alarms listed in the summary
• Print the summary
• Export the summary to a Microsoft® Excel®-format file
All alarms must be acknowledged. To do this, an operator with sufficient authority
can activate the row head button of the Alarm Summary, or alarms can be
acknowledged one page at a time. When an alarm is acknowledged, it stops
flashing.
Smart Alarming Management
White paper | 010
Smart Alarming features
Area of Responsibility (AOR)Only the alarms for devices that are within the
operator’s area of responsibility, as assigned by the
system administrator, are shown on the system alarm
and station alarm summaries; alarms that are not in
the operator’s area of responsibility are filtered out.
If system configuration allows the operator to select
another area or areas for control and/or viewing of the
database summaries and displays, then the operator
will have access to the Alarm Summary for that area.
• If an area is not identified for control by an operator,
the operator is not able to view and acknowledge
alarms for that area, even if the area is selected for
viewing.
• If an area is selected for control by an operator,
the operator will be able to view and acknowledge
alarms for that area, even if the area is not selected
for viewing.
• Changing the control area is the only way to affect
Alarm Summary access.
Establishing AORs is an effective way to restrict
supervisory control, data entry, tag placement and
alarm routing. Assignment of AOR can be restricted
by console and by user, to prevent assignment of
AORs by anyone outside of the control room. Multiple
users can have the same AOR assigned. In addition
to user-specified AORs, there is an additional AOR
named Uncovered AORs. Users or consoles that
have this AOR assigned to them will receive alarms
for all uncovered AORs.
User logout from the DMS system is prevented when
such action leaves one or more AORs unmonitored
or when there is an uncovered AOR. Dialog will notify
the user that this action leaves one or more AORs
uncovered, and the complete list of AORs in question
is provided. In case of console failure, an alarm is
generated enabling other users to monitor uncovered
AORs.
Non-covered alarmsWhere needed, it is possible to designate a workstation to receive non-covered alarms — those from an AOR
that is not assigned to an operator, or, in distributed projects, between peer, master, or sub-master systems.
Besides user specified AORs, there is also one additional special AOR called Uncovered AORs. Users or
consoles that have this AOR assigned will receive alarms for all uncovered AORs.
White paper | 11
Smart Alarming Management
Data quality flagsData acquisition processing includes data quality flags associated with each
numeric and discrete point, both telemetered and calculated. These data quality
flags include:
• Alarm Inhibited – If a point is marked as alarm inhibited, any change in state or
value will not result in the generation of an alarm.
• Event Inhibited – If a point is marked as event inhibited, any change in state or
value will update the database but will not result in the generation of an event
message or an alarm message.
Even if a point has been alarm or event inhibited, the abnormal state flag will
remain visible on all the displays and summaries.
By-point alarm inhibitOperators can inhibit individual points for alarm announcement. Alarms for these
points in the device are suppressed and do not appear in the Alarm Summary
display. Since it is still important to be able to scrutinize the alarm conditions and
events generated by testing, the system continues to poll the devices normally.
Events are still generated and appear in the event summary with an alarm-inhibit
flag to distinguish them from other events.
Audible alarmingThe HMI annunciates alarms either by beeping or playing sound files. If configured
to beep when an alarm is generated, the number of beeps will indicate the alarm
severity. Alternately, sound files are supplied that can be configured to play when
alarms of specific severity levels are generated. Additional sound files are easily
added to the system. Audible alarming announcement can be also inhibited on a
by-point basis.
Triggered programsOASyS DNA Realtime Services generates alarms and events from telemetered
and calculated point data as well as from application programs within the
Advanced Calculation Engine (ACE) subsystem. The system can be configured so
that specific alarms or events automatically trigger or activate programmed actions
in response.
White paper | 12
Smart Alarming Management
Disturbance mode (Storm mode)Within the InstAlarm subsystem, alarming can be configured to operate
in Disturbance mode, where low-priority alarms are not processed. Alarm
Disturbance mode suspends the processing of lower-priority alarms during
periods of peak alarm volumes. Disturbance mode includes the following
functionalities:
• Maximum severity level configuration
• Ability for applications or operators to enter or exit alarm disturbance mode
• Regeneration of alarms for analog, status, and rate points after exiting
disturbance mode
Storm mode expands the Alarm Disturbance capabilities with the ability to
suppress the lowest-priority alarms by AOR. The operator can define a different
priority level for each AOR when activating the Alarm Disturbance mode.
Test Mode alarm suppressionTest Mode alarm suppression reduces unnecessary alarms when field devices
are being tested as part of troubleshooting, maintenance and updates. Alarms
generated by such devices under these circumstances are not actionable,
because they are the result of work being done on the field equipment itself.
To use this feature, the user places the device into Test Mode via the GUI. Alarms
on any points in the device are suppressed and do not appear in the Alarm
Summary. Since it is still important to be able to scrutinize the alarm conditions
and events generated by testing, the system continues to poll the devices
normally. Events are still generated and appear in the event summary with a test
mode flag to distinguish them from other events.
White paper | 13
Smart Alarming Management
Alarm suppressionTo reduce nuisance alarms, Schneider Electric’s
ADMS supports different types of alarm suppression,
applicable to analog and status-telemetered points;
see Figure 5:
• Control-initiated alarm suppression – Operator-
initiated commands can cause many alarms to
appear as a direct result of the command. Control-
initiated alarm suppression prevents these alarms
from cluttering the alarm table.
• Hierarchical alarm suppression – Hierarchical alarm
suppression will prevent large numbers of alarms
from cluttering an operator’s display when they are
triggered as the result of a single device going into
alarm. This suppression applies to parent and child
device relationships only; four types of suppression
are applicable:
- Parent alarm timeout – When a parent point goes
into alarm or enters a different alarm state, the
children are marked as suppressed.
- Parent return-to-normal timeout – The parent
Return-to-Normal (RTN) timeout value assists
in suppressing child alarms that are held until
after the parent returns to normal. In reality, this
timeout value can be used either with or without a
configured parent alarm timeout value.
- Transient alarm suppression – Transient alarm
suppression is invoked when a status point
changes state, or when an analog point changes
between the high/low alarm states. In this case,
the child does not have a parent.
- Alarm hold-off – Alarm hold-off is used to
temporarily suppress child state alarms that result
from data crunching. Other types of alarms, such
as command failure, execute as normal. Alarm
hold-off is supported for analog and status points.
The combination of alarm suppression types does
not affect the performance of each type. An alarm is
suppressed when it satisfies one of the suppression
criteria.
Alternate Alarm Limit SetsThis feature allows the operator to select an alternate limit set and assign it to an
analog group. When a new limit set is assigned to a group of analog points, all
points in the group will immediately be subjected to the new limits.
Parent
Alar
m S
tate
normal
alarm
10 60 100 115 130 Time (Seconds)
Child2
Parent goes into alarmand children are markedfor alarm suppression
Child alarmsare suppressed
Parent returnsto normal
Child1 returns tonormal without
generating alarms
Child2 is in a different state from where it was at the time
of alarm suppression; therefore, an alarm is generated for Child2
Child1Child2 alarm suppression timeout
Child1 alarm suppression timeout
Figure 5. Alarm suppression capabilities.
White paper | 14
Smart Alarming Management
Dynamic Alarm LimitsDynamic Alarm Limit is a new feature in the Smart Alarming infrastructure where
limit values depend on predefined input signals. Dynamic Alarm Limit can be
profile-based, analog-based or interval-based. For example, this functionality is
useful when the maximum operational current of a transformer depends on the
weather temperature.
Dynamic Alarm Limit is, in effect, a special configuration of Alarm Limit Sets, so it
can be used combined with the Alarm Limit Set configuration.
Seasonal/24h alarm limitsThe Alternate and Dynamic Alarm Limits functionalities enable the administrator to
create seasonal or 24-hour limits.
Operator alarm overrideSchneider Electric’s ADMS lets the operator override the individual limits values.
The HMI will display a summary of all points whose alarms have been manually
overridden, including timestamp and identification of the user who applied the new
alarm limits.
Smart Alarming Management
White paper | 015
Logging and storage: Historian System
Numeric point limit violations and ‘returns to normal’ are logged as events, unless
the point is deactivated, manually overridden or event inhibited. Of course, it is
also possible to define alarm/event action classes that will not generate an event.
The event history, as part of Schneider Electric’s ADMS Historian System, provides
a chronological record of changes in the system’s condition, as well as actions
taken by system users over time.
Alarms and events are logged to Historian Services, and the logs are then stored
online for a configurable time period by the Historical Database for immediate
retrieval and analysis. After receiving data from other ADMS Services, Historical
Database can summarize this data for use in reports, displays, trends, reports and
analysis applications.
In order to manage events and analyze past alarm states, it is necessary to be
able to categorize events into various types. To facilitate this categorization, event
information available includes the source of the alarm (system, database, or
application); the alarm inhibit type if it exists (none, unknown, application-specific,
transient, parent alarm, parent control, inhibited, and test mode); and the type of
control for control events, i.e., alarm acknowledgements are distinguished.
Based on Microsoft SQL Server Reporting Services, Schneider Electric’s ADMS
Historian System also automatically generates detailed reports organized
according to the location of the alarm, to facilitate compliance processes and to
monitor and improve staff performance.
White paper | 16
Smart Alarming Management
Conclusion
Electric utilities are seeing more solutions becoming available to them to help
realize the Smart Grid that will optimize distribution operations effectiveness and
efficiency. Schneider Electric’s InstAlarm Smart Alarming management solution is
designed to take advantage of the seamless integration of the field-proven OASyS
DNA SCADA and DMS services enabled by Schneider Electric’s ADMS. As this
comprehensive solution collects and analyzes real-time data from intelligent
field devices and recognizes and automates appropriate network adjustments,
the Smart Alarming solution identifies events judiciously at every level, helping
operators focus on truly significant performance issues and improve their response
efforts. Combining Smart Operations and Smart Alarming is a significant step
toward a streamlined, effective and safe Smart Grid.
Schneider Electric USA, Inc.
4701 Royal Vista CircleFort Collins, CO 80528Phone: 1-866-537-1091 + (34) 9-17-14-70-02Fax: 1-970-223-5577www.schneider-electric.com/us
December 2012
©20
12 S
chne
ider
Ele
ctric
. All
right
s re
serv
ed.