In the ROK kit, they use serial ports and a redundancy manager with power relays to attempt to do all of what you are asking. Unless the spec calls for this, don’t go there. In my experience, the controllers will run for 20+ years without an issue, period. Adding complexity will actually reduce the reliability. Your biggest fail point will be the network hardware. Making sure electrical surges are prevented on both the controller power, the switch power and the ethernet ports will do way more for the reliability of the system than anything else. Of course you are dealing with engineers who probably do not have that experience, so they will insist on mucking up the works.
In order to sync vars in both directions, you have to keep in mind that if there is a problem with the primary, then the secondary will have to operate a power relay and reboot it, so all that logic has to be in place to make the primary reboot, have a timer that waits for the primary to reboot, then you can’t have the primary booting up on line…so it starts getting very complicated because all this stuff doesn’t necessarily go like you would like it to.
Pac Display Pro fortunately has a very nice feature that automatically detects the failure of the primary and picks up the secondary (with separate IP), unfortunately, no other Opto22 software does this, so if you are going to do this, then I recommend using Pac Display, otherwise, you might be able to pull this off in Ignition. When I did the ROK, I had no idea what using Groov View was like and the limitations, and therefore it is a sad implementation where I have 2 - Groov servers and a graphic that indicates you need to open the other server…
Keep in mind, that the Opto ROK kit does work, maybe a little bit too good, because pretty much anything can trigger a switchover, which doesn’t necessarily solve anything. So for instance, if any one of the brains on the network are powered down, even for a power blip seperate from the controller, the system switches over and reboots the primary. In other words, anything that interrupts comm, will initiate a switchover. I have had several cases where I could not figure out what caused the problem, because the system reboots the primary and then you have no debug info because that gets wiped.