OPC A&E

OPC A&E Specification is used to transfer alarm messages between OPC Client and Server. It only makes sense to implement OPC A&E if the underlying device creates alarms. A typical “device” is a distributed control system (DCS) of a plant in the chemical industry: If a part of the process reaches a critical condition (“Temperature of tank A is too high”), the DCS generates an alarm that can be seen in operation stations.

AE Overview
Figure 1. AE Overview

In industrial environments it is often very difficult to transfer alarms of a specific DCS or PLC to 3rd party applications. This is for 2 reasons mainly:

  • Access to alarm data is only possible over native tools made by the DCS vendor

  • Over time all DCS vendors have developed their own conventions of how an alarm message is formatted

The OPC A&E specification solves the above problems in the following way:

  • OPC A&E Servers create a standardized interface to make alarms of an alarm source available

  • Using OPC A&E Clients, applications can read alarms without a native driver for a specific DCS system

  • OPC A&E specification defines a standard message format, which fits all different DCS systems. Each message consists of different fields that are defined by the A&E specification.

Alarm messages are created very infrequently, therefore it does not make sense to use a polling mechanism. The OPC A&E specification uses a high performance data transfer based on a subscription between OPC Client and Server (Asynchronous with callback).

Most clients only read A&E data, but writing A&E data is also possible and can be used to acknowledge alarms.

Subscription

To start reading alarms from an OPC A&E Server, the client has to create a subscription (IOPCEventServer::CreateEventSubscription). After the subscription is created, the server sends alarms via callback when they are created in the underlying device. A single callback can contain multiple alarm messages. It is possible for the OPC Client to set different filters for a subscription, this helps to reduce network load, and to remove alarms not required by the OPC Client.

By specifying the parameter Buffer Time, the client defines a minimum time interval that needs to elapse between callbacks. After the time interval specified by buffer time value passes, the OPC Server sends all alarms (matching filter criteria) that have been collected during the time interval. A typical value for buffer time is 100ms.

Critical conditions in the process industry sometimes trigger multiple alarms in a very short time (alarm flood). This can have the effect that an OPC A&E server needs to send a huge number of alarm messages in one callback. The number of messages allowed in one callback can be specified with the parameter MaxSize. If the value specified by max size is reached during a single buffer time, the OPC Server is allowed to trigger the callback earlier than specified by the buffer time value.

OPC AE Subscription
Figure 2. OPC AE Subscription

Different OPC A&E Clients exist on the market, but not every application requires every message that is created in a DCS system. If the OPC A&E Client is only interested in a subset of all available alarms, best performance can be reached when filtering is realized on the OPC Server side. To do so an OPC A&E Client can apply filtering to an existing subscription object (IOPCEventSubscriptionMgt::SetFilter). Filtering is possible on:

  • Event Types

  • Event categories

  • Severity

  • Process Area

  • Event Source

Filtering event subscription by a specific hierarchy branch requires a Fully Qualified Area Name. To obtain it, an OPC A&E Server can implement an area browser (IOPCEventAreaBrowser), which works in similar fashion as item browsing in DA & HDA specification.

Message Fields

OPC A&E specification defines 3 event types for messages (Simple, Tracking and Condition). A message of a specific type has different message fields available. When implementing the OPC A&E Server, the vendor needs to decide how the OPC Server populates fields in the message container.

Simple messages have the following fields:

  • Source – Physical location of device causing the event

  • Time – UTC timestamp when event was triggered

  • Type – Simple, Tracking / Condition

  • EventCategory – Category of message (example: “Level”)

  • Severity – Range from 1…​1000 defines severity of event. 1 is highest severity.

  • Message – human-readable text message shown with event

OPC AE Message Fields - Simple
Figure 3. OPC AE Message Fields - Simple

Tracking messages have all the fields of the Simple event type, plus the field ActorID. A message with ActorID can be tracked back to a person or an instance in the process.

OPC AE Message Fields - Tracking
Figure 4. OPC AE Message Fields - Tracking

Condition based messages have the largest selection of fields. In addition to those of the Simple and Condition event types, they also have the following fields:

  • ConditionName – physical type of value that triggered the message

  • SubConditionName – type of limit violation

  • ChangeMask

  • NewState

  • ConditionQuality – data quality of condition (Good/Bad/Uncertain)

  • AckRequired – Acknowledgement required for this alarm?

  • ActiveTime

An alarm in the process sometimes contains the process value that triggered the alarm. This is different compared to an OPC DA item: it always shows the current value, whereas the alarm message contains a “historical” value at the time when the alarm was triggered.

OPC AE Message Fields - Condition
Figure 5. OPC AE Message Fields - Condition

When a condition based alarm is triggered in the process, it can go through multiple states. The fields ChangeMask and NewState are used to track the state.

  1. At the beginning a condition based alarm becomes active, and requires acknowledgement. (ChangeMask: “ActiveStateChanged”, NewState: “Active”, AckRequired: “True”)

  2. When acknowledgement was created, the message is sent a second time with AckRequired field set to “False”.

  3. When condition returns to safe state, alarm is inactive again (ChangeMask: “ActiveStateChanged”, NewState: “Inactive”, AckRequired: “False”)

ActiveTime provides the timestamp when the alarm became active the first time.

There is a high degree of variation between different vendors alarm strings. When implementing the OPC A&E Server, a vendor should use all standard message fields defined by the OPC Foundation. If this is not sufficient to implement all required content there is also the possibility to define vendor specific message attributes.