Global – October 27, 2026 -- A pump pressure trend shows when a value left its normal range but cannot show which alarm changed state, what severity the server reported, or when an operator acknowledged it. Those answers sit in separate OPC UA records, and historian designs must decide which questions each record has to answer.
Tag history stores values, not alarm lifecycles
An OPC UA client collects a variable through a monitored item. When DataChange criteria are met, the server sends a DataValue that the historian can store with source timestamp, server timestamp, and StatusCode, depending on the collector mapping. Sampling, deadbands, queues, and timestamp selection determine how much process behavior survives.
Events carry source, time, and severity that value changes lack
A client monitors an EventNotifier and uses an EventFilter to select event types, sources, and returned fields. Fields can include EventId, EventType, SourceNode, SourceName, Time, ReceiveTime, Message, and Severity. The historian's ingestion timestamp is a separate time and should not replace the event's occurrence time; both should be preserved when delay analysis matters.
Alarms and Conditions add acknowledgment state and branches
The Alarms and Conditions model extends base Events with stateful conditions. Depending on alarm type and server implementation, notifications can carry ConditionId, BranchId, ActiveState, AckedState, ConfirmedState, Retain, limits, comments, and the acting user. Rapid changes can leave unacknowledged prior states preserved as Condition branches. Not every server supports every field, alarm type, or method, and the client receives only the fields its EventFilter selects.
A Boolean HighPressureAlarm tag cannot show which occurrence was acknowledged, whether severity or message changed while active, who acknowledged it, or whether a queue overflow dropped a transition. A short transition can vanish if the collector never receives it.
A 10:14 pump incident needs both record types
In the source example, discharge pressure exceeds its limit and the alarm activates at 10:14:02. An operator acknowledges it at 10:14:20, and pressure returns to normal at 10:15:07. Process history shows the peak, duration, motor status, and reading quality, but cannot prove the server issued an alarm. Alarm records show the active, acknowledgment, and return-to-normal transitions, but may lack the high-resolution pressure waveform.
Live subscriptions do not guarantee event backfill
Subscriptions normally report transitions only after monitoring begins. ConditionRefresh requests current retained Condition states after connection but does not replay earlier events. OPC UA Historical Access can read stored Events, but support and retention are optional, and the collector must also support it. Teams should specify whether they need live transitions only, retained states after reconnect, or historical backfill, then test that behavior.
Validation should cover reconnects, client restarts, server restarts, queue pressure, and duplicate timestamps, followed by the exact investigation query engineers will use.
TDengine documents a dedicated alarm and event mode in taosX
TDengine TSDB Enterprise describes an OPC UA Alarm and Event collection mode in taosX. It uses subscriptions with EventFilters, handles ordinary Events and Alarms separately, and stores one row per alarm state transition with fields chosen from the event type. The capability depends on what the server exposes and what the task selects, so the resulting schema and lifecycle need validation against the source.