Alarm Notification in the Age of Mobility

Summary
In recent months, ARC Advisory Group has been looking further into alarm notification, an increasingly important and sophisticated component of industrial automation that has only recently been recognized as a strategic component of the automation ecosystem.

In the past, alarm displays were restricted to control rooms and machine panels that required staffing. In some cases, companies used general alarm notification such as calls to phones and messages to handheld pagers. Today, companies can leverage an increasing base of connected devices to make appropriate individuals aware of alarms at any time from any location. These include smartphones and tablets as well as more traditional voice and text messaging.

Distributed Alarm Notification
Global economic forces require companies to maximize the utilization and availability of a growing number of machines and other plant floor assets, which are being monitored by fewer people who also often have other responsibilities. With production processes often running 24/7, it is not cost effective or efficient for operations personnel to be available around the clock to monitor the in-plant control panels awaiting possible alarm notifications. Instead, appropriate plant personnel must receive alarm notifications immediately, regardless of the day and time or their physical location at the time.

Monitoring a greater number of machines also results in an increasing quantity of alarms. This requires better filtering, so the most critical alarms receive the greatest attention and fastest response.

Alarm Notification vs. Alarm Management
While "alarm notification" and "alarm management" are often used interchangeably, in fact, they are very different.

Alarm management largely relates to the ANSI/ISA 18.2 alarm management standard, which covers areas such as baselines for alarms; benchmarking; visualization and labeling of alarms; alarm documentation, auditing, and enforcement; and "bad actor" analysis and solutions. The latter area is critical for managing alarm cascades, dead-band issues, and chattering alarms.

In contrast, alarm notification deals with areas such as what alarms are most important, whom and to what communication devices should the alarm be sent, how aggressively should the alarm be sent, and how should alarms escalate if they are not acknowledged or addressed by the person notified.

While seemingly simple, the science of alarm notification is often exceedingly complex. A simple, easy to manage user experience that effectively filters the most important alarm information from the noise requires a lot of complexity "under the hood," much of it invisible to the user.

While generally separate, the two areas are often complementary, since some aspects of alarm notification relate to alarm management. For example, alarm notification can play a major role in filtering alarms. Only a subset of total alarms, often about 10 percent, are critical enough to warrant notification. Also, alarm bundling can help filter alarms. For example, instead of getting 100 notifications of 100 related alarms, which would cause devices, such as cell phones, to be constantly signaling alerts, it is better to receive one notification containing the 100 related alarms. An additional challenge is the increasing aggressiveness of alarm notification, which could start with an email, then proceed to a smartphone push, then calls, SMS, etc. Finally, smart routing only sends alarm notifications to the most relevant individuals. For example, with smart routing, machine maintenance alarms would only go to the maintenance team, while safety alarms would only to safety team members.

Layers of Alarm Notification
Alarm notification typically involves three layers.

Layer one connects with various data sources, often via open standards such as OPC DA, AE, and UA; BACnet, and SNMP. Automation companies also provide specific device drives to enable direct, native data connections with HMI/SCADA and DCS applications. This enables alarm acknowledgements from any device to be automatically recorded and visible in the core HMI/SCADA system or DCS.

Layer two, the "logic layer," provides the functionality that controls how alarm notifications are routed, escalated, and filtered. Examples include loading work shift schedules so that the alarm automatically goes to the appropriate person or people on shift at the time of an alarm. This layer also provides the functionality to increase the aggressiveness of alarm notification as needed. For example, if the appropriate person does not acknowledge an alarm notification sent via email within a certain number of minutes, that same person will then receive a phone call, text message, and/or a smartphone push notification. This helps keep people from getting overwhelmed with their mobile devices continually signaling alerts.

If that person does not acknowledge or address an alarm after a certain period of time, another designated person will get notified, then another and another until the alarm is acknowledged. Typically, alarm routing parameters enable alarms notifications to be routed and filtered by any user-configured parameter. These can include alarm severity, time of day, day of week, whether or not an alarm is acknowledged, whether an alarm is still active, the amount of time an alarm has been active, whether the same alarm has occurred recently, and so on.

Layer three supports most communication devices and methods deployed across industry. We've seen an enormous proliferation of communication devices and methods over the past 20 years. Users have a variety of preferences on what devices and communication method are used. These will depend on whether use of the internet is allowed for security reasons, whether companies have already made an investment in certain hardware, what communication protocols and networks are available, whether personnel are always in-plant or need notifications outside of the facility, how people prefer to receive information, etc.

Alarm Notification Software Must Support a Wide Variety of Devices

Today, alarm notification software must support a wide range of communication devices and methods. These include smartphone push notifications and alarm displays for major smartphone and tablet devices in HTML5 format; including Android, iOS, Windows phones/tablets, Blackberry, and the range of operating system versions that go back at least two iterations.

The software's email notifications need to support the different security protocols to comply with differing end user IT and control network security standards. SMS notifications need to support different protocol standards and modems used worldwide and character sets for all major spoken languages. The software must also support notifications via Voice over Internet Protocol (VoIP), as well as over fixed/analog lines; both as a backup should the internet go down, or for users that do not wish to use the internet for security reasons. Alarm notification software must also support in-plant or wide area alphanumeric paging systems, marquee or Andon display systems, plant announcement/PA systems, and all current major web browsers, such as Microsoft Internet Explorer, Google Chrome, and Apple Safari.

Automation Company Approaches to Alarm Notification
The major automation companies typically approach alarm notification in one of three different ways.

Some build alarm notification into the HMI/SCADA or DCS. These tend to be closed systems that don't enable users to enhance the native alarm notification features.

Other automation suppliers build basic alarm notification into the HMI/SCADA or DCS with an interface for the end user to extend capabilities with a third-party product.

The third category of automation suppliers deliver alarm notification via partnerships with specialized alarm notification companies; many that have invested extensively in these solutions.

These third-party alarm notification solutions can either be embedded or preloaded in the HMI/SCADA or DCS software or purchased separately (often from the same distributor) and then interfaced to the HMI/SCADA or DCS software (often by the same system integrator).

Since it is not part of their core competency and/or strategic offering vision, many automation companies choose to outsource alarm notification to specialized companies because it is a niche offering that requires a great deal of work, including constant updating due to ever-changing communications standards and devices.

Conclusion
WIN-911 recently briefed ARC on the science of alarm notification, a subject that often does not get the attention it deserves, and its own well-developed alarm notification solution. WIN-911 has positioned itself as a primary solution provider in the alarm notification area and has achieved high brand awareness among end users.

ARC predicts that, in the not-too-distant future, alarm notification will become a ubiquitous component of the automation system, with increasing importance and sophistication and specialized suppliers such as WIN-911 will have an increasingly important role.

This is especially critical now as the Industrial Internet of Things (IIoT) continues to gain traction, providing connectivity to an ever-increasing number and assortment of plant assets and creating the need for additional alarm notifications of issues, problems and conditions.

All signed-in ARC Advisory Group clients can view this report in pdf format at this Link

If you would like to buy this report or obtain information about how to become a client, please Request ARC Info

Keywords: Alarm Notification Software; Automation, Industrial Internet of Things, ARC Advisory Group.