Alarm function blocks in IEC 61131-3 programming

Introduction

Essential alarm status features

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

  • 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 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
  • optional: timestamps for a variety of substatuses can be set

    Additional from 2020.6:
  • comment – the latest comment provided by the user
  • language – identifier of the LocaleID for a comment (e.g. "en-US")
  • user – the latest user who has acknowledged, confirmed or changed the comment

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.

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. With Acknowledge and Confirm the client can pass a localized comment along with the user's name. This is also reflected in the AlarmState

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

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.

Using Alarm function blocks in IEC 61131-3 programming

IEC 61131 alarm function blocks

The alarm function blocks are contained in the PLCnext Controller library.

Alarm_IEC-FBs.png

There are three types of alarm function blocks:

  • Standard alarm blocks (ALM_REGISTER, ALM_ALARM)
  • Blocks with user parameters (ALM_REGISTER_PARAM and ALM_ALARM_PARAM)
  • A support class for user-defined alarm blocks (ALM_CUSTOM_ALARM)

Alarm blocks use theALM_ALARM structure for internal data storage. It is used by the blocks, and ouside of the blocks this structure shall only be read.

Standard alarm blocks

TheALM_REGISTER alarm block

To register an alarm, you can use theALM_REGISTER function block. A rising edge or constantTRUE signal at the input introduces the alarm to the system. This function block must be called until theDONE output delivers aTRUE signal. If many alarms are registered at the same time, aFALSE signal might occur.

Several alarms can be registered in the same PLC cycle. However, if theDONE output sends aFALSE signal, the registration can only be continued during the next cycle.

ALM_REGISTER.png

The ALM_ALARM alarm block

To send alarm statuses, you can use theALM_ALARM function block. With each change of theACTIVE input, the new status is sent to the OPC UA server. This function block must be called until theDONE output issues aTRUE signal. If many alarms are transmitted at the same time, aFALSE signal might occur. In this case, the call must be tried again in the next cycle.

TheAUTO_ACK andAUTO_CONF inputs can be used to control if alarms require acknowledgement or confirmation. If both inputs are set toTRUE, the alarm will disappear as soon as the condition at the ACTIVE input changes toFALSE again.

If acknowledgement or confirmation is desired, the function block has to process these requirements. It is therefore required that the function block is called continuously so that it can internally process these messages.

ALM_ALARM.png

Blocks with user parameters

To send user-defined parameters together with an alarm, you can use extended function blocks:

The user-defined parameters have to be introduced to the server via a structure. You can define and use a structure of up to ten parameters. The parameters must each have an elementary data type including strings. ForALM_REGISTER_PARAM, the names and types of the structure components are taken from the data type definition (worksheet) as names and types for the parameters.

ALM_REGISTER2.png

For theALM_ALARM_PARAM function block, the values from the structure are transmitted with the alarm status.

ALM_ALARM2.png

User-defined alarm blocks

Use theALM_CUSTOM_ALARM function block to create your own alarm blocks. This might be useful if special timing or a specific filter is required, for example. In addition, you can use the user-defined alarm block to set another semantics ofACK,CONF orRETAIN or implement several alarms in a combined function block.

TheALM_CUSTOM_ALARM function block provides access to methods of the subordinate alarm system. All methods are implemented as methods of the block.

ALM_CUSTOM_ALARM class diagram

The following methods send the corresponding messages to the OPC UA server:

  • SendAcknowledge
  • SendAddAlarm
  • SendConfirm
  • SendStateChange

Use the GetAckConfRequest method to handle Acknowledge, Confirm or AddComment calls of the client.

Acknowledging and confirming alarms

Instead of the OPC UA Server, you can also use the ALM_ACK and ALM_CONF function blocks to acknowledge and confirm any alarm. The alarms are clearly identified by the ALARM_ID.

Section0200037.jpg

 

 

 


•  Web browser recommendation: Chrome/Edge 88 or newer, Firefox ESR 90 or neweror Safari • 
• Published/reviewed: 2022-09-14 • Revision 046 •