Alarm Communication Best Practice

Hello All! I have a question about communicating alarms from a plc/controller to another plc/controller. Generally I am looking for the best practices or industry standard approach. For instance, I need a controller/plc (called "PLC1") to gather alarm information from another controller/plc (called "PLC2")that does all the actual alarm detection. I could have PLC1 poll PLC2 for the data or I could have PLC2 push data to PLC1 only when an alarm or event that I care about happens. An upside to the first method would be that changes to programming will only need to be done at PLC1. But a downside is that the constant polling will unnecessarily use some bandwidth and processor time (which may or may not be a problem). The second method will surely save on bandwidth & processor time but will require programming at both PLC1 & PLC2. Do you have any thoughts on what a best practice or industry standard approach to this would be? Thanks for your time : )

Bandwitdh is not really a problem these days. What kind of PLCs and network type is it ?

But I would worry about that PLC1 would be dependent on PLC2. If PLC2 is down, what about PLC1 ? Wouldn't that nullify the advantage of having independent CPUs ?

Current HMIs have no problems with handling alarms from multiple CPUs.
The programming effort to have alarms in 2 PLCs in stead of 1 is nothing. You use the same code in both PLCs.

So I think there is only disadvantages to putting all alarm handling in 1 PLC when you physically have 2 PLCs.

I see your point. Thank you! It definitely does not make sense to duplicate the information if we dont have to and make some alarm information dependent on two controllers. We are currently using an Opto22 HMI and need to pull alarms from a modicon. I will investigate how well Opto22 plays with others : )