SERVICES PLATFORM PROFILE

INTEGRATED PRODUCTION & PERFORMANCE SUITE

Alarms and EventsOVERVIEWMaintaining a current, accurate alarm and event status in anarchitecture can be challenging. A traditional alarming systemstores the status and state of an alarm in the human-machineinterface (HMI), so keeping the view from operator to operatoror database to database has always been difficult. Re-booting analarm server might require manually rebuilding the state of thealarm, but you are left with the question of whether the alarm isacknowledged or suppressed?

FactoryTalk Alarms and Events rewrites this paradigm by movingall alarm configuration (including alarm messages) down to thecontroller where the alarm conditions are monitored. As part ofthe FactoryTalk Services Platform, FactoryTalk Alarms and Eventsprovides components that allow FactoryTalk-enabled products toparticipate in a common, consistent view. It provides managementof alarms and events throughout a FactoryTalk system.

FactoryTalk Alarms and Events helps eliminate the problems oftraditional alarm and event systems such as required programmingin both the controller and the HMI software; alarms beingdetected and processed twice; heavy polling between the HMIand controller tags resulting in heavy network overhead; andalarm time stamps being delayed because they are applied by theHMI after polling and processing. FactoryTalk Alarms and Eventscreates a consistent user interface for visualization andmanagement across the entire control system and significantlyreduces network traffic due to alarm reporting by exception.

FactoryTalk Alarms and Events can support information providedby two different types of alarm sources:

• Device-based Alarms —Pre-built alarm instructions that areprogrammed in a Logix5000 project and then downloaded intoa Logix controller (Figure 2). The controller detects alarmconditions and publishes event information, which is routedthrough the system for display and logging.

• Tag-based Alarms — Software-based alarm servers monitordata tags for alarm conditions and publish event information fordisplay and logging (Figure 3). Tag based alarm monitoring issupported by Logix controllers, PLC-5 controllers, SLC 500controllers, or any third-party device through OPC Data Access(OPC-DA).

HIGHLIGHTS OF FACTORYTALK ALARMS ANDEVENTSFactoryTalk Alarms and Events:

• Provides a single, integrated set of alarm information. Allparticipating FactoryTalk products work together to provide aconsistent way to define, manage, log, and view alarm and eventinformation across a FactoryTalk application.

• Streamlines alarm programming and eliminates polling withdevice-based alarm monitoring. If your automation systemincludes Logix5000 controllers, you can use pre-built alarminstructions, available in RSLogix 5000 v. 16 or later, tosimplify coding, and then download to the controller. Device-based alarm monitoring eliminates the need for duplicatingalarm tags in an HMI server and requires fewer controllercommunication resources by eliminating polling.

• Allows other controllers to participate in the integrated systemwith tag-based alarm monitoring. If your automation systemincludes other controllers, such as PLC-5s or SLC 500s, or ifyou prefer not to use the new alarm instructions with

Figure 1. Docked alarm banner in FactoryTalk View SE

2

Logix5000 controllers, software-based alarm servers monitorcontrollers for alarm conditions and publish event information.

• Allows monitoring alarms and events from third-partycontrollers. Tag-based alarm monitoring also makes it possibleto monitor alarm conditions from third-party controllers,which communicate through OPC-DA servers.

• Provides accurate time stamps on alarm conditions that aregenerated from Logix5000 controllers using device-based alarmmonitoring. With device-based alarm monitoring, time stampsare applied immediately in the controller and are not delayeduntil alarms reach an HMI server.

• Sends process data with events and messages. You can associateup to four tags with each alarm to include process data withevent information and alarm messages.

• Common Open Microsoft SQL database for alarm historystorage. Use the FactoryTalk Alarm and Event Log Viewer,create your own SQL queries or use third-party tools tointerrogate the standard SQL database.

Visualization of alarms is accomplished in FactoryTalk View SEusing four new graphic objects that can be placed in your graphicdisplays. Each graphic object has its own customization options tomake it fit your user requirements.

• Alarm and Event Banner: Displays up to five of the mostrecent, active alarms with the highest priority. The Alarm andEvent Banner is a graphic object that can be added to a graphicdisplay. The graphic display can then be docked at the bottom ofthe operator's screen. Once docked, the alarm and event bannerdisplay reserves its space in the FactoryTalk View SE Clientwindow. From the Alarm and Event Banner an operator canexecute specific commands linked to the alarm, act on the alarm(for example, suppress or acknowledge the alarm), or open agraphic display containing the Alarm and Event Summary.

• Alarm and Event Summary: This object displays up to 2000 ofthe most recent alarms. It shows details about the selectedalarm, its source, and other configurable items. From the Alarmand Event Summary the operator can execute specificcommands linked to the alarm and act on the alarm (forexample, suppress or acknowledge the alarm). The Alarm andEvent Summary also contains a full suite of filter and sortingoptions to allow the operator to see exactly what is important.

• Alarm and Event Log Viewer: This object is used to view thehistory of alarms and events that have been logged to adatabase. The Alarm and Event Log Viewer object also has afull suite of filter and sorting options to allow the operator toview data from the historical SQL database. From this screen,an operator can easily reconstruct the sequence of eventsoccurring in time that lead to a process failure.

• Alarm Status Explorer: This object is a graphic object userscan add to graphic displays. The graphic display then can showthe status of all alarms in the FactoryTalk system and allows anoperator to suppress, unsuppress, disable and enable alarms.From this graphic display an operator can quickly identify whatalarms are currently suppressed or disabled.

This alarm monitoring system provides many benefits overtraditional alarming systems including:

• Alarm instructions are programmed only once and thendownloaded to the controller, reducing programming effortand errors. And full programmatic access is available from thecontrol system to change alarm state. For example, during amachine switchover, alarms from a removed tool can besuppressed or disabled from the control program.

• Alarm conditions are detected more quickly and alarm status ismaintained. And since the controller is the device that createsand maintains the alarm state, replacing a server or re-bootingan HMI means nothing to the actual state of the alarm. It'sstored in the controller and reported to the HMI when it againbecomes available.

• Real-time alarming is performed in the controller. Alarm state ismanaged, processed, and preserved by controllers, even if acomputer goes down.

• HMI tags are not required, reducing overhead and potential tagmapping errors. The HMI only requires a simple subscriptionto the controller and definition of how the alarms should beviewed and logged.

Figure 2. Device-based alarms

Figure 3. Tag-based alarms

3

• Data polling is eliminated; alarm status is communicated onlywhen state changes, reducing network overhead, controllerprocessing, and improving overall system performance.

• Time stamps on alarm conditions are accurate, because they areapplied in the controller, and not delayed until they reach theHMI software. Now resolution to first-in conditions on alarmstriggered a few milliseconds apart can be achieved easily.

In addition:

• Historical Logging: Reconstruct a sequence of events andactions easily using the FactoryTalk Alarms and Events history.FactoryTalk Alarms and Events logs all alarm actions and statusto a Microsoft SQL Server database. Select your own existingMS SQL Server database for storage, or use the MS SQLServer Express database that comes with FactoryTalk Viewand RSLinx Enterprise. The contents of the database can bedisplayed, sorted, and filtered using the Alarm and EventLog Viewer.

• Broadcast by Exception: Improve system efficiency byreducing network usage and freeing controller resources.Device-based alarms use a new broadcast method forcommunications. When an alarm occurs, the controllerbroadcasts that alarm to all alarm subscribers. This broadcast-by-exception technique eliminates the constant pollingtraditional alarm systems required, freeing network bandwidth,as well as the controller resources servicing those requests.

• Controller-based Time Stamp: When operators need to builda historical reference of events that led up to a failure, the timeassociated with each event should be as precise as possible.Traditional alarm monitoring relied on the HMI system totime-stamp events. Polling cycles inherent in HMI-based alarmmonitoring introduced latency as well as sequencing errors inthe time stamps. With device-based alarms, time stamps arecaptured at the controller when the actual event occurs.Accuracy of the time stamps is now a function of thecontrollers' code scan.

• Alarm Buffering: Minimize the risk of losing alarm transitionsin the event of a server crash with alarm buffering. In the eventthat the computer hosting an RSLinx Enterprise alarm servercrashes or is restarted, rather than discard alarms that occurwhile the system is recovering, the controller buffers alarm

transitions. When the RSLinx Enterprise alarm server comesback online and reconnects, the controllers push the bufferedalarm information up to the HMI, including the timestampsfor when the event occurred. Additionally, alarm buffering isavailable between the alarm server and your Microsoft SQLalarm history database. In the event that the computer hostingthe database is not currently connected or is rebooting, thealarm server will buffer any information on the local drive thatneeds to be logged in the database and will pass thatinformation to the database when it reconnects.

THE EXPANDED INTEGRATED ARCHITECTUREThe FactoryTalk Services Platform delivers value through reuseand sharing of common service features (or services) across a rangeof software applications. This enables superior interoperabilityand commonality between applications and results in reducedengineering, operations and training costs while extending the lifeof existing investments. Products that are built on the FactoryTalkServices Platform are better integrated, easier to configure, havean identical look and feel, and are easier to maintain thanproducts that do not share common features.

Figure 4. Rockwell Automation Integrated Architecture

Publication FTALK-PP015A-EN-P – October 2007 Copyright © 2007 Rockwell Automation, Inc. All Rights Reserved.

Facto

ryTalk

Ass

etCen

tre

Facto

ryTalk

Batc

h

Facto

ryTalk

Gate

way

Facto

ryTalk

Hist

orian

SE

Facto

ryTalk

Hist

orian

Clas

sic

Facto

ryTalk

Metr

ics

Facto

ryTalk

Metr

ics LE

Facto

ryTalk

Porta

l

Facto

ryTalk

Sche

duler

Facto

ryTalk

Pro

ducti

onCe

ntre

Facto

ryTalk

View

ME

Facto

ryTalk

View

SE

Facto

ryTalk

Tra

nsac

tion M

anag

er

RSLo

gix 5

RSLo

gix 50

0

RSLo

gix 50

00

RSLin

x Clas

sic

RSNe

tWor

x

RSVi

ew32

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.