Automation Alerts and Events Have Expanding Responsibility

Overview

Detecting, reporting, and responding to abnormal situations or automation events and alarms are all important functional elements of a complete process automation strategy. Traditional control systems present this information in the form of alarms directed to the operations staff on the control system console. In abnormal situations, the volume of these alarms can present a present a significant challenge as operators are subjected to alarms floods or storms.

Process-related alarms are only one type of alert typically presented to the operations staff. For example, the growing importance of industrial control systems (ICS) cybersecurity means that security-related events must also be captured and managed. The ISA/IEC 62443 series of standards on industrial automation and control systems security explicitly state that security-related events and alerts must be collected and maintained for analysis. The standards implicitly assume that once this information is collected, someone will be available to interpret it and take the appropriate action.

Automation solution providers and end users must focus not only on the nature of the information, but how to express it and, most importantly, to whom. More research and development is required in this area. End users must state clear requirements and expectations as to the types of information they require when describing anomalous behavior in their processes.

Abnormal Situations

Detecting and responding to abnormal situations has been a topic of considerable interest in industrial automation for many years. Early work in this area included that of the Abnormal Situation Management (ASM) Consortium, which began with Honeywell’s Alarm Management Task Force to address Alarm Floods. More recently international standards bodies have addressed the topic; most notably the ISA18 committee on instrument signals and alarms.

Automation Alarm Management

Alarm management has been an important element of industry response. The ISA18 committee was created to “…establish terminology and practices for alarm systems, including the definition, design, installation, operation, maintenance and modification and work processes recommended to effectively maintain an alarm system over time.”

The original standard from this committee, ISA-18.1-1979 (R2004), Annunciator Sequences and Specifications, is intended primarily for use with electrical annunciators that call attention to abnormal process conditions using individual illuminated visual displays and audible devices. In 2009, the committee completed ANSI/ISA-18.2, Management of Alarm Systems in the Process Industries. Additional technical reports have also been developed on several aspects of alarm management, including:

• ISA-TR18.2.3-2015, Basic Alarm Design
• ISA-TR18.2.4-2012, Enhanced and Advanced Alarm Methods
• ISA-TR18.2.5-2012, Alarm System Monitoring, Assessment, Auditing

• ISA-TR18.2.6-2012, Alarm Systems for Batch and Discrete Processes

Additional Sources of Alerts

However, an abnormal situation may be signaled by more than just traditional process-related alarms. The increased use of monitoring systems and other “smart” devices results in a wide variety of alerts that may require a timely response. These additional sources include:

• Cybersecurity – It is becoming more common to have some sort of network or security monitoring in place, with alerts generated for events such as unusual network traffic, authorization failures, or unauthorized network traffic.
• Network monitoring – With the increased sophistication of process networks it may be necessary to detect and alert on unusual situations such as node or switch failures.
• Physical security – Monitoring devices such as cameras or physical access sensors may also have the capability to generate alerts or requests for attention.
• Business process alerts – Various information or work flow automation solutions may also be capable of alerting staff to unusual behavior.

The result is that a growing amount of information may be generated with an expectation of further follow-up for analysis and resolution. Unfortunately, it is not always clear exactly who is accountable for this follow-up and associated response. In the absence of an explicit definition, certain assumptions may be made.

For example, it’s safe to assume that the operations staff (operators, plant engineers, etc.) will always be available to react to abnormal situations. Operators and plant engineers generally understand the implications and potential consequences of such events, including possible impacts on the integrity of the system under control. However, they may not have the skills or experience to make the best decisions in response to these new sources of information.

Unfortunately, it is much easier to configure devices and systems to generate alerts than to fully define the intended audience and expected actions associated with them. In the case of process alarm management, this has resulted in automation systems that have far too many alarms for which the optimum response is not clear. Adding new sources of alerts such as security and network management will only exacerbate this situation.

Different Approach Needed

The increased number of information sources and diversity of the data available demands a different response than simply assuming that the operations staff “will take care of it.” When designing and implementing different monitoring systems the designer must make a conscious decision with respect to the role best equipped to respond to the information. For example, for security-related alerts, the decision may be to route this information to a security operations center (SOC), rather than to the control room operator interface. However, this may result in a loss of context since SOC staff may not have the benefit of a view of the process to provide context. Ideally, security information should be interpreted and presented in a process context, using terminology and presentations that allow operations staff to make the necessary decision.  In some cases, this could include calling in more specialized security expertise, as required.

Regardless of how and by whom they are eventually handled, every alert generated in response to an event or abnormal situation must be designed in a way that clearly identifies the target audience as well as the appropriate response options. The same principles that have been identified for the intelligent design of process alarms can also be applied to alerts of other types.

Rather than simply alerting on an unusual event or unexpected state, there should be an attempt to interpret the situation and present associated information using appropriate terminology for the context and audience. For example, information presented using network-related jargon may have little meaning to a process operator.

If possible, alerts should be defined in the context of an established work flow that takes full account of the roles involved and the expected level of accountability and responsibility in each case. This allows information to be routed to the proper individuals depending on the state of the overall process.

While most automation and associated systems have the capability to deal with traditional process alarms, other types of alerts are typically handled by separate systems using terminology and models that may not be familiar to plant operations.

Better Tools and Methods Required

New methods and better solutions may be required in order to bring disparate information into a common context. This begins with a broader definition of the nature of automation-related alerts.

The Standards and Practices department of the International Society for Automation (ISA) is currently considering the need for new or expanded standards and practices to address the proper handling of the full range of alert information that may be generated in an industrial environment.

The nature of certain types of alerts may also require changes to the form in which information is displayed. The typical process flowsheets and numerical displays traditionally used in operator interfaces may not be sufficient.

Recommendations

Based on ARC research and analysis, we recommend the following actions for owner-operators and other technology users:

• Operations Perspective – Place additional emphasis on understanding the operations perspective on automation-related alerts in order to tailor information to the audience.
• More than Process Alarms – Embrace the idea that process alarms are only part of the picture.
• State Expectations – Asset owners must define clear expectations for handling of a broad range of alerts that may be presented in the context of a process automation system.
• ISA Proposal for Alert Management – ARC encourages those interested in this activity to contact the leaders of the ISA18 committee for further information.

If you would like to buy this report or obtain information about how to become a client, please Contact Us.

Keywords: Events, Alerts, Alarms, Operations View, Security, Operator Interface, ARC Advisory Group.