91
Setting up FactoryTalk system availability Chapter 14
Rockwell Automation Publication VIEWSE-UM006K-EN-E
375
If this property
Is changed to this value
This is what happens when AlarmAcceptEdits is
run
Alarmed
(Alarmed or Not Alarmed)
True
The newly alarmed tag is monitored for alarms.
Additionally, existing alarm events with the same name
as the newly alarmed tag are removed from HMI tag
alarm summaries.
False
Existing alarm transactions for the tag are removed
from HMI tag alarm summaries.
Label
Any change
New alarm transactions reflect the new Label value.
Existing alarm transactions continue to use the old
Label value.
Severity
Any change
If the tag is currently in alarm, a new alarm transaction
is generated, based on the new Severity value.
Analog Level
Level is added
Existing alarm transactions for the tag are removed
from HMI tag alarm summaries.
Level is added or removed
If the change results in a new alarm state for the tag, a
new alarm transaction is generated based on the new
state.
Analog Threshold
Any change
If the change results in a new alarm state for the tag, a
new alarm transaction is generated based on the new
state.
Analog Direction
Increasing or Decreasing
Existing alarm transactions for the tag are removed
from HMI tag alarm summaries.
If the change results in a new alarm state for the tag, a
new alarm transaction is generated based on the new
state.
Digital Alarm Type
On (from Off)
or
Off (from On)
A new alarm transaction is generated.
If the tag is currently in alarm, the transaction is
OutofAlarm; if the tag is currently out of alarm, the
transaction is InAlarm.
Any Change, Changes to On, or
Changes to Off
(from Off or On)
If the tag is currently in alarm, an OutofAlarm
transaction is generated.
On
(from Any Change, Changes to
On, or Changes to Off)
If the tag’s value is On, a new alarm transaction is
generated.
If the tag’
s value is Off, no new transaction is
generated, and existing alarm transactions remain in
HMI tag alarm summaries.
Off
(from Any Change, Changes to
On, or Changes to Off)
If the tag’s value is Off, a new alarm transaction is
generated.
If the tag’s v
alue is On, no new transaction is
generated, and existing alarm transactions remain in
HMI tag alarm summaries.
In Alarm Messages
Out of Alarm Messages
Acknowledge Messages
Identification
Out of Alarm Label
Deadband
Any change
The change takes effect, for any new or existing alarm
transactions associated with the modified tag.
Tip: The AlarmAcceptEdits command will not apply
y
changes to the contents of User Default messages, for
theInAlarm Messages, Out of Alarm Messages, and
Acknowledge Messages properties.
49
Chapter 14 Setting up FactoryTalk system availability
376
Rockwell Automation Publication VIEWSE-UM006K-EN-E
Acknowledge (bit)
Any change
The change takes effect, for any new or existing alarm
transactions associated with the modified tag.
If an Acknowledge Bit tag is added with the Auto Reset
property set to True, the Acknowledge Bit tag is set to
0.
Handshake (bit)
Any change
The change takes effect, for any new or existing alarm
transactions associated with the modified tag.
If a Handshake Bit tag is added, and alarming is started
with handshaking turned on (AlarmOn /H), and if the
alarm tag is in alarm, the Handshake Bit tag is set to 1.
If a Handshake Bit tag is added with the Auto Reset
property set to True, and alarming is started with
handshaking turned on (AlarmOn /H), and if the alarm
tag is not in alarm, the Handshake Bit tag is set to 0.
.
Tip: The AlarmAcceptEdits command is for HMI tag alarms
only. The command is not required to effect online
changes to alarm definitions in a Tag Alarm and Event
Server. For information about modifying FactoryTalk
tag-based alarm properties, see the FactoryTalk Alarms
and Events Help.
To help ensure that HMI data generated in an online redundant system is as
accurate and accessible as possible, keep the following considerations in
mind.
Synchronize time clocks on redundant computers
HMI servers manage the synchronization of HMI tag alarm states, between
primary and secondary servers.
For example, if there are five unacknowledged alarms at the primary server
when it fails, the same five alarms will be show at the secondary server,
when the failover is complete. Alarm states are also synchronized when the
system switches back to the primary server.
To ensure tight synchronization of alarm states, synchronize clocks on the
primary and secondary HMI server computers to a time server.
If the clocks are not synchronized, when a failover occurs, multiple alarms or
inconsistent information might be shown in HMI tag alarm summaries, on
connected clients.
Tip: You can set up a Microsoft Windows domain to include a
time-synchronization service. For details, see Windows
Help for setting up the domain.
Managing HMI data
in an online
redundant system
37
Setting up FactoryTalk system availability Chapter 14
Rockwell Automation Publication VIEWSE-UM006K-EN-E
377
About alarm monitoring on the secondary server
While the primary HMI server is active, the secondary server runs its alarm
monitoring system in backup mode. This means that alarm states are
synchronized even if you have not set up the secondary server to start alarm
monitoring on demand.
The backup mode that runs on the secondary server only keeps alarm states
synchronized; it does not detect alarms.
When the system fails over to the secondary server, alarm monitoring starts
on that server automatically, as if it was running on the primary server.
When the system switches back to the primary server, alarm monitoring
starts on that server automatically, while the secondary server returns to
standby mode.
Tip: If FactoryTalk View SE is monitoring a large number of
HMI tags for alarms, it is possible that alarms might be
missed for tags that go into and out of alarm quickly. This
might happen while the system is failing over to the
secondary or switching back to the primary server.
Centralize storage of diagnostic and alarm log data
Diagnostic log files are stored on every computer where system activity is
generated.
For network distributed applications, it is highly recommended that you log
diagnostic and HMI tag alarm information to a central ODBC database, such
as Microsoft SQL Server, even for HMI servers that are not redundant.
A central, system-wide ODBC log can be made secure and redundant
through features of the database. Central logs also simplify troubleshooting,
by letting you search all diagnostic information in one location.
For additional protection, it is also recommended that you set up FactoryTalk
View SE local diagnostic and alarm logs to buffer logged data, in the event
that communications with the ODBC database are lost.
For information about setting up a central ODBC database:
For diagnostic logs, see Logging system activity on page 381.
For HMI tag alarm logs, see Setting up HMI tag alarms on page 217.
45
Chapter 14 Setting up FactoryTalk system availability
378
Rockwell Automation Publication VIEWSE-UM006K-EN-E
Determine which server will run events
Events that are triggered by an event detector, are not synchronized
specifically between primary and secondary HMI servers.
However, it is possible to manage which server is responsible for detecting
and running events, so that only one server is active at a time.
Use an HMI server’s On Active and On Standby macros, to run the
EventOn
command (starts event detection) when the HMI server becomes active, and
to run the EventOff command (stops event detection) when the HMI server
goes on standby.
This will automatically ensure that event detection is only running on the
Active (primary or secondary) HMI server.
For information about On Active and On Standby macros, see Specifying On
Active and On Standby macros on page 366.
For information about creating macros, see Adding logic and control on page
631.
Synchronize derived tags and data log files
To keep derived tags and data logs synchronized, ensure that the same
derived tags components and data log models are running on the primary and
secondary computers.
You can also keep memory tags synchronized, if their values are the result of
derived tags.
For information about replicating changes from the primary to the secondary
HMI server, see Replicate changes to the secondary HMI server on page 364.
The health monitoring system monitors network connections on all
computers hosting application clients and servers, in a network distributed
application.
The system does the following connection monitoring:
The computer detection interval sets how often the system attempts
to detect whether a computer exists on the network. The default
interval is two seconds.
The network failure detection interval sets how often the system
attempts to verify the health of the network connection to remote
computers. The default interval is 2 seconds.
The maximum network glitch sets the amount of time used to
distinguish a temporary network disruption from an actual
Monitoring network
client and server
connections
32
Setting up FactoryTalk system availability Chapter 14
Rockwell Automation Publication VIEWSE-UM006K-EN-E
379
communications failure. For more information, see "About network
glitches," next.
The maximum delay before server is active sets the maximum
amount of time during a switch back to the primary server, that the
server will wait for clients to respond, before it becomes active. For
more information, see Notifying clients when switching back to the
primary on page 371.
You can change the default settings, in the Health Monitoring Policy Settings
dialog box.
To change Health Monitoring Policy Settings:
1. In FactoryTalk View Studio, in the Explorer window, expand the
System folder, double-click the Policies folder, and then double-click
the System Policies folder.
2. Double-click Health Monitoring Policy, and then select the policy
setting you want to change.
3. Click the amount of time for the policy setting. To select a different
time, click the up or down arrow beside the time.
Tip:
Settings in the System folder, including the Health
Monitoring Policy Settings, are stored at the FactoryTalk
Network Directory, and apply to all application servers
the directory manages.
About network glitches
Sometimes communications across a network are temporarily disrupted, for
fractions of seconds, by noise or brief disconnections.
When this happens, it is possible for the Standby server in a redundant pair to
lose contact with its Active partner, and assume it must become the Active
server.
24
Chapter 14 Setting up FactoryTalk system availability
380
Rockwell Automation Publication VIEWSE-UM006K-EN-E
To prevent the Standby server from becoming active before it is necessary,
the health monitoring system distinguishes a temporary
disconnection
—
called a network glitch
—
from an actual communications
failure.
If the Standby server can re-establish contact with its Active partner within a
set time period, then it remains on standby. If the time period expires before
contact is re-established, then the Standby server becomes the Active server.
The default time period that defines a network glitch is 5 seconds. You can
change the definition, by modifying the policy setting, Maximum network
glitch. For details, see Monitoring network client and server connections on
page 378.
Tip: In a partitioned network, if clients are connected to both
partners in the redundant pair on either side of a network
switch, it is possible for both the primary and the
secondary server to become active. For more
information, see What happens if both servers become
active on page 366.
Documents you may be interested
Documents you may be interested
