UniInt failover modes

The failover mode specifies how the backup PI Interface for OPC DA instance handles connecting to an OPC server, creating groups, and adding points when failover occurs.

The faster the backup interface instance can take over data collection, the less data is lost. However, the ongoing activities required to maximize the readiness of the backup interface instance increase OPC server load and system resources. To determine which mode to use, consider how long failover takes and how much workload your system can handle. Be prepared to experiment, and consult your OPC server documentation and vendor as needed.

PI Interface for OPC DA provides five levels of failover, from cold to hot. Higher (“hotter”) levels ensure that more data is preserved in the event of failover, but impose increasing workload on the system. The highest level, hot failover, is lossless unless both the primary and backup interface instance nodes fail together.

Hot failover

Hot failover is the most resource-intensive mode. Both the primary and backup interface instances are collecting data, possibly from the same OPC server. No data is lost during failover, but the OPC server carries a double workload, or, if two servers are used, the back-end system must support both OPC servers.

Warm failover

There are three options for warm failover:

• No groups on backup interface instance (Warm_1)

  The backup instance connects to the OPC server every 30 seconds and checks its status, but does not create groups or add items. Because the interface pre-loads point information from Data Archive, this option is faster than cold failover, but when the backup becomes the primary instance, it must create groups, add items to them, activate them, and then advise them. Because of the time required, data can be lost during failover. This option is for OPC servers that cannot support groups when they are not the active OPC server. The command line equivalent is /UFO_TYPE=HOT /FM=1.

• Inactive groups on backup interface instance (Warm_2)

  The backup instance connects to the OPC server, creates inactive groups, and adds items to the groups, but does not activate the groups. For most OPC servers, this approach reduces workload, because the server does not need to maintain the current values for inactive groups. When the interface instance becomes primary, it activates the groups and then advises them. This approach is faster than option 1. The command line equivalent is /UFO_TYPE=HOT /FM=2.

• Active groups on backup interface instance (Warm_3)

  The backup interface instance connects to the OPC server, creates groups, adds items, and activate the groups, but does not advise the groups. The OPC server must maintain its cache of current values for all the items, but does not send the values to the backup interface instance.

  If both interface instances are connected to the same OPC server, and the server maintains one central cache for data, this approach might impose very little load on the server, because the cache must be updated for the primary interface instance.

  For an OPC server that does not use a centralized cache or a configuration in which the interface instances connect to different OPC servers, this approach can impose a considerable load on an OPC server or the data source system. When the backup interface instance becomes primary, all it needs to do to start collecting data is to advise the groups, making this the fastest warm failover option. The command line equivalent is /UFO_TYPE=HOT /FM=3.

Cold failover

Cold failover is required if an OPC server can support only one client, or if you are using redundant OPC servers and the backup OPC server cannot accept connections. The backup instance does not connect with the OPC server until it becomes primary. At that time, it must create groups, add items to groups, and advise the groups. This delay almost always causes some data loss, but imposes no load at all on the OPC server or data source system.

Tip: In addition to UniInt based failover, PI Interface for OPC DA also supports OPC server-level failover. See the topic Configure OPC server failover and its sub-topics for detailed descriptions of the options available. OPC server-level failover is based on information received from the OPC Server; there is no PI point to control which OPC Server is active or which connection is preferred.

In brief, OPC server-level failover utilizes OPC watchdog points to control OPC server-level failover. Watchdog points enable the interface to detect when its OPC server is unable to adequately serve data and failover to another OPC server if that other OPC server is better able to collect data. This approach is intended for OPC servers that are data aggregators, collecting data from multiple PLCs. If one point on each PLC is designated as a watchdog point, the interface can be instructed to failover if less than a specified number of those points are readable. This approach enables the benefits of redundancy to be applied at the data collection level.