The OPC application need not to be changed or affected for redundance connections to the controllers.

During the start of the data aquisition both connections will be created, established and checked. The data will be handled over one connection only preventing the controller from overloaded. This connection now is the master connection.
If the master connection does not respond in the requested time or it breaks, all items will be switched active on the second connection. If data are arriving now it becomes the master connection. The previous connection becomes slave, all items will be inactivated on it. None of the items will give a quality error to the OPC client. In the diagnostics logger the switching will be listed.
Only if all connections will be disturbed the elements will deliver bad quality. The OPC client can check the switching connection over the item "System.Topics..Redundancy", the value will change.
If the slave connection will fail this will be written into the diagnostics logger. Additionally the item "System.Topics..Status" will be set to failure.

On redundancy with three connections in case of failure of the master connection, some items are switched active on both slave connections. The faster connection wins and will become master, all of the rest items will be used on it. The more slowly connection goes into the slave state again.
Over the item "Redundancy" it can be checked which connection actually is the master. The items "Status1" and "Status2" (optionally "Status3" or more) are showing the actual state of the connections. They should be all zero if all connections exists.
Writing to the item "Redundancy" will switch the master immediately. This is for test purposes or for mainenance.
The jitter during switching the redundancy connection sets together

Monitoring timeout - the application timeout. It should be the controller reaction time multiplied by three, but minimum of one second.