I want to acknowledge the alarms for both independent gateways. Assuming both gateways have the same set of users and tag sources, Gateway 2 will acknowledge the same set of alarms, including notes and user information, as acknowledged on Gateway 1. It seems we may need to use system.alarm.queryStatus along with system.alarm.acknowledge to implement this. Are there any examples available, or alternative suggestions?
Typically, Gateway2 is configured with a Remote Tag Provider to provide access to tags of Gateway1, whereby all execution (tag writes, alarms, history, etc.) is handled by a single gateway.
If this arrangement doesnt work for you, can you describe your architecture in a bit more detail?
The following figure represents my intended architecture. A copy of the same project will reside on both redundant gateways, Gateway 1 and Gateway 2. Both Gateway 1 and Gateway 2 receive data from the same sensors. My goal is to auto-acknowledge alarms on one gateway when they are acknowledged on the other, regardless of whether it’s Gateway 1 or Gateway 2.
So this isn't a typical architecture. At least not one I've seen a need for. Is there a specific reason that leads you to this architecture?
Typically, you would only have one redundant pair. Dual gateway pairs, as you have described, are typically implemented in a scale-out architecture.
You could use system.util.sendMessage | Ignition User Manual to generate a message to another gateway, and then ingest that message and acknowledge alarms properly. However, you will need to be very careful to avoid a storm of messages ping-ponging between the gateways.
1 Like
I would think to send the message to another gateway using Alarm Acknowledged from the Tag Scripting. And another Gateway Message Handlers to acknowledge the same sourcepath alarm. It may cause the looping between the gateways. Is there a way to prevent this loop 
?
I am pretty sure you can set up an “ack” alarm pipeline on each tag, then use the pipeline script block to log the ack event to a database table. I would probably utilise a table that is shared by the two gateway sets , and when an ack is registered against a tag and alarm name, poll the db to propagate this to the other gateway. You could use update queries to indicate that an ack has been actioned by each gateway, but the table would be your source of truth.
DB could be useful for other purposes. Might impose a bit of excess overhead during a flood of alarm events.
Another option: Within the message handler receiving a message from the other gateway, add a note with predefined text to each acknowledgement (AlmHandler: Remotely Acknowledged By:...)and filter on any notes beginning with the same prefix in the alarm pipeline?