Multiple Device Redundancy (Standby Data Paths)

Using CitectSCADA > Building Redundancy Into Your System > Data Path Redundancy > Multiple Device Redundancy (Standby Data Paths)

Multiple Device Redundancy (Standby Data Paths)

If your I/O Devices support peer-to-peer communication, you can add another level of redundancy to your system by duplicating the I/O Devices.

Note: Although I/O Servers are not assigned the Primary or Standby role based on the I/O devices to which they are connected, it is common practice in redundant I/O systems to connect the Primary I/O Devices to the Primary I/O Server and the Standby I/O Devices to the Standby I/O Server. One I/O Server can connect to a mixture of Primary and Standby I/O Devices. The I/O Server can support any number of Standby Data Paths.

The following diagram demonstrates multiple device redundancy and Standby Data Paths:

In this scenario, we have three I/O Servers connected to three I/O Devices in the following manner:

I/O Server	I/O Devices Connected
IOServer1	I/O Device1 (Primary) I/O Device2 (Standby) I/O Device3 (Primary)
IOServer2	I/O Device1 (Standby) I/O Device2 (Primary)
IOServer3	I/O Device1 (Standby) I/O Device2 (Standby) I/O Device3 (Standby)

The following is known:

CitectSCADA clients communicate with every configured I/O Server at the same time (on startup, the clients try to connect to each configured I/O Server. If they cannot establish communications with an I/O Server, a hardware error is generated).
When every device is running, CitectSCADA processes the I/O on the Primary I/O Devices (this reduces the I/O load on the I/O Device (and PLC network), which is important in improving performance).
The client creates network sessions to the three I/O Servers.
The client then sends requests for I/O Device1 and I/O Device3 to I/O Server1, and requests for I/O Device 2 to I/O Server2.

Redundancy is provided as follows:

If I/O Device1 become inoperative on I/O Server1, the client will send requests for I/O Device1 to I/O Server2 through the standby data path. It continues to send requests for I/O Device3 to I/O Server1.
If I/O Device also becomes inoperative on I/O Server2, the client sends requests to I/O Server3.
If the connection between I/O Device1 and I/O Server1 be re-established, the client resumes sending requests for I/O Device1 to I/O Server1.

The Standby I/O Devices will be activated strictly in the order in which they are first created in the project. This can be viewed by looking in the Units.dbf file in the project directory.

Since we can place primary and standby I/O Devices on various I/O Servers, share the primary I/O Devices between your I/O Servers to balance the loading across the I/O Servers. However, this might not apply for every protocol because the loading could be dependent on the PLC network and not the I/O Server CPU. In this case, more than one active I/O Server on the same PLC Network can degrade the PLC network and therefore, slow the total response.