OPC UA SCADA Acknowledgement: Bind the Action to the Reported Event State

An operator can select an alarm row while newer notifications for
that condition are still arriving. If the SCADA client replaces the
selected row’s EventId with the latest one before sending Acknowledge,
the resulting command can target a different reported state from the one
the operator reviewed. Preserve the selected event-state identity
through the command handoff.

This article uses OPC UA Part 9, Alarms & Conditions, version
1.05.06. It covers acknowledgement and confirmation identity in a SCADA
client, not automatic operation of a live plant. No method calls or
alarm-system tests were performed.

Keep the selected state
immutable

The Acknowledge
method contract uses an EventId to identify the particular
notification state being acknowledged. ConditionId can supply the
ObjectId even when the condition instance is not exposed as a browsable
object. The AcknowledgeableConditionType node itself is not a valid
substitute for the target instance.

At selection time, capture the server context, condition identity,
branch identity and EventId with the displayed state. Branch identity is
useful application context; the method’s defined inputs are EventId and
a localized comment, rather than an invented BranchId argument.

Consider a hypothetical condition that generates state E1, then E2
while an acknowledgement dialog is open. The dialog should retain what
the operator selected. If the application instead intends the action to
cover the newest state, it needs an explicit interaction that shows that
changed target. Silently looking up the latest EventId at submission
time changes the action’s meaning.

Interpret
stale-state results without retargeting

The method defines distinct outcomes for an unknown EventId, an
already acknowledged branch and an invalid method or object context.
Preserve those distinctions in the command record. An unknown identifier
does not authorize substituting a different event automatically.

If the server no longer recognizes the selected state, refresh the
displayed condition information through the supported client path and
ask the operator to review the current target. This is an application
interaction recommendation, not a new OPC UA method requirement. It
avoids converting recovery from an old selection into acknowledgement of
an unseen state.

A valid acknowledgement produces an updated event with AckedState/Id
true. When a previous state is acknowledged, the notification identifies
that branch and its condition values. Reconcile that result with the
selected state rather than clearing every row sharing the same source
name.

Keep confirmation separate

The Confirm
method also targets a particular EventId, but acts on
ConfirmedState. The conditions that make confirmation necessary are
server-specific and can vary by event or condition. Do not make a
successful Acknowledge response trigger Confirm automatically as a
generic UI convenience.

Where confirmation is supported, expose it as its own permitted
operation and preserve its selected state in the same way. The
confirmation result can report that a branch was already confirmed or
that the EventId is unknown. Those outcomes should not be collapsed into
a fresh command against the latest row.

Comments also have a defined distinction: a null localized comment
leaves the existing comment unchanged, whereas an empty text with a
locale resets it. A blank UI field therefore needs an intentional
mapping. Do not let an incidental serialization default erase an
operator’s earlier annotation.

Test the selection-to-submit
race

Use an isolated alarm simulator with controllable condition
transitions. Open an acknowledgement dialog for E1, inject E2, and
inspect the command that would be submitted. Repeat with a retained
previous branch and with an EventId the simulator has deliberately
retired.

Also test delayed command results after the visible row has changed,
and separate acknowledgement from confirmation. The expected behavior
should explain which selected state each action addresses and how the
resulting event updates that state.

No universal retry policy is implied. The acceptance contract is
narrower and observable: the operation sent corresponds to the state
reviewed, stale-target failures remain visible, and a newer event cannot
silently rewrite an already selected operator action.