OPC UA Alarms and Events vs. Tag History: What Should Your Historian Capture?

A pressure trend can show when a pump moved outside its normal range. It cannot, by itself, show which alarm object changed state, what severity the server reported, or when an operator acknowledged that alarm.

Those answers come from different OPC UA records. Ordinary tag history stores sampled or reported variable values. OPC UA Events report occurrences. Alarms and Conditions add a stateful model for conditions that can become active, return to normal, require acknowledgment, or retain previous branches. A useful historian design starts by deciding which questions each record must answer.

Tag history preserves process behavior

An OPC UA client normally collects a variable through a monitored item. When the value or status meets the configured DataChange criteria, the server sends a DataChange notification containing a DataValue. The historian can store the value, source timestamp, server timestamp, and StatusCode, depending on the collector mapping.

That record is suited to questions such as:

• How high did discharge pressure rise?
• How long was the motor running?
• Did temperature change before the trip?
• Was the value Good, Uncertain, or Bad?

Sampling, deadbands, queues, and timestamp selection determine how much of the process behavior survives. The earlier guide to OPC UA timestamps in historian storage explains why the source, server, and receipt times should not be treated as one clock.

Events preserve occurrences and their context

OPC UA Events are not ordinary value changes with a different label. A client monitors an EventNotifier and uses an EventFilter to select the event types, sources, and fields it wants returned.

Fields defined by the OPC UA event model can include:

• EventId and EventType, which identify the notification and its type.
• SourceNode and SourceName, which identify where it originated.
• Time, which is set as close to the event generator as possible.
• ReceiveTime, which records when the OPC UA server received the event.
• Message and Severity, which provide human and priority context when the event type supplies them.

The historian’s ingestion timestamp is a separate time. It may help diagnose transport delay, but it should not silently replace the event’s occurrence time. Preserve both when delay analysis matters.

An ordinary Event can be a one-time occurrence, such as a system start or an audit action. It does not need to represent an ongoing abnormal state.

Alarms and Conditions add state and operator workflow

The OPC UA Alarms and Conditions model extends the base Event model. A Condition represents a stateful situation associated with a source. Alarm types add state related to abnormal process behavior.

Depending on the alarm type and server implementation, an event notification can carry information such as ConditionId, BranchId, ActiveState, AckedState, ConfirmedState, Retain, limits, comments, and the user associated with an action. EventId identifies a specific event notification and is used when acknowledging or confirming the relevant condition state.

This distinction matters because one alarm occurrence can produce several records. A high-pressure condition may become active, be acknowledged, return to normal, and later be confirmed. Each transition changes the investigation timeline. If rapid changes create previous unacknowledged states, Condition branches can preserve those states until the required action occurs.

Not every server supports every alarm type, field, branch behavior, or method. The client also receives only the fields selected through its EventFilter. Confirm the server and collector behavior rather than assuming a complete alarm model is present.

Why a Boolean alarm tag is incomplete

A Boolean HighPressureAlarm tag can show false, then true, then false. That is useful, but it usually cannot answer:

• Which event occurrence was acknowledged?
• Did severity or message change while the alarm remained active?
• Who acknowledged it, when, and with what comment?
• Was a previous condition branch still awaiting action?
• Did a queue overflow or filter omit a transition?

A Boolean trend also depends on variable sampling and queue configuration. A short state transition can disappear if the collector never receives it. Native alarm records identify transitions in the condition lifecycle rather than reducing that lifecycle to one current-state value.

Keep the Boolean tag when it helps dashboards or simple queries. Do not treat it as a replacement for event and alarm records when acknowledgment or sequence reconstruction is required.

Pump incident: what each record explains

Consider a pump whose discharge pressure rises above a configured limit. The alarm activates at 10:14:02. An operator acknowledges it at 10:14:20. Pressure returns to normal at 10:15:07.

Pressure and motor-status history can show the process trajectory: the peak, how long pressure remained high, whether the motor stopped, and whether the reading quality changed. It cannot prove that the server issued an alarm, identify the alarm severity, or show the acknowledgment action.

Alarm records can show the active transition, EventId, source, message, severity, acknowledgment transition, user context if provided, and return-to-normal transition. They may not contain the full high-resolution pressure waveform. A sound incident record therefore keeps both the process series and the selected alarm lifecycle fields.

Subscription is not the same as event history

An event subscription normally reports transitions after monitoring begins. ConditionRefresh can request the current retained Condition states so a client can rebuild a current alarm display after connecting. It is not a general replay of every earlier event.

OPC UA Historical Access defines services for reading stored Events from servers that expose historical event nodes. Support and retention are optional. A server that produces live alarm notifications does not automatically keep a queryable event archive. The collector must also support the required historical access if backfill is part of the design.

Write the recovery requirement explicitly: live transitions only, current retained states after reconnect, or historical event backfill. Then test that exact behavior.

Validate the historical record before an incident

Use a controlled alarm lifecycle and compare the OPC UA client view with stored rows. Confirm that the selected fields retain event identity, source, event time, receive or ingestion time, severity, message, condition state, and acknowledgment context required by the site.

Test reconnects, client restarts, server restarts, queue pressure, and duplicate timestamps. Verify whether current states are refreshed, older transitions are replayed, duplicates are handled, and missing records are visible. Finally, run the investigation query that engineers will use. A complete source payload is not useful if the storage schema or query discards its distinguishing fields.

Capturing OPC UA alarms and events in TDengine

TDengine TSDB Enterprise documents a dedicated OPC UA Alarm and Event collection mode in taosX. The current OPC UA Alarm and Event collection guide describes subscriptions with EventFilters, separate handling for ordinary Events and Alarms, one stored row per alarm state transition, and fields selected from the event type.

That capability is different from ordinary point collection. It also depends on what the server exposes and what the task selects. Validate the resulting schema and lifecycle against the source before relying on it for investigations.

For teams building an industrial historian on a time-series database, keeping process values and alarm transition records available for correlation preserves more of the incident than either record type alone.