Alarms and Conditions

Unlike simple threshold violations, A&C implements a state machine for each alarm. An alarm transitions through distinct states—Inactive, Active, Acknowledged, and Confirmed—providing a complete lifecycle. This ensures that an operator's interaction with an alarm is tracked, preventing critical events from being lost or ignored. The model mandates that an alarm must return to an inactive state before it can become active again, preventing duplicate flooding.

A&C defines a rich object-oriented hierarchy rooted in the ConditionType. Key specializations include:

• AlarmConditionType: For states that require operator acknowledgment.
• LimitAlarmType: For violations of a process limit (e.g., High, Low, Deviation).
• DiscreteAlarmType: For digital on/off states like a safety interlock trip.
• CertificateExpirationAlarmType: A system-level alarm for expiring security certificates. This hierarchy allows Clients to generically handle any alarm while understanding specific semantics.

A&C introduces a two-stage human interaction protocol to ensure accountability:

1. Acknowledge: An operator explicitly signals they have seen the active alarm. The alarm transitions from Active to Acknowledged.
2. Confirm: A separate action indicating the root cause has been resolved. The alarm transitions from Acknowledged to Confirmed. This separation provides a clear audit trail, distinguishing between merely seeing a problem and actually fixing it. The ConfirmedState property tracks this final resolution.

To manage alarm floods during known maintenance or transient conditions, A&C provides suppression mechanisms:

• Shelving: Temporarily suppresses an alarm for a defined time period or until a specific condition clears. The alarm remains logically active but is hidden from the main operator view. A ShelvingState tracks this.
• Out of Service: An administrative state that removes the alarm from all processing, typically used during sensor calibration or replacement. These features prevent operator overload and maintain the integrity of the alarm system during abnormal plant states.

Alarms are delivered to Clients using the standard OPC UA MonitoredItem and Subscription mechanism, but with a critical distinction: the Retain flag. When a Client subscribes to an alarm, the Server immediately sends the current state of all active alarms (Retain=True). Subsequent state transitions are sent as live events. This ensures a newly connected Client always has a complete, current view of all active plant disturbances without waiting for a new occurrence.

A&C supports vendor-specific extensions through the concept of a Dialect. A Dialect is a URI that identifies a specific set of fields included in the alarm notification. This allows vendors to add proprietary diagnostic data (e.g., a specific machine vibration signature) to a standard alarm event without breaking interoperability. Clients can browse the supported Dialects on a Server and select the one that provides the richest context for their specific operational needs.

Every alarm follows a deterministic lifecycle with well-defined states and transitions:

• Inactive: Normal operating condition, no alarm present
• Active/Enabled: Abnormal condition detected, alarm is raised and requires attention
• Acknowledged: Operator has seen the alarm but the root cause may still exist
• Confirmed: The underlying condition has returned to normal and the alarm can clear
• Shelved: Alarm is temporarily suppressed by an operator for a defined period

This state machine ensures auditable operator response and prevents alarms from being silently lost.

Alarms and Conditions are fundamentally event-driven, not data-driven:

• Data Access provides the current value of a variable (e.g., temperature = 85°C)
• Alarms & Conditions provide stateful notifications that persist until resolved

Key implication: An alarm remains retrievable and auditable even after the triggering value returns to normal. This enables post-incident forensics and regulatory compliance reporting that simple threshold monitoring cannot provide.

OPC UA defines a type hierarchy for different categories of abnormal situations:

• AlarmConditionType: Requires operator acknowledgment, represents a safety or process risk
• AcknowledgeableConditionType: Requires acknowledgment but may not be safety-critical
• ConditionType: Base type for any stateful event, including informational conditions
• DialogConditionType: Requires a user response with predefined options
• CertificateExpirationAlarmType: System-level alarm for expiring security certificates

Each class inherits behaviors and adds domain-specific properties, enabling rich semantic modeling of industrial events.

Two critical properties govern alarm lifecycle and prioritization:

• Retain: A boolean flag indicating the alarm remains in the system's active list even after the triggering condition clears. This ensures no alarm is lost during transient network issues or operator shift changes.
• Severity: An integer from 0–1000 defining urgency, where 1–333 is low, 334–666 is medium, and 667–1000 is high. Severity can be dynamic, increasing over time if an alarm remains unacknowledged.

These properties enable escalation workflows and ensure critical alarms surface above informational noise.

OPC UA provides controlled mechanisms for temporarily suppressing alarms without disabling the underlying monitoring:

• Shelving: An operator intentionally suppresses an alarm for a defined time period. The alarm state machine continues to run but notifications are withheld. Shelving is audited and automatically unshelves when the timer expires.
• Out of Service: An engineering state that removes the alarm from active processing, typically used during maintenance. Requires explicit re-enabling.

These mechanisms prevent alarm flooding during planned maintenance while maintaining a complete audit trail of who suppressed what and when.

When a new OPC UA Client connects or reconnects after a disruption, it can issue a ConditionRefresh request to the Server. The Server responds by re-sending the current state of all active alarms and conditions.

This mechanism solves the lost alarm problem in distributed systems:

• New operator workstations receive the complete alarm picture immediately
• Clients recovering from network outages do not miss state transitions that occurred while disconnected
• Enables hot-standby redundancy for alarm management systems

ConditionRefresh is essential for building resilient, multi-client HMI and SCADA architectures.