Alerting

On the Alerting tab in device management you can configure how the system should handle alarms and fault reports from PLCs and other sources. The Avelon system can process various alarm types and either forward them or feed them into its own ticket system.

Manage alertings

Create a new alerting by clicking Add Alerting on the left side above the sidebar or edit an existing alerting by selecting it in the sidebar.

When creating a new alerting, you must first select the type of alerting. This determines the basic behavior of the alerting and cannot be changed later. You can configure any number of alertings on one Beetle.

The available alarm types are:

Intrinsic Alarm: The device sends alarms directly to the Avelon control system.
Filtered Intrinsic Alarm: The device sends alarms directly to the Avelon control system where they are relayed.
Text Alarm: The device sends alarms as text via email or via an ESPA 4.4.4 interface to a (virtual) Beetle.
Heartbeat by Email: The device sends heartbeats to the Avelon control system by email. Missing heartbeats will be interpreted as faults and will trigger an alarm.
Manual Alarm Condition: The Avelon system checks alarm conditions on the remote device at regular intervals and triggers an alarm if necessary.
Data Point Watchdog: The Avelon system regularly checks whether the specified data point can be read.
Catch Unhandled Alarms: This option can be used as a temporary solution for alertings that are not caught by any of the alarm types described above. However, this is purely a safety net for testing purposes. In general, it is recommended that alarm handling be implemented using one of the other procedures described above.

Alarmed data points

Subsequently specify which data points are to be used for the alerting by dragging them from the right sidebar to the lower part of the main view. All data points assigned to the alerting are listed in the main view under Data Points. You can also assign multiple data points of the same data type simultaneously by first selecting them in the sidebar while holding down the Ctrl or Shift key.

To remove data points from an alerting, move the mouse over them and then click Remove Data Point on the right-hand side. Alarms of the data point that have already been triggered are not deleted, but new alarms are no longer triggered for this data point.

Settings

The following setting options are possible for an alerting and refer to all data points assigned to the alerting:

Name: Give the alerting a suitable name.
Alarm Chain: Select the alarm chain to be escalated in the event of an alarm to notify a stand-by service or technicians. Also see the chapter Alarm Chains.

The following options depend on the selected alarm type and are not available for all types:

Notify current alarm chain user by email when alarm is gone: With this option you can specify whether device acknowledgments should be sent by email to the recipients of the alarm message. This setting overrides the option “Notify current alarm chain user by email alarm is gone,” which can be configured in the general settings for all alertings (see Notifications).
Support BACnet acknowledgment: Activate this option if you want the acknowledgment of a ticket in the Avelon control system to automatically acknowledge all corresponding BACnet transitions. When a ticket is acknowledged manually, the system sends a BACnet notification of type ACK_NOTIFICATION to the corresponding device. Thus the alarm is acknowledged not only in the Avelon control system, but also directly on the BACnet device from which the trigger originated.
Treat notifications of the EVENT as alarms: The default is for notifications of the EVENT type to be treated as events. Although these appear in the ticket list if it is configured accordingly, they do not trigger an alarm escalation. Enable this option to invoke alarm escalation for events as well.
Add notification of type ACK_NOTIFICATION as ticket comments: If this option is enabled, notifications of the ACK_NOTIFICATION type are appended to the corresponding alarm ticket as comments.
Device acknowledgment is required to be able to close a ticket: Users cannot close a ticket until the corresponding alarm from the device has been acknowledged as “gone” with an acknowledgment.
Set data point value on user acknowledgment: This option allows an alarm on the controller to be turned off as soon as the alarm ticket is acknowledged by a user in the alarm chain. A dedicated data point is assigned to the alarm, for which you can set specific values for acknowledgment and reset. Once the alarm is acknowledged, the value of this data point will be set to the acknowledgment value and then it will be reset to the reset value after one second. Information such as the fact that a value was written, the actual acknowledgment value, system name and name of the data point will be added in the ticket history, for reference.

Warning

This option is applicable for all protocols, except for BACnet.
Conditional alarm suppression: Alarm suppression allows you to prevent alarms from being issued under certain conditions. Set the condition by first dragging a data point from the right sidebar to the yellow note field, then selecting the data point property to be tested from the list and configuring a value comparison, such as <LiveValue> ≥ 100.
Enable tag for alarm messages: Activate this option and then enter any text in the Alerting Tag field. You can then use this text in the alarm message template so that it is sent to the recipient by email or SMS message as part of the alarm message in the event of an alarm. This allows several different alarm texts that depend on the alarm condition to be defined for the same data point. To learn how to use the custom tag in alarm messages, see Notifications.

Manual alarm condition

Surveillance

Alert at Value: The value at which an alarm should be triggered.
Checking Interval: The frequency at which the alarm condition is checked.
Delay: If the alarm condition is met, wait for this amount of seconds before triggering an alarm. Only if the alarm condition is still present after this delay, the alarm will be triggered. This must be a multiple of the checking interval (or 0, if no delay is required).

Example

In the example below, an alarm condition occurs two times. The first time, the condition is no longer valid after the delay, so no alarm will be triggered. The second time, the condition is still valid after the delay, at which point an alarm is triggered.

	Alarm condition
	Alarm
	Checking interval
	Delay

If you enable the option to send an email to the alarm chain user when an alarm is gone, the delay will not be applied in that case.

Data point watchdog

Surveillance

Alert if the value doesn’t change: If this option is enabled, an alarm will be triggered only when the value of the data point doesn’t change from one check to the next. If the option is disabled, an alarm will be triggered when the data point cannot be read.
Checking Interval: The frequency at which the alarm condition is checked.
Delay: If the alarm condition is met, wait for this amount of seconds before triggering an alarm. Only if the alarm condition is still present after this delay, the alarm will be triggered. This must be a multiple of the checking interval (or 0, if no delay is required).

Example

In the example below, a data point value doesn’t change after a given checking interval three times in a row. Each time, the system waits for the delay to elapse (which happens to be twice the checking interval in this example). Since the data point value eventually changes before the delay is over after the first and second time, no alarm is triggered. After the third time, however, the value still hasn’t changed after the delay, at which point an alarm is triggered.

	No change detected
	Alarm
	Checking interval
	Delay

If you enable the option to send an email to the alarm chain user when an alarm is gone, the delay will not be applied in that case.

Filtered intrinsic alarm

Alarms of a specific notification class can be configured so that they trigger an alarm on another data point. This makes it possible to forward alarms, for example in situations where alarms are to be received by the Avelon control system but are also to be forwarded to an external alarm service.

With the alarm type Filtered Intrinsic Alarm, you can specify in the Filters section which alarm or message texts are to be forwarded to which target data point.

Make sure that in the main view at the bottom under Data Points you have only assigned data points of the Notification Class type.

To set an instance of alarm forwarding, first click the Add Filter button under Filters to add a new row to the table. In the Expression column, you can enter the regular expression against which the incoming alarm text is to be checked. Then drag the target data point to be written in the event of an alarm from the right sidebar to the empty cell in the Target Data Point column.

Note

* and ? are reserved placeholders that can be used to search for a single character (?) or multiple characters (*).

Whenever an alarm with the corresponding expression is received, its value is automatically written to the target data point.

Warning

The functionality of this alarm type is comparable to a collective alarm, i.e. incoming alarms are grouped into a single target alarm according to the rules you have configured. Note, however, that an alarm escalation only takes place if the target data point does not already have a pending alarm. This also applies for acknowledgment: The target data point is only acknowledged if the pending alarms of all source data points have been acknowledged.

Text alarm

Incoming messages via email or ESPA 4.4.4 can be converted into alarms automatically according to a predefined pattern.

First enter the desired search term to be searched for in the incoming message text as well as the desired search algorithm.

Select whether the desired search term should be searched for at the beginning, in the middle or at the end of the message text, or select the Regular Expression option to search for text modules using a rule or to include parts of the message text in the alarm text.

Regular expression

Regular expressions can be used to recognize dynamic alarm texts according to a specific pattern. If, for example, you want to handle message texts with the texts Alarm A and Alarm B for the same alerting, enter the text Alarm (\w) in the Search Term field to intercept both options.

This not only allows similar texts to be handled using the same alerting, but also allows the text from the message text to be included in the alarm text. For example, if you enter the text System reports an alarm: $1 as a Template for alarm text, you will receive both alarms with the text System reports an alarm: A as well as with the text System reports an alarm: B, depending on the incoming message text.

Examples
String	Description
`.*`	Any number of characters (digits, letters, spaces, etc.)
`\d{4}`	Exactly four digits
`\w{10,12}`	Between 10 and 12 digits, letters or underscores
`(\d*)`	Any number of digits → The parentheses form a group so that the characters found within it can then be used in the alarm text with the abbreviation $1. Example: `Alarm code: $1`
`Alarm code: (\d{4})-(\w*)`	The text “Alarm code: ”, followed by four digits, a hyphen and any number of other digits, letters and underscores → The latter are grouped separately and are available as the different abbreviations $1 and $2 that can then be used in the alarm text.

Note

By default, line breaks are ignored in the incoming emails. If you want to include line breaks in your regular expression, you have to activate the option Multiline Support.

Condition for recognizing a device acknowledgment

If you do not want to treat a message text as an alarm, but instead as a positive acknowledgment or an acknowledgment of the alarm, you can set this under Condition for recognizing a device acknowledgment. However, this assumes that you have selected the Regular Expression option under Condition and that the Search Term field contains at least one grouping, i.e. a text section surrounded by two parentheses.

Example
Condition	Regular expression
Search term	`Priority: P-(\d)\nAlarm Status: (.*)`
Template for alarm text	`Alarm with priority P-$1`
Condition for recognizing a device acknowledgment	`$2 = Acknowledgement`
Possible message texts that are to be covered by the alarm	`Priority: P-1 Alarm Status: Alarm` `Priority: P-2 Alarm Status: Alarm` `Priority: P-2 Alarm Status: Acknowledgment`

Heartbeat by email

The configuration of Heartbeat by Email is similar to the configuration of Text Alarm described above. However, there are three main differences:

Emails are not interpreted as alarms, but as heartbeats.
A regular expression is mandatory for pattern recognition (see description in the section Regular expression).
Instead of an acknowledgment, you define a timeout. If no heartbeat arrives within this timeout period, an alarm is triggered with the alarm text entered under Template for Alarm Text.