Detecting, reporting, and responding to abnormal situations or events 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 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 behaviour in their processes.
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.
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.
• SA-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 signalled 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, authorisation failures, or unauthorised 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 workflow automation solutions may also be capable of alerting staff to unusual behaviour.
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 is 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.
© Technews Publishing (Pty) Ltd | All Rights Reserved