IEC 62541 · Access type

Part 9: Alarms and Conditions

Document number	OPC 10000-9
IEC designation	IEC 62541-9
Colloquially	Part 9
Group	Access type

Conditions are stateful events

An ordinary OPC UA event is a fact that happened once. A condition is an object with state that emits events when that state changes, so the same condition can be reported many times as it becomes active, is acknowledged, and clears. The hierarchy runs ConditionType, then AcknowledgeableConditionType adding AckedState and ConfirmedState, then AlarmConditionType adding ActiveState, shelving and suppression. Below that sit the concrete alarm types.

The concrete alarm types

Limit alarms come in two flavours: ExclusiveLimitAlarmType, where the alarm is in exactly one of HighHigh, High, Low or LowLow at a time, and NonExclusiveLimitAlarmType, where several limit states can be flagged simultaneously. Alongside them are the discrete alarms - OffNormalAlarmType and TripAlarmType for a state that should not be - plus deviation and rate-of-change alarms for analogue behaviour. Choosing exclusive versus non-exclusive is a modelling decision your HMI will inherit.

Retain, refresh, and getting the current list

The Retain flag is what keeps a condition on the alarm list. It is typically true while a condition is active or unacknowledged, so an alarm does not vanish when the process recovers - it vanishes when the process has recovered and the operator has signed it off. Because alarms arrive as events, a client that has just connected has no list at all. ConditionRefresh replays the retained conditions, bracketed by refresh-start and refresh-end events so the client knows when the snapshot is complete.

Operator interaction and its optional parts

Acknowledge and Confirm are methods that take the EventId of the specific notification being acted on, plus a comment. AddComment is separate and acknowledges nothing. Shelving lets an operator temporarily silence a nuisance alarm through OneShotShelve, TimedShelve and Unshelve, and suppression lets the system silence alarms the designer knows are consequential. Confirm, shelving, suppression and the newer latched, silenced and out-of-service states are all optional, so browse before you build a workflow on them.

What it defines

Concept	What it is
ConditionType	The base stateful condition, with EnabledState, Quality, Severity, LastSeverity, Comment and the retained flag. Disabling a condition stops it emitting entirely.
AcknowledgeableConditionType	Adds AckedState and the optional ConfirmedState, plus the Acknowledge and Confirm methods. This is where operator responsibility is modelled.
AlarmConditionType	Adds ActiveState, InputNode, shelving and suppression, and the audible and alarm-metrics extensions. Everything a plant would call an alarm is a subtype.
ExclusiveLimitAlarmType	One active limit state at a time, driven by an exclusive limit state machine over HighHigh, High, Low and LowLow. Use for a single measurement with graded thresholds.
NonExclusiveLimitAlarmType	Independent flags per limit, so HighHigh and High can both be set. Use where the HMI expects each threshold reported separately.
OffNormalAlarmType	Fires when a discrete value differs from its expected NormalState. TripAlarmType is the common subtype for a tripped device.
Retain	The flag deciding list membership. An inactive but unacknowledged condition stays retained, which is exactly why alarms outlive the fault that caused them.
ConditionRefresh	A method that replays retained conditions to one subscription, wrapped in refresh-start and refresh-end events. The only way to populate an alarm list on connect.
ShelvingState	A state machine with OneShotShelve, TimedShelve and Unshelve. Operator-driven nuisance suppression with an audit trail, as opposed to muting the client.
ConditionClassId	Classifies a condition as process, maintenance, system or a vendor class. The right field to filter on when separating operator alarms from engineering noise.

Do you need to read it?

Anyone connecting an OPC UA server to an alarm client, a historian or a notification system, and anyone modelling a machine that has to report faults rather than just numbers. Also anyone computing downtime reasons: alarm conditions with a ConditionClassId and a severity are usually the only structured fault data a machine offers.

Traps that trace back to this part

• Alarms are events, not variables. You create an event MonitoredItem on a node that is an event notifier and supply an EventFilter whose SelectClauses list every field you want. Fields you do not select simply never arrive, which is why a working subscription can deliver alarms with no message, no severity and no condition name.
• Without ConditionRefresh your alarm list starts empty and fills only as things change, so a client that reconnects during a quiet shift shows no alarms while the plant is in alarm. Call ConditionRefresh after every subscription create and after every reconnect, and wait for the refresh-end event before declaring the list complete.
• Acknowledge takes the EventId of the state-change notification, not the ConditionId. That is deliberate - a newer event on the same condition invalidates the stale EventId so an operator cannot acknowledge a state they never saw - but it means you must cache the EventId of the exact notification you displayed.
• Confirm, shelving and suppression are optional and frequently absent. An HMI that shows a Confirm button against a server implementing only Acknowledge produces method-call errors in front of an operator. Browse for the methods on the condition type and build the UI from what is there.

Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.