Alarm and Event Ingestion: How Industrial Control Systems Feed Your Notification Platform

There is a step in industrial alarm management that most documentation skips over. Standards like ISA-18.2 and EEMUA 191 define how alarms should be designed, prioritised, and managed. Escalation and notification platforms define how alarms reach people. But between the control system generating an alarm and a notification platform acting on it, there is a layer that neither side fully explains: alarm and event ingestion.

Getting this layer right determines whether a notification platform sees every alarm that matters, with enough context to route it correctly. Getting it wrong means alarms that fire in the control system and go nowhere.

What Alarm and Event Ingestion Is

Alarm and event ingestion is the process by which a notification platform reads alarm and event state data from one or more industrial control systems and uses it to trigger notification workflows.

The term covers three distinct things that often get conflated. First, the connection between the notification platform and the source system: how data physically moves between them. Second, the filtering and mapping logic: which alarm states trigger a notification, and what data travels with them. Third, the normalisation layer: how data from different source systems is translated into a consistent format the notification platform can act on.

All three matter. A platform that connects but maps incorrectly will route alarms to the wrong people. One that connects and maps correctly but lacks normalisation cannot handle a multi-system environment consistently.

Alarms, Events, and Why the Distinction Matters

One of the most common points of confusion in alarm and event ingestion is the difference between an alarm and an event, and why a notification platform needs to handle both.

In industrial control systems, an alarm is a condition that requires operator action. It has a defined priority, a set point, and an acknowledgement mechanism. An event is a record of something that occurred: a mode change, a setpoint modification, an operator login, or a system status change. Events do not necessarily require action, but they provide the context that makes alarm response effective.

A well-configured alarm and event ingestion layer captures both. When a high-pressure alarm fires, the notification platform should know not just that the alarm is active, but what the current value is, what the limit is, what the priority level is, and what recent events in that process area are relevant. That context is what allows a technician receiving a notification at 3 a.m. to make an informed decision before arriving at the equipment, not after.

Ingestion systems that capture alarms only, without event context, produce notifications that are technically accurate but operationally thin.

The Three Ingestion Paths and When to Use Each

Many manufacturing facilities run multiple PLCs, one or more SCADA or HMI platforms, a process historian, and potentially a manufacturing execution system, often from different vendors and each with its own alarm architecture. Alarm and event ingestion has to handle all of them.

OPC-based ingestion is the established open standard for moving alarm and event data from control systems to third-party platforms. Two specifications are in active use.

OPC A&E (Alarms and Events) is the classic specification. It operates on a client-server model in which the OPC A&E server collects alarm and event data from PLCs, SCADA systems, and DCS platforms, and exposes it to subscribing clients. Critically, OPC A&E delivers alarms that originate inside the control system itself, complete with the system’s own alarm logic, priority classification, and acknowledgement state. This is meaningfully different from inferring alarm conditions by polling tag values from outside the system (OPC Expert).

OPC UA Alarms and Conditions (A&C) is the modern successor. It adds platform independence, built-in security, and subscription-based delivery, meaning the server pushes notifications to clients when alarm conditions change rather than waiting to be polled. OPC UA A&C is increasingly specified for new installations (OPC Foundation).

More about OPC UA integration for alarm management.

Native platform integrations are the alternative to OPC for facilities running major SCADA and HMI platforms with direct API or middleware connections available. Rockwell Automation FactoryTalk, AVEVA System Platform, GE Vernova’s iFIX and CIMPLICITY, and others expose alarm data through proprietary interfaces. A notification platform with native integrations to these systems can ingest alarm state without an OPC server in the middle. This reduces the number of components in the integration stack and eliminates the OPC server as a potential point of failure. Many engineers prefer native integration to OPC where both options are available, precisely for this reason.

Historian-based ingestion applies where the process historian is the central data repository and alarm event records flow through it. Platforms such as AVEVA PI aggregate time-series data and event logs from multiple upstream sources. For facilities where the historian already serves as the integration hub, a notification platform that can read from it directly avoids duplicating connections to every upstream source. This path is most relevant in large, multi-vendor installations rather than simpler single-SCADA environments.

Choosing the Right Path for Your Environment

Most plants will use more than one ingestion path simultaneously. A facility might use a native Rockwell integration for FactoryTalk alarms in the main production area, OPC A&E for a legacy DCS managing utilities, and direct PLC polling for standalone equipment that has no SCADA layer above it.

The decision for each source system comes down to three questions. Does the source system have a native integration available from the notification vendor? If yes, use it. If not, does the source system support OPC A&E or OPC UA? If yes, use OPC. If neither, can alarm conditions be inferred from tag polling, and is that level of fidelity acceptable for the alarms in question? The answer to the third question is often no for safety-critical alarms, where the alarm state inside the control system and the state inferred from tag values can diverge.

The practical implication is that alarm and event ingestion architecture is a design exercise, not a plug-and-play setup. It requires knowing which source systems are in scope, which protocols they support, which alarms need to be captured, and what event context needs to travel with each one.

What Should Travel With Every Alarm

The ingestion layer does not just pass a trigger to the notification platform. The value of well-configured alarm and event ingestion is the data payload that accompanies each alarm.

At minimum, a notification platform needs the alarm tag name, the alarm description, the current process value and the limit that was breached, the alarm priority, the timestamp of the alarm condition, and the alarm state: active, acknowledged, or returned to normal. This set of fields is what allows the notification platform to route the alarm to the right person and populate the notification with actionable information.

Beyond the minimum, event context from the same process area adds significant value. A sequence of operator events immediately before an alarm fires can indicate whether the condition was anticipated, whether a setpoint was recently modified, or whether a mode change is relevant to the response. Notification platforms that can surface this context in the notification itself reduce the back-and-forth between the responding technician and the control room.

How SeQent Handles Alarm and Event Ingestion

SeQent Alarm Management supports alarm and event ingestion from SCADA, MES, HMI, PLC, and historian sources through a combination of native integrations and OPC. Supported platforms include Rockwell Automation FactoryTalk, AVEVA System Platform and PI, GE Vernova iFIX and CIMPLICITY via the Velotic partnership, and any OPC DA, OPC A&E, or OPC UA compliant source.

Once an alarm is ingested, FPAM applies routing logic to determine who should be notified, on which device, and within what timeframe. If the alarm is not acknowledged, FPAM escalates automatically through a pre-configured hierarchy. Every ingested alarm, every notification, every acknowledgement, and every escalation step is logged with a timestamp, creating a complete and auditable record from detection through resolution.

SeQent has spent 30 years building and maintaining connections to the control systems that run industrial plants. The ingestion paths that work in a real-world, multi-vendor environment are well understood from that experience.

Want to understand how FirstPAGE Alarm Manager connects to your specific control systems? Request a demo at seqent.com/contact/.

Sources

• OPC Expert. What Is the OPC A&E Protocol? https://opcexpert.com/opc-faq/what-is-the-opc-ae-protocol/

• OPC Foundation. Multi-Vendor Alarm Integration with OPC UA. https://opcconnect.opcfoundation.org/2022/09/multi-vendor-alarm-integration-with-opc-ua/

• Software Toolbox. What is OPC A&E? https://softwaretoolbox.com/resources/what-is-opc-ae