The suppression and disable functionality defined in part 9 described in clause 7 leaves a lot of questions as to how it should work across vendor servers.

My use case is an IO Application represented by one UA Server providing flow and pressure measurements and a separate UA Server representing a Function Block Execution Engine providing a Pump Object. When the pump is stopped I want to suppress the low flow and low pressure alarms in the IO Server.

If I try to apply the original Alarm Group approach to suppression I can see how this can be implemented. In this case the HasAlarmSuppressionGroup References target a remote AlarmGroup in the Execution Engine which allows the IO Application to subscribe to the state of the Alarm Group Members (PumpStoppedAlarm in this case) allowing the IO Application to manage its own state. (See Figure 1 in the attached pdf).

Now If I try to apply the state based approach to suppression it seems like the Suppress and UnSuppress Methods would need to be used since the references are from the StateMachine toward the Alarms to be suppressed. With the references flowing from the Pump the IO would have no way to know they are expected to participate in the suppression logic. I am assuming the 2 UA server are from different vendors so no vendor magic possibility. (See Figure 2 in the attached PDF).
The spec doesn’t describe how the suppression is expected to occur but it would seem the method calls is the only way this could be implemented.

Is this what was intended by the design?
If so I’m not sure this is a good idea. For example on startup or restart of the IO Application it will have no way to determine what its state should be. This would leave it entirely up to the Pump Object to monitor the current state of each target alarm and if it wasn’t in the expected suppression state reissue the method calls. There are also a lot of failure conditions that would result in unwanted behavior.