Alarms via OPC UA Server

Introduction

Essential alarm status features

Every alarm is oriented towards the OPC UA Alarms and Conditions specification and has these properties:

  • 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 the alarm (from 1 = information to 1000 = severe error)
  • Retain – the alarm is to be shown to the user (evaluated by the client)
  • Message – the message to be shown to the user
  • AlarmType – the alarm type can be used for filtering in the client
  • AlarmId – the unique name of the alarm on the device
  • as an option, timestamps for a variety of substatuses can be set

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 cancel alarms. 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.

Some alarms must be acknowledged and sometimes even 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.

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, 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} First user parameter
{3} Second user parameter

The ALM_ALARM and ALM_ALARM_PARAM function blocks implement defined semantics of the alarms. Via Requires Acknowledge and Requires Confirm, you can only specify if the alarm is to be acknowledged or confirmed.

For more complex scenarios, you can write your own alarm blocks. This way you can, for example, check additional conditions, implement a different time behavior, or implement several alarms with a single block. For these tasks, the ALM_CUSTOM_ALARM block is available. It provides the Low Level methods that were used for implementing the other blocks. The same functions are also available in C++.

Using Alarm 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 ActiveStateAckedState 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

Alarms in UA address space

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, sitting here: Root/Types/EventTypes/BaseEventType/ConditionType/AcknowledgeableConditionType/AlarmConditionType/DiscreteAlarmType. The subscription will then send events about all alarm status changes.

E. g., in the UaExpert client (provided by Unified Automation GmbH), the Event tab shows a general view to all events with timestamps, the Acknowledged and Confirmed flags, the message, and the Active state.

The Alarm tab shows alarms with retain=true and provides a context menu for alarm handling.

Acknowledging and confirming alarms

Alarms are acknowledged and confirmed via the standard OPC UA alarm function. Note that the status change takes place in the alarm source (e.g., in the PLC program). Only after the alarm source has implemented the request for acknowledgement and confirmation, the OPC UA server will send the new event with the updated state (AckedState = TRUE, or  ConfirmedState = TRUE).

Filtering alarms

During OPC UA subscription, you can specify which alarm properties are to be sent 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.