What is OPC A&E?
OPC A&E (OPC Alarms & Events) is the OPC Classic specification that lets a server push alarms, process events and operator actions over Microsoft COM/DCOM to subscribing clients, so that alarms from different control systems can be displayed, acknowledged and recorded centrally, independent of the vendor. The OPC Foundation released the specification in 1999 as a companion to OPC DA, which delivers current process values. The last version, 1.10, was published in October 2002. Within OT and industrial automation environments, OPC A&E connects SCADA, HMI, DCS, historians, alarm servers and other industrial control systems.
Although new projects increasingly choose OPC UA, OPC A&E still runs in many existing installations. Anyone who operates, secures or migrates such an installation needs to understand its event model, its alarm states and its DCOM risks.
🧠 Where does OPC A&E come from and what does it do?
Within industrial processes, alarm and event information is essential for process safety, operator awareness, incident detection, fault analysis, auditing and compliance. Before 1999, every SCADA or alarm application had to build its own interface to every control system. OPC A&E standardised that interface in the same way that OPC DA had already done for process values.
The main difference from OPC DA is the communication model. OPC DA delivers tag values; OPC A&E delivers events with a timestamp, source, severity and message. The server monitors the conditions itself and only sends a notification when something changes. As a result, the client never misses an alarm that appeared and cleared between two read cycles.
| Specification | Full name | Delivers | Typical use |
|---|---|---|---|
| OPC DA | Data Access | Current process values with quality and timestamp | HMI screens, real-time interfaces |
| OPC HDA | Historical Data Access | Stored time series | Trends and reports from historians |
| OPC A&E | Alarms & Events | Alarms, state changes and events | Central alarm lists, event logs, audit trails |
All three are built on COM/DCOM and therefore run only on Windows. That is both the strength of the standard (broad vendor support) and its biggest weakness (security and firewall management).
🔧 How does the OPC A&E event model work?
The architecture is a client/server model. An OPC A&E server collects alarms from the underlying control layer, for example a PLC read via Modbus, S7 Comm or Ethernet IP, or a BACnet network in building automation. The server translates them into a uniform model with these building blocks:
-
Area - a hierarchical, logical grouping of the plant, for example
Plant1.BoilerHouse - Source - the object that raises an event, such as a tag or device within an area
- Condition - a named state of a source, such as a level alarm
- Subcondition - the specific step within a condition, such as HIGH_HIGH, HIGH, LOW or LOW_LOW
- Category - a server-defined group of events that share the same attributes
- Severity - a number from 1 to 1000 that expresses urgency
- Attributes - additional data defined per category, such as the current value or the limit
A condition in OPC A&E is not the same thing as condition monitoring: the first is an alarm state, the second is tracking the technical health of machines.
The specification defines three kinds of events:
| Event type | Meaning | Acknowledgement needed? | Example |
|---|---|---|---|
| Condition-related | State change of an alarm condition | Often, yes | Tank level moves from HIGH to HIGH_HIGH |
| Tracking-related | An action by an operator or client, including the actor ID | No | Operator changes a setpoint or a tuning parameter |
| Simple | Standalone notification without state | No | Device failure, system message, batch start |
Not every server supports all three: some products deliver simple and condition events but no tracking events. Check this beforehand if you need audit trails of operator actions.
🔄 Which states can an alarm have in OPC A&E?
A condition has three state attributes: enabled/disabled, active/inactive and acknowledged/unacknowledged. On every change, the server sends a new event to all subscribers, so every alarm list shows the same picture.
| Step | Process | Acknowledged? | Meaning for the operator |
|---|---|---|---|
| 1 | Normal (inactive) | n/a | No alarm |
| 2 | Active | No | New alarm, action required |
| 3 | Active | Yes | Acknowledged, but the process deviation still exists |
| 4 | Inactive | Yes | Process recovered, alarm leaves the list |
| 5 | Inactive | No | Process recovered before acknowledgement; the alarm stays until someone acknowledges it |
When an alarm is acknowledged, the server records who acknowledged it and with what comment. A shelved state, in which an operator temporarily parks a nuisance alarm in a recorded way, does not exist in OPC A&E. Shelving and suppression only arrived with OPC UA Alarms & Conditions, in line with ISA-18.2.
⚙️ How does an OPC A&E subscription work in practice?
An OPC A&E client is event-driven rather than polling-based. That means a lower network load and better scalability than periodically reading alarm bits. A typical connection works like this:
- Connect - the client connects to the event server over DCOM.
- Browse - the client requests the area and source hierarchy and the available categories.
- Create a subscription - with a BufferTime (minimum time in milliseconds between callbacks, so events are batched) and a MaxSize (maximum number of events per callback).
- Set a filter - by event type, category, severity range, area and source.
- Receive events - the server calls the client back as soon as events are available; an optional KeepAlive shows during quiet periods that the connection is still alive.
- Refresh - after a restart, the client requests all active and unacknowledged conditions again so the alarm list is correct.
- Acknowledge - the client sends an acknowledgement back; the server distributes the state change to all subscribers as a condition event.
A common set-up in a SCADA interface is a BufferTime of, say, a few hundred milliseconds and a filter that keeps events below a certain severity out of the operator list while still sending them to the historian.
🏭 Where is OPC A&E used?
OPC A&E is mainly found where alarms from systems of different vendors come together:
- Process industry - a DCS feeds alarms to central alarm analytics or to an MES for production analysis.
- Energy and water - substation and pump faults, water quality alarms and telemetry events come together in one SCADA.
- Buildings - faults from HVAC installations and energy management are passed to a central control room.
- Archiving - a Historian stores all events for root cause analysis, incident investigation and compliance.
- Security monitoring - for security purposes, alarm and event data flows to a SIEM or SOAR platform, so unusual operator actions or alarm patterns stand out.
Connectivity products such as Kepware offer an OPC A&E interface alongside OPC DA. This integration of operational events with IT systems is a classic example of OT convergence.
🧩 How does OPC A&E fit into alarm management?
OPC A&E transports alarms but does not make them more meaningful. Good alarm management according to ISA-18.2 and EEMUA 191 is still required. The well-known target is an average of no more than one alarm per ten minutes per operator; more than ten alarms in ten minutes counts as an alarm flood.
| Problem | Cause | Role of OPC A&E |
|---|---|---|
| Alarm flood | Power failure, network or PLC fault | MaxSize and BufferTime limit the load on the client, but not the number of alarms |
| Missed critical alarms | Too many notifications with the same priority | Severity and category make filtering and sorting possible |
| Loss of situational awareness | Slow or overloaded HMI | Filtering per area and source keeps lists manageable |
| Incomplete audit trail | Actions not recorded | Tracking events and the acknowledger ID record operator actions |
Define in your alarm philosophy how the severity scale of 1 to 1000 maps to the priorities in your HMI, for example three or four levels. Without that agreement, every server uses its own classification.
🔐 What are the security risks of OPC A&E?
Because OPC A&E runs on DCOM, it inherits the well-known cybersecurity problems of DCOM. DCOM uses TCP port 135 for the Endpoint Mapper and then a dynamic port, by default between 49152 and 65535 since Windows Vista. In addition, the server makes callbacks to the client, so traffic flows in both directions.
| Risk | Consequence |
|---|---|
| Broad DCOM permissions and weak authentication | Unauthorised connections or lateral movement |
| Wide firewall rules due to dynamic ports | Large attack surface between zones |
| Event spoofing | False alarms that mislead operators |
| Alarm suppression | Real deviations remain invisible |
| Outdated Windows systems | Unpatched vulnerabilities on the OPC host |
Encryption is not part of OPC A&E itself; it depends on the DCOM authentication level. Since 14 March 2023, Microsoft enforces at least the Packet Integrity level for DCOM activation through KB5004442 (CVE-2021-26414). Old OPC clients on unpatched Windows versions no longer work with an updated server after that.
🛡️ How do you secure an OPC A&E connection?
A practical approach to hardening, in line with IEC 62443 and NIST SP 800-82:
- Inventory all OPC A&E servers and clients and the zones they sit in, for example according to the Purdue Model.
- Keep DCOM within one zone using network segmentation; do not let it cross an IDMZ or reach office networks.
- Restrict ports and allow only port 135 and a narrow dynamic range between fixed IP addresses on an industrial firewall.
- Limit permissions - dedicated service accounts, read-only subscriptions where possible and no anonymous access.
- Use a tunnel or OPC UA wrapper for traffic between zones, so only one encrypted port needs to be open.
- Patch the Windows hosts through patch management and test KB5004442 behaviour in advance.
- Monitor with logging and security monitoring, including checks for unexpected acknowledgements or disabled conditions.
For Dutch organisations that fall under the Cybersecurity Act (Cyberbeveiligingswet), which entered into force on 15 August 2026, demonstrable control of such legacy interfaces is part of the duty of care. Frameworks such as the NIST CSF help to structure this.
📡 What is the difference between OPC A&E and OPC UA Alarms & Conditions?
OPC UA Alarms & Conditions, described in Part 9 of the OPC UA specification, is the functional successor to OPC A&E. The core concepts (conditions, acknowledgement, subscriptions and filters) remain, but the data model is much richer.
| Property | OPC A&E | OPC UA Alarms & Conditions |
|---|---|---|
| Technology | COM/DCOM, Windows only | Platform-independent, TCP or HTTPS |
| Firewall | Port 135 plus a dynamic range | One fixed port |
| Security | Depends on DCOM settings | Built-in authentication, signing and encryption |
| Alarm states | Enabled, active, acknowledged | Also confirmed, shelved and suppressed |
| Data model | Area, source, category, attributes | Object-oriented information model with alarm types |
| Cloud integration | Limited, via gateways | Direct or via PubSub |
🛠️ How do you migrate from OPC A&E to modern architectures?
Many organisations gradually replace OPC A&E with OPC UA or with event streaming over MQTT and a Unified Namespace. A common approach:
- Map the alarm flows - which servers, categories and severity schemes are in use.
- Deploy a wrapper that exposes OPC A&E events as OPC UA Alarms & Conditions, so new clients already speak OPC UA.
- Replace clients such as the Historian and the alarm analytics step by step.
- Validate that alarm states, timestamps and acknowledgements come through identically, especially in validated environments.
- Disable DCOM once the last classic client is gone.
A migration touches the legacy systems that tend to stay in service the longest, so plan it together with the replacement of the control system.
❓ Frequently asked questions
Is OPC A&E the same as OPC DA?
No, OPC A&E and OPC DA are separate specifications in the OPC Classic family. OPC DA delivers current process values from tags, while OPC A&E pushes alarms and events with a source, severity, timestamp and acknowledgement status. Many servers offer both interfaces side by side.
Is OPC A&E still supported?
OPC A&E is no longer being developed; version 1.10 from 2002 is the last one. Many vendors still ship OPC A&E servers and clients for existing installations. For new projects, OPC UA Alarms & Conditions is the recommended choice.
Why does my OPC A&E client stop working after Windows updates?
Since the DCOM hardening KB5004442 became mandatory on 14 March 2023, an updated Windows server rejects DCOM activation below the Packet Integrity level. Old OPC A&E clients on unpatched Windows versions do not meet that requirement. Updating, replacing the client or using a tunnel solves this.
What does severity mean in OPC A&E?
Severity in OPC A&E is a number from 1 to 1000 that indicates how urgent an event is. The specification does not define how that number maps to HMI priorities. You should therefore record that mapping in your alarm philosophy.
Can OPC A&E pass through a firewall?
OPC A&E can pass through a firewall, but it is difficult because DCOM uses port 135 plus a dynamic port range and sends callbacks to the client. It is better to keep OPC A&E within one zone and route traffic between zones through a tunnel or an OPC UA gateway.
Does OPC A&E support alarm shelving?
No, OPC A&E only knows the states enabled, active and acknowledged. Shelving and suppression only became part of OPC UA Alarms & Conditions. In an OPC A&E environment, the SCADA or alarm application handles shelving itself.
📌 In summary
From 1999 onwards, OPC A&E made vendor-neutral alarm and event communication possible between controllers, SCADA, historians and alarm servers. Its event model of areas, sources, conditions, severity and acknowledgement is still recognisable in OPC UA, but its DCOM foundation makes security and firewall management difficult.
OPC A&E is the classic, DCOM-based OPC standard for alarms and events: keep it within one zone, manage the DCOM risks and migrate step by step to OPC UA Alarms & Conditions.