We will see how we can test how the concept of redundancy works for AVEVA drivers, and for this, we will use the simulation driver. But it would be equivalent for another driver.
We have PLC1 with the same configuration as PLC2, changing the suffixes from 1-2
PLC1 - Device Groups -> Fast1
In the definition of the Items, we create Item_0
For PLC2, we have exactly the same configuration, starting with the algorithm for the simulator.
PLC2 - Device Groups -> Fast2
And as we mentioned, we have configured the same item.
We insert a new redundancy object, where we have to point to the configuration of our PLCs. As seen in the image, Primary & Secondary and as Ping Item, the variable we have defined in both configurations.
The next device group will be the one we will use when configuring our driver for ... Intouch, Historian, etc...
And in items, it will be the redundant items from both PLC1 and PLC2
And now once we have the driver running, it is time to check its operation.
I will disable the configuration of PLC2
With an OPC Client, we will subscribe to the item we have created for each connection, we have stopped PLC2 and we can already see how Item_0 of that PLC does not communicate and Item_0 of redundancy has the value of PLC1
If on the contrary we stop PLC1 and enable PLC2, we can check its operation.
And to finish, if we disable both PLCs, well of course...
We have no communication with any PLC, and the variable $SYS$Status of the redundancy configuration indicates that there is no communication.
How we configure our Historian for a driver configured with redundancy. More information
The first step, like any driver, is the server where our IO Server is and the name of the application, for this example SIM.
And where the key point is that in the topic, we have to point to the topic of the redundancy configuration.
