services platform profile
Alarms and Events
Maintaining a current, accurate alarm and event status in an
architecture can be challenging. A traditional alarming system
stores the status and state of an alarm in the human-machine
interface (HMI), so keeping the view from operator to operator
or database to database has always been difficult. Re-booting an
alarm server might require manually rebuilding the state of the
alarm, but you are left with the question of whether the alarm is
acknowledged or suppressed?
FactoryTalk Alarms and Events rewrites this paradigm by moving
all alarm configuration (including alarm messages) down to the
controller where the alarm conditions are monitored. As part of
the FactoryTalk Services Platform, FactoryTalk Alarms and Events
provides components that allow FactoryTalk-enabled products to
participate in a common, consistent view. It provides management
of alarms and events throughout a FactoryTalk system.
FactoryTalk Alarms and Events helps eliminate the problems of
traditional alarm and event systems such as required programming
in both the controller and the HMI software; alarms being
detected and processed twice; heavy polling between the HMI
and controller tags resulting in heavy network overhead; and
alarm time stamps being delayed because they are applied by the
HMI after polling and processing. FactoryTalk Alarms and Events
creates a consistent user interface for visualization and
management across the entire control system and significantly
reduces network traffic due to alarm reporting by exception.
FactoryTalk Alarms and Events can support information provided
by two different types of alarm sources:
• Device-based Alarms —Pre-built alarm instructions that are
programmed in a Logix5000 project and then downloaded into
a Logix controller (Figure 2). The controller detects alarm
conditions and publishes event information, which is routed
through the system for display and logging.
• Tag-based Alarms — Software-based alarm servers monitor
data tags for alarm conditions and publish event information for
display and logging (Figure 3). Tag based alarm monitoring is
supported by Logix controllers, PLC-5 controllers, SLC 500
controllers, or any third-party device through OPC Data Access
Figure 1. Docked alarm banner in FactoryTalk View SE
FactoryTalk Alarms and Events:
• Provides a single, integrated set of alarm information. All
participating FactoryTalk products work together to provide a
consistent way to define, manage, log, and view alarm and event
information across a FactoryTalk application.
• Streamlines alarm programming and eliminates polling with
device-based alarm monitoring. If your automation system
includes Logix5000 controllers, you can use pre-built alarm
instructions, available in RSLogix 5000 v. 16 or later, to
simplify coding, and then download to the controller. Devicebased alarm monitoring eliminates the need for duplicating
alarm tags in an HMI server and requires fewer controller
communication resources by eliminating polling.
• Allows other controllers to participate in the integrated system
with tag-based alarm monitoring. If your automation system
includes other controllers, such as PLC-5s or SLC 500s, or if
you prefer not to use the new alarm instructions with
• Alarm and Event Banner: Displays up to five of the most
recent, active alarms with the highest priority. The Alarm and
Event Banner is a graphic object that can be added to a graphic
display. The graphic display can then be docked at the bottom of
the operator's screen. Once docked, the alarm and event banner
display reserves its space in the FactoryTalk View SE Client
window. From the Alarm and Event Banner an operator can
execute specific commands linked to the alarm, act on the alarm
(for example, suppress or acknowledge the alarm), or open a
graphic display containing the Alarm and Event Summary.
• Alarm and Event Summary: This object displays up to 2000 of
the most recent alarms. It shows details about the selected
alarm, its source, and other configurable items. From the Alarm
and Event Summary the operator can execute specific
commands linked to the alarm and act on the alarm (for
example, suppress or acknowledge the alarm). The Alarm and
Event Summary also contains a full suite of filter and sorting
options to allow the operator to see exactly what is important.
Figure 2. Device-based alarms
Logix5000 controllers, software-based alarm servers monitor
controllers for alarm conditions and publish event information.
• Allows monitoring alarms and events from third-party
controllers. Tag-based alarm monitoring also makes it possible
to monitor alarm conditions from third-party controllers,
which communicate through OPC-DA servers.
• Alarm and Event Log Viewer: This object is used to view the
history of alarms and events that have been logged to a
database. The Alarm and Event Log Viewer object also has a
full suite of filter and sorting options to allow the operator to
view data from the historical SQL database. From this screen,
an operator can easily reconstruct the sequence of events
occurring in time that lead to a process failure.
• Provides accurate time stamps on alarm conditions that are
generated from Logix5000 controllers using device-based alarm
monitoring. With device-based alarm monitoring, time stamps
are applied immediately in the controller and are not delayed
until alarms reach an HMI server.
• Alarm Status Explorer: This object is a graphic object users
can add to graphic displays. The graphic display then can show
the status of all alarms in the FactoryTalk system and allows an
operator to suppress, unsuppress, disable and enable alarms.
From this graphic display an operator can quickly identify what
alarms are currently suppressed or disabled.
• Sends process data with events and messages. You can associate
up to four tags with each alarm to include process data with
event information and alarm messages.
• Common Open Microsoft SQL database for alarm history
storage. Use the FactoryTalk Alarm and Event Log Viewer,
create your own SQL queries or use third-party tools to
interrogate the standard SQL database.
This alarm monitoring system provides many benefits over
traditional alarming systems including:
• Alarm instructions are programmed only once and then
downloaded to the controller, reducing programming effort
and errors. And full programmatic access is available from the
control system to change alarm state. For example, during a
machine switchover, alarms from a removed tool can be
suppressed or disabled from the control program.
Visualization of alarms is accomplished in FactoryTalk View SE
using four new graphic objects that can be placed in your graphic
displays. Each graphic object has its own customization options to
make it fit your user requirements.
• Alarm conditions are detected more quickly and alarm status is
maintained. And since the controller is the device that creates
and maintains the alarm state, replacing a server or re-booting
an HMI means nothing to the actual state of the alarm. It's
stored in the controller and reported to the HMI when it again
becomes available.
• Real-time alarming is performed in the controller. Alarm state is
managed, processed, and preserved by controllers, even if a
computer goes down.
• HMI tags are not required, reducing overhead and potential tag
mapping errors. The HMI only requires a simple subscription
to the controller and definition of how the alarms should be
viewed and logged.
Figure 3. Tag-based alarms
• Data polling is eliminated; alarm status is communicated only
when state changes, reducing network overhead, controller
processing, and improving overall system performance.
transitions. When the RSLinx Enterprise alarm server comes
back online and reconnects, the controllers push the buffered
alarm information up to the HMI, including the timestamps
for when the event occurred. Additionally, alarm buffering is
available between the alarm server and your Microsoft SQL
alarm history database. In the event that the computer hosting
the database is not currently connected or is rebooting, the
alarm server will buffer any information on the local drive that
needs to be logged in the database and will pass that
information to the database when it reconnects.
• Time stamps on alarm conditions are accurate, because they are
applied in the controller, and not delayed until they reach the
HMI software. Now resolution to first-in conditions on alarms
triggered a few milliseconds apart can be achieved easily.
In addition:
• Historical Logging: Reconstruct a sequence of events and
actions easily using the FactoryTalk Alarms and Events history.
FactoryTalk Alarms and Events logs all alarm actions and status
to a Microsoft SQL Server database. Select your own existing
MS SQL Server database for storage, or use the MS SQL
Server Express database that comes with FactoryTalk View
and RSLinx Enterprise. The contents of the database can be
displayed, sorted, and filtered using the Alarm and Event
Log Viewer.
The FactoryTalk Services Platform delivers value through reuse
and sharing of common service features (or services) across a range
of software applications. This enables superior interoperability
and commonality between applications and results in reduced
engineering, operations and training costs while extending the life
of existing investments. Products that are built on the FactoryTalk
Services Platform are better integrated, easier to configure, have
an identical look and feel, and are easier to maintain than
products that do not share common features.
• Broadcast by Exception: Improve system efficiency by
reducing network usage and freeing controller resources.
Device-based alarms use a new broadcast method for
communications. When an alarm occurs, the controller
broadcasts that alarm to all alarm subscribers. This broadcastby-exception technique eliminates the constant polling
traditional alarm systems required, freeing network bandwidth,
as well as the controller resources servicing those requests.
• Controller-based Time Stamp: When operators need to build
a historical reference of events that led up to a failure, the time
associated with each event should be as precise as possible.
Traditional alarm monitoring relied on the HMI system to
time-stamp events. Polling cycles inherent in HMI-based alarm
monitoring introduced latency as well as sequencing errors in
the time stamps. With device-based alarms, time stamps are
captured at the controller when the actual event occurs.
Accuracy of the time stamps is now a function of the
controllers' code scan.
• Alarm Buffering: Minimize the risk of losing alarm transitions
in the event of a server crash with alarm buffering. In the event
that the computer hosting an RSLinx Enterprise alarm server
crashes or is restarted, rather than discard alarms that occur
while the system is recovering, the controller buffers alarm
Figure 4. Rockwell Automation Integrated Architecture
Alarms & Events
FactoryTalk, Logix, Rockwell Automation, Rockwell Software, RSLinx and RSLogix are trademarks or registered trademarks of Rockwell Automation, Inc.
All other trademarks are the property of their respective owners.
Publication FTALK-PP015A-EN-P – October 2007
Copyright © 2007 Rockwell Automation, Inc. All Rights Reserved.
RSLinx Classic
RSLogix 5000
RSLogix 500
RSLogix 5
FactoryTalk Transaction Manager
FactoryTalk View SE
FactoryTalk View ME
FactoryTalk ProductionCentre
FactoryTalk Metrics LE
FactoryTalk Metrics
FactoryTalk Historian Classic
FactoryTalk Historian SE
FactoryTalk Gateway
FactoryTalk Batch
FactoryTalk AssetCentre
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF