Rockwell Automation FactoryTalk Historian SE 3.0 UniInt Interface User Guide - Manual (Page 102)

UniInt Failover Scheme
96
Interfaces Connect to Data Source at Approximately the Same Time
There may be a chance where both copies of the interface connect to the data source at
approximately the same time and contend to become the primary interface. For example,
both interfaces are running and then the data source is started, or both copies of the interface
are started at the same time. If the data source is unavailable and the interface is running,
attempts to update the failover control points will return an error. If the interface receives
errors reading from or writing to the data source, it will transition to the backup role. At start-
up, the interface starts in the backup role. It initially checks the value of the active ID point
and the heartbeat point of the other copy of the interface. The value of the active ID point
will be one of three values: the failover ID for this copy of the interface, the other copy‘s
failover ID, or something else. These three scenarios are discussed below.
 If the ActiveID equals the failover ID for this copy of the interface, the interface
transitions to the primary role and starts sending data to Historian. In this situation, it
will take two failover update intervals for data to show up in Historian. This is because
the interface actually transitions to the AssumingControl state for two intervals and
queues its data. No data is lost during this two failover update interval start-up delay.
The delay is used to prevent contention between the two interfaces trying to assume the
role of primary at the same time.
 If the ActiveID equals the failover ID for the other copy of the interface, the interface
stays in the backup role and starts monitoring the heartbeat of the other copy. For
example, if both copies of the interface are down and then one copy is started and the
active ID point is equal to the other copy‘s failover ID, it will take four update intervals
for its data to show up in PI. This is because the interface assumes the backup role at
startup and waits to verify the other copy‘s heartbeat. If the other copy‘s heartbeat point
is not being updated, this copy will go through the process of assuming the role of
primary. All data collected by the interface during this four interval start-up delay will be
sent to PI.
 If the ActiveID equals something other than this copy‘s or the other copy‘s failover
ID, the interface transitions to the AssumingControl state. Again, the interface will
stay in this state for up to two failover update intervals to avoid contention. For example,
if interface IF1 reads the ActiveID, then interface IF2 reads the ActiveID before
interface IF1’s update takes place. Interface IF1 will claim primary by setting the
ActiveID to its failover ID. Interface IF2 will claim primary by setting the ActiveID
to its failover ID. Then both copies wait one failover update interval and read the value
of the active ID point. If the ActiveID has changed to the other copy‘s failover ID, the
interface will transition to the backup role. If the ActiveID is still equal to this copy‘s
failover ID, the interface will wait one more interval. If, after two intervals, the
ActiveID still equals this copy‘s failover ID, the interface will transition into the
primary role and send the data it has queued during this process.
In any of the situations where a backup assumes control by updating the active ID point,
the update takes place immediately after reading the point. The two interval delay
resolves the collision problem and will only be an issue if both interfaces read the value
of the active ID point before the update reaches the data source. If the latency for a write
is more than two failover update intervals, then the failover update interval should be
increased. This algorithm results in the last interface to make the update to the active ID
point remaining the primary interface.