A line stops mid-shift. Within one second, twenty rows appear on the alarm list: low pressure, motor overcurrent, an interlock, a valve position deviation, five follow-on alarms. The operator looks at the list and draws the only possible conclusion: something broke. Which came first — the interlock or the pump stopping — cannot be told, because every row shows the same second.
This is the everyday problem of alarm management, and it is not solved by adding more alarms. It is solved by preserving information that already existed in the automation system: the order in which events occurred. OPC UA alarms carry that information with them, provided they are read using the standard's own alarm model rather than being polled like measurement values.
This article goes through what the OPC UA Alarms & Conditions model defines, how alarms are read from an existing system without changes, why timestamp precision decides root cause analysis — and what is worth calculating from alarm history once the burst is over.
Why OPC UA alarms are their own kind of data
Collecting process data and collecting alarms look like the same job on the surface: in both, values are read from the automation system and stored in a database. In practice they are different things, and confusing the two is the most common reason why alarm history yields nothing useful afterwards.
A measurement value is a sample. It describes a quantity at a given moment, and together the samples form a continuous time series. If one sample is missing, the curve still makes sense — a trend survives a gap.
An alarm is an event. It has a precise moment of origin, a state, a severity, a source and a life cycle: it is raised, possibly acknowledged, and it returns to normal. An event is not a sample that can be taken again. If it is lost, or its timestamp is replaced, the information is gone permanently.
The difference shows up immediately in practice. In a typical arrangement an alarm is read like a variable: every second, the system asks whether a bit is set. Two problems then follow inevitably:
- An event shorter than the poll interval disappears. An alarm that is raised and cleared within the same second never appears in the poll at all.
- The timestamp is created in the wrong place. The moment recorded is when the poll happened to land — not when the event occurred. The poll interval and network latency get mixed into it.
This is exactly why the OPC UA standard has a separate alarm model. OPC UA alarms are not variables to be read, but events the server publishes.
What Alarms & Conditions (Part 9) defines — and how alarms are read
Alarms & Conditions is Part 9 of the OPC UA standard. It defines how a server presents alarms and events: what fields they carry, how state changes, and how a client subscribes to them. It is, in other words, a shared language spoken by every OPC UA compatible system — Siemens, ABB, Valmet, Beckhoff, Schneider Electric, Honeywell and Rockwell.
At the core of the model is the distinction between a condition and an event. A condition is a lasting state, for example "tank level above the upper limit". An event is the moment something changed: the condition was raised, acknowledged or cleared. Over its life cycle one condition produces several events, and it is their order that tells you what happened in the process.
Every event carries a set of standard fields, four of which decide the investigation:
Source (SourceNode)
Which device or part of the process produced the event. This binds the alarm to a physical object rather than to a piece of text — and makes filtering by area possible.
Timestamp (Time)
The moment the event occurred according to the server. This is the most valuable field in the whole model, and it is also the field most often lost along the way.
Severity
A numeric classification from 1 to 1000. It lets background noise be separated from critical events without reading every row by hand.
Message and condition name
A verbal description and the identifier of the condition. These are what search relies on when the device tag is not remembered but the wording of the alarm is familiar.
Reading happens as a subscription, not as a poll. The client tells the server once which events it is interested in, and the server sends them as they occur. This is an important difference: a subscription has no poll interval for an event to fall between.
The practical consequence is that commissioning alarm collection does not touch the automation system at all. The subscription is made to an existing OPC UA server, which is typically already running for a SCADA system or another client. DataPortia™, for instance, acts here as a pure OPC UA client: it subscribes to events through the Alarms & Conditions interface, writes nothing back, and requires no changes to the logic or the display graphics.
One prerequisite is worth checking in advance
The server has to publish events according to the Alarms & Conditions model. Not every system has an equally complete alarm model, and a limited model shows up directly in what can be established from history afterwards. It is worth confirming this before setting targets for alarm analysis.
The timestamp decides the root cause: one millisecond at a time
When twenty alarms are raised within the same second, the root cause can be separated from its consequences in exactly one way: by order. Not by severity, not by the wording of the message, not by what happens to be at the top of the list. By order.
That is why handling the timestamp is the single most important technical choice in alarm management, and it is also the only point at which OPC UA alarms can lose their most valuable property unnoticed. Three common approaches produce three entirely different outcomes:
| Stored timestamp | What it can establish | What has been lost |
|---|---|---|
| Server timestamp, millisecond precision | The relative order of events, even within the same second | Nothing |
| Timestamp rounded to the second | Only which events fell within the same second | The order inside the burst — permanently |
| Database write time | The order in which events happened to arrive | The true order of origin; network and queue latency are mixed in |
The middle row is the one you meet most often. Rounding never looks like an error at any point: the alarms are stored, the list looks tidy and the report is produced. Only in the first real investigation does anyone notice that the question "what was raised first" no longer has an answer — and it cannot be recovered with any tool, because the information was destroyed at the moment of storage.
Sequence of events (SOE) analysis simply means arranging events by their original timestamp and looking at the start of the chain. It is a modest method, and that is precisely why it works — as long as the source information is intact.
- 1 ms
- is the precision at which the order inside a burst is still visible. Rounded to the second, twenty events have more possible orderings than anyone could rule out by inspection — which amounts to no information at all.
A practical example: a district heating plant stop and a burst of twenty rows
District heating plant: the same stop at two timestamp precisions
Practical example
Timestamp rounded to the second
- The boiler feedwater pump stopped during the night shift
- 21 rows accumulated on the alarm list, all with the same second
- The order on the list was determined by write order
- Two candidates in the investigation: the low-pressure interlock or motor overcurrent
- Which one was the cause remained guesswork
- Corrective action was aimed at both — wasted work on one of them
Original server timestamp in milliseconds
- The same 21 events, the same second
- The first event stood out: the low-pressure interlock, 340 ms ahead of the rest
- Motor overcurrent followed 180 ms later — a consequence, then
- The remaining 19 rows were consequences of the chain, not separate faults
- The investigation focused on suction-side pressure, not on the motor
- The same view was exported into the deviation report as it stood
What is worth noting is that in both cases the automation system produced exactly the same information. The difference arose only in what was stored from it. In the left-hand case all 21 events are still in the database — only their relative order is missing, and it can no longer be restored.
In practice, the working order for unpicking a burst is usually the same: narrow the time window around the stop, narrow the area to the part of the process where the chain began, and look at the first event in the chain. When alarms and measurement data live in the same time-series database, the same window can also be viewed as trend curves — and then you can see what pressure and flow were doing during those 340 milliseconds.
Three analyses that show where the alarm load comes from
Investigating a single stop is the use case OPC UA alarms are most often collected for. In day-to-day work, however, a different question is more useful: why does the list contain hundreds of rows every day that nobody reads? Three calculations answer it, all of them made from the same event history.
| Analysis | Question it answers | What you do with it |
|---|---|---|
| Pareto | Which alarms repeat most often? | The top of the list reveals the handful of points that fill the list day after day. The cause is usually a setpoint, a delay or a chattering contact. |
| Duration | Which ones stay active longest? | An alarm that is raised rarely but stays on for a week does not stand out in counts at all — it is found only by measuring duration. |
| Severity | How much of it is genuinely critical? | The distribution across severity classes shows how much of the list is background noise. It is also the best basis for deciding what to filter out. |
The result of these three is almost always the same observation: a very small group of measurement points produces the bulk of the row count. Once the top ten points have been dealt with, the length of the alarm list typically collapses — and only then does the list become readable again.
When alarm history sits in the same database as the measurement data, the analysis can also be extended to free-form questions about the material. DataPortia's AI module runs a language model on the plant's own server and reads the same data, so an alarm period can be reviewed without the material moving anywhere.
Where alarm analysis is not enough
In fairness, it is worth stating what an arrangement like this does not do.
- Precision cannot be improved after the fact. If the automation server stamps events to the second, no tool can bring the order back. Storage can preserve what the server provides, nothing more.
- Clocks across servers must be synchronised. If alarms are read from two systems, the order between servers is reliable only if the clocks agree. This is often forgotten.
- A person draws the conclusion. The analysis gives order, counts and durations. What they mean in the process is known by the people who know the plant.
- Delivering notifications is a different matter from history. Alarms are visible in the browser interface and in the reports compiled from it. SMS notifications are not available, so alerting the on-call engineer is still handled by whatever system you already use for it.
These limits are worth knowing in advance. They do not prevent the benefit, but they define what can honestly be promised to your own organisation about alarm history.
Summary: OPC UA alarms as a tool, not noise
The hardest part of alarm management is not getting OPC UA alarms collected. It is preserving the information that already existed in the automation system and disappears unnoticed on the way to the database.
The key points:
- An alarm is an event, not a sample. Read by polling, it loses both short spikes and its true moment of origin.
- Alarms & Conditions is the standard's own model. It works with every OPC UA compatible system and requires no changes to the automation.
- The timestamp is the critical point of the whole chain. A timestamp rounded to the second destroys the order permanently.
- Pareto, duration and severity show where the load comes from. A handful of points usually produces most of the rows.
- The limits are worth saying out loud. Storage does not improve the precision of the source system, and a person still draws the conclusion.
When alarms, measurement data and reporting are part of the same whole on the plant's own server, the investigation is completed in the same view where it was carried out — without moving the material anywhere. Try DataPortia free for 30 days: the trial includes every feature apart from the HA add-on and commits you to nothing, and alarms are read straight from your own automation system's Alarms & Conditions interface. Only then will you see whether the true first event stands out from your own burst.