I would agree with jerry.bradford. Its important to differentiate between redundant communications (a feature of PACProject Professional HW to enable the second Ethernet port) and redundant controllers, where a secondary “standby” controller takes over control of the program if it detects a failure in primary “running” controller.
While redundant comms are handled by the operating system, the use of redundant controllers requires the functionality to be developed as part of your application software under PACControl.
This is the same as many PLC’s that offer “redundancy”. Only a few high end models include controller redundancy at the operating system level. The rest depend on application software, examples of which are usually supplied by the manufacturer. Maybe someone nice in Opto22 could develop an example strategy for PAC hardware.
Use 2 PAC-S controllers (S1 or S2) to talk through a switch to one or more SNAP-PAC-EB1 o SNAP-PAC-EB2 brains. If you are seriously implementing redundancy you should also consider the use of separate power supplies for each SNAP-PAC-S controller and a diode arrangement for dual 5VDC power supplies for the PAC-EBx brains.