The SilenceState is just a state in the Alarm model that allow an alarm to be silenced. We do not have a model for signaling device and the interaction with them. I do not believe that this issue is a part 9 issue. I would think this issue should actually be an Part 200 issue, in that the part 200 should describe how it interface with an alarm model. As a note, when an alarm is silenced - it is not the device that is silenced, but the specific alarm. so if a horn has three alarms that can trigger it - a silence on one alarm does not affect the other two

Agreed to move to Part 200.

@Paul: I cannot fully subscribe to your point of view that the silence state is related with the alarm but not the signaling device. Yes of course it may be required to being able to trace via which alarm one or multiple signaling devices have been silenced. However, if a plant operator is in a critical situation, means multiple alarms requiring user action, forces the operator to identify them all in the alarm summary to silence devices first - "to get rid of the annoying noise" - before handling alarms one by another may could increase the stress level of the operator(s).

Discussed in Harmonization WG meeting:
The stacklight model is just a representation of a physical stacklight in OPC UA. It does not define any relation to when it switches to any color or plays an acoustic signal.
We will improve section 5.1 explaining this in more detail. It is not forbidden to add information on how to control the stacklight, but it is intentionally not addressed in Part 200.

It seems to us that the request of the mantis issue should not be on the stacklight anyhow, but you rather would silence the signal / alarm that would trigger a change to the stacklight.
If you want to silence an alarm, this is already available in Part 9 (see Pauls comment).

Fixed in version 1.01.3

Reviewed in meeting on the 12th of February 2024 and agreed on changes.