Alert Notifications Overview

Alert Notifications works as the notification provider for GENESIS. You can receive alerts via email, text messages, text-to-speech, WhatsApp, instant messaging, and so on. Alerts can be sent through a native SMS or email, Microsoft Teams, and other Communications Platform as a Service (CPaaS) providers using REST calls.

Alert Notifications provides reporting via GenEvents, supports multiple data sources, and integrates with Connected Field Services, Bridging, and Alarm Server (native SMS, email). You can also use alert services in GraphWorX through commanding. Alert services integrate with Web API services for providing alert status and acknowledgment support.

The following image shows the Alert Notifications general architecture.

Alert Notifications General Architecture

Providers Used for Alert Notification

Alert Notifications supports alerting through various providers as listed in the table.

To learn which GENESIS version introduced the support of each type of notifications, refer to the list of list of supported providers.

Provider

Supported Alert Notifications

SMS (GSM)

Outgoing SMS only

Sierra Wireless

Outgoing SMS and acknowledgment

Email (SMTP)

Outgoing email only

AT&T

Outgoing SMS only

Twilio
  • Outgoing SMS and acknowledgment
  • Outgoing text to speech and acknowledgment
  • Outgoing WhatsApp and acknowledgment

Vonage
  • Outgoing SMS and acknowledgment
  • Outgoing text to speech and acknowledgment
  • Outgoing WhatsApp and acknowledgment

Azure Communication Service (ACS)
  • Outgoing SMS and acknowledgment
  • Outgoing email only

SendGrid

Outgoing email and acknowledgment

Brevo

Outgoing email only

Microsoft Teams (MS Teams)

Outgoing instant message only

Logging

Alerting modules except email (SMTP) and SMS (GSM) log the data of outgoing alerts in runtime database tables, which are used to support acknowledgment of alarms through Bridging and Connected Field Service. You can store the tables as a part of the Alert Configuration database, or configure a separate custom database in Workbench under Alert Notifications > General Settings.

Archiving

You can set up archiving the logged data in Workbench under Alert Notifications > General Settings. The archiving condition can be based on time or time and size.

Events

Before performing an action, the Alert Notification service posts an event describing the destination of the action and an indication of the action's trigger. After performing an action, the service posts another event describing the destination of the action, an indication of the action's trigger, and the result of the action. You can display this event information in an Alarm Viewer with event subscription or logged via the alarm logger.

The alert services do not process events triggered by themselves.

Communication

Alert Notifications supports the following types of input communication:

  • Commands

    Commanding supports a simple to configure trigger that you can easily tie to various GENESIS components. This allows you to trigger alert actions by using a GraphWorX command, right-clicking an asset tree view, or right-clicking a menu item in the Alarm Viewer.

  • FrameWorX alarm communication

    Native alert notifications (SMS, email) can be triggered based on the contents of received alarm or event messages. This is configured via the standard real-time subscription available in GENESIS Alarm Viewer. You can use this method to handle notifications of high-importance alarm or event messages.

  • OPC UA data

    Alert Notifications can be set up to read the destination, subject, and message data from OPC UA string data points. In addition, Alert Notifications trigger alerts based on the value of the sent UA point and report the result to the status of the result in the OPC UA stats value. The expected use of UA triggers is to dynamically change information that is being processed or contained in batch updates.

Status Results

When possible, the system reports the status of the alert action. This status is the result as known by the service in question and is not guaranteed to represent the final throughput result. There are expected cases where the alert services report a sent success status, and the result is a failure. This can happen when the failure results are withheld from the service or are not known at the time of reporting the status. For example, a common email security mechanism is to withhold reporting of invalid email addresses. When an invalid email address is sent to a mail exchange, the exchange reports success on processing the email, and then drops the email.

The native email service attempts to check the syntax of the email names. If you run into a syntax conflict that you think is invalid, contact the Support Center.