Redundant DIObjects

The following section explains implementing redundant DIObjects.

Configuration

AppEngines can host redundant Device Integration Objects (DIObjects). The Redundant DIObject is a DINetwork Object used to enable continuity of I/O information from field devices.

The redundant DIObject provides the ability to configure a single object with connections to two different data sources. If the primary data source fails, the redundant DIObject automatically switches to the backup data source for its information.

There is a one-to-two relationship between an instance of the redundant DIObject and the running instances of the source DIObjects. That is, for each redundant DIObject, a pair of source DIObjects is deployed.

The following naming practices are recommended for implementing redundant DI client objects. The OPCClient object is typically used as the DI client object, since it includes an attribute (Hierarchy Path) that allows it to be easily configured to emulate the naming structure of many commonly-used PLCs.

• If the Communication Driver resides on the same node as the AppEngine hosting the DI client object, configure the server node name in the General tab as <Blank> or <Localhost>.

• If the Communication Driver resides on a remote node, any node name is acceptable as it refers to the same remote node regardless of where the DI client object is located.

In the previous example, the PLC sent data using two unique protocols. It is also common for the PLC to send data through two ethernet ports using the same protocol, via different IP addresses. In this case, the following redundant DIObject configuration is recommended:

The figure shows two unique DAServer instances, each using the same topic and pointing to a unique IP address. The DAServers in this scenario can be also be deployed on different machines.

Common Configuration Requirements

Redundant DIObject configuration requires the following:

• Source DIObjects do not have to be of the same type, but must support the same type of Scan Group and have the same items address space. The Scan Groups configured in the Redundant DIObject must also be configured in both the Primary and Backup DIObjects.

• The configuration must include at least one Scan Group.

• The names of the Primary and Backup DIObject must be different. The Primary DIObject attribute refers to the name of the DIObject that will be used as the primary source of I/O attributes.

The Redundant DIObject supports creating and configuring Scan Groups, BlockReads, and BlockWrites. The Redundant DIObject can have configurable I/O points (Tag dictionary), which are periodically scanned for their value. The redundant DIObject supports Subscription, Read Transaction, and Write Transaction on I/O points.

Redundant DIObject Behavior at Run-Time

After the redundant DIObject is initialized, its state changes to Startup. The object opens MX communications and registers a reference to ScanState to track whether the DIObject is deployed. If the DIObject is off scan, the redundant DIObject treats it as a bad data source.

The ProtocolFailureCode and ConnectionStatus attributes provide status of the source device. During run-time, the redundant DIObject performs the following tasks:

1. Adds newly activated attributes to the Active DI source.

2. Updates attributes with new values from the Active DI source.

3. Monitors the connection with the Active and Standby DI source. If the connection to the Active DI source is lost, the object switches to the Standby DI source.

If both DI sources are in bad state, the object raises the Connection Alarm.