Alarms via OPC UA Server
Introduction
Essential alarm status features
Every alarm is oriented towards the OPC UA Alarms & Conditions specification and has these properties:
| Property | Meaning or purpose | Restrictions |
|---|---|---|
AlarmId |
The unique name of the alarm on the device. | |
AlarmType |
The alarm type can be used for filtering in the client. | |
Active |
The alarm condition is active. | |
Acknowledged |
The user has seen the alarm condition. | |
Confirmed |
The user has solved the problem that caused the alarm. | |
Severity |
The severity of an alarm is set by values from 1 = information to 1000 = severe condition. |
|
Retain |
The alarm is to be shown to the user (evaluated by the client). | |
Message |
The message to be shown to the user. | |
comment |
The latest comment provided by the user. | firmware 2020.6 or newer |
language |
Identifier of the LocaleID for a comment (according to ISO 639-1 and ISO 3166-1, e.g. "en-US"). | firmware 2020.6 or newer |
user |
The latest user who has acknowledged, confirmed, or changed the comment. | firmware 2020.6 or newer |
Optionally, timestamps for a variety of substatuses can be set.
Registration of alarms
To introduce an alarm to the system, it has to be registered before the first use. As a result, you can see in the OPC UA® Server which alarms can occur.
Note: It is not possible to remove a registered alarm. However, they are deleted during each cold and warm restart. This is why alarms have to be registered after each cold or warm restart. Registering an alarm twice does not trigger an error message.
Acknowledgement and confirmation of alarms
Some alarms must be acknowledged and sometimes even be confirmed. To do so, the Acknowledge and Confirm methods can be used. These are also messages in PLCnext Technology. However, they are sent from a client to the alarm source. The alarm source must process this message. Usually, this results in a new alarm status which, as usual, is sent to all clients.
From firmware 2020.6 and newer, the client can pass a localized comment and the the user's name along with the Acknowledge and Confirm properties. This is also reflected in the alarm state.
Additional information to send with the alarm message
Often there is the requirement to add additional information to an alarm, which is available in the client and can be displayed in the message. For this, the alarm state also holds a list of up to 10 custom parameters. These parameters must be entered during registration with their name and data type so that they are known by the client. Elementary data types including strings are supported.
There are alarm blocks that can take on a structure with additional parameters. These parameters must be entered during registration so that they are known to the client. In the message, the parameters can be referenced using placeholders. The following placeholders are supported:
| Placeholder | Meaning |
| {0} | Alarm name - must be unique within the controller |
| {1} | Alarm type |
| {2} | 1st user parameter |
| {3} | 2nd user parameter |
| ... | |
| {11} | 10th user parameter |
Using Alarms via OPC UA Server
The OPC UA Server is the typical interface for accessing alarms. Here, alarm messages are mapped to OPC UA® alarms.
Registered alarms
In the OPC UA® address space, you will find the alarms in the Root/Objects/Server/Alarms node. Here, all registered alarms are displayed with their AlarmId. Below, you will see the alarm status, with ActiveState, AckedState or Retain as OPC UA® properties. This way, you have direct access to the current state.
Find all registered alarms in the OPC UA Address Space:Click to show a screenshot
Alarm types
The alarm types are written as subtypes of the DiscreteAlarmType. You will find them in the OPC UA® Address Space under Root/Types/EventTypes/BaseEventType/ConditionType/AcknowledgeableConditionType/AlarmConditionType/DiscreteAlarmType.
Subscribing to events
If you wish to be notified about alarm status changes, you can create an OPC UA® subscription (e.g., with the UaExpert client) and subscribe to the DiscreteAlarmType object, located in this path:
Root/Types/EventTypes/BaseEventType/ConditionType/AcknowledgeableConditionType/AlarmConditionType/DiscreteAlarmType
The subscription will then send events about all alarm status changes.
As an example, the following images show the alarms handling in the UaExpert client (provided by Unified Automation GmbH):
The Events tab shows a general view to all events with time stamps, the Acknowledged and Confirmed flags, the message, and the Activestate.
The Alarms tab shows alarms withretain=true and provides a context menu for handling an alarm.
Acknowledging and confirming alarms
Alarms are acknowledged and confirmed via the standard OPC UA® alarm method. Note that the status change takes place in the alarm source (e.g., in the PLC program). Only after the alarm source has processed the request for acknowledgement and confirmation, the OPC UA® server will send the new event with the updated state (AckedState = TRUE, or ConfirmedState = TRUE).
From firmware version 2020.6, the client can also provide comments to the Acknowledge and Confirm methods. If only the comment should be changed, the AddComment method can now be used. In all cases the user name of the OPC UA® session is associated with the comment.
Subscribing custom parameters
In an OPC UA® subscription you can specify which alarm properties shall be sent along with the event. Here you can also include the user parameters so that these values are transmitted consistently with the alarm from the source to the client.
Related Topics