6 October 2009

Alarms standard like laundry: It's never done

By Ellen Fussell Policastro

Just like the clothes we wear every day get dirty, and we have to wash, dry, fold, and put away, the process of writing and updating standards is a never-ending one.

It is a task that must be done, and in a certain order. Writing and updating standards and technical reports on alarm management is no different. At least that is the philosophy of Nick Sands of DuPont, who co-chairs the ISA18 committee, Instrument Signals and Alarms, along with Donald Dunn of Saudi Aramco Services.

The committee develops standards, technical reports, and guidelines for alarm systems including annunciators, process automation systems, and the general development, design, installation, and management of alarm systems in the process industries.

The purpose of the committee’s meeting Monday at the Westin Galleria was to revise ANSI/ISA-18.1-1979 (R2004), Annunciator Sequences and Specifications, and to begin the process of developing six technical reports for ISA-18.02, Management of Alarm Systems for the Process Industries.

“We have to refresh that standard, so we have some work to do. We follow rules, and it may seem trivial, but it’s basic housekeeping. Co-chairs have responsibilities, the committee follows rules so that we are valid under ANSI and not challenged,” Dunn said.

Some of the main goals of the committee are 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.

Current working groups include:

•  ISA18.1 – WG to revise “Annunciator Sequences and Specifications”
•  WG1 – Alarm Philosophy
•  WG2 – Alarm Identification and Rationalization
•  WG3 – Basic Alarm Design
•  WG4 – Enhanced and Advanced Alarm Methods
•  WG5 – Alarm Monitoring, Assessment, and Audit
•  WG6 – Alarm Design for Batch and Discrete Processes

Working Group 1, Alarm Philosophy, covers the definitions, principles, and activities by providing overall guidance on methods for alarm identification, rationalization, and classification.

“We’ve created a frame for the technical report (TR), which is a concept we use at Chevron,” said WG1 chairman, Lokesh Kalra with Chevron. The frame concept is “a way of capturing what’s within scope and out of scope. We’ve come pretty close to a final table of contents. We’ve identified areas of overlap with other TRs and defined the delineation of content relative to other TRs.”

Inside the scope or frame is implementation guidance on contents of Clause 6 (the how-to document.) “Another thing we decided early on in the TR1 is we’ll provide guidance on things not covered explicitly in Clause 6 but maybe within the scope of Clause 6. We added a few items in the table of contents,” he said. Kalra said his working group believes this TR will be “used is by facilities and corporate departments looking to create an alarm philosophy for their site or company. We expect them to look at this TR along with the standard itself to help them determine what needs to go into the alarm philosophy documents.”

Kalra said in order to talk about philosophy, it is important to at least take a look at the other five TRs and what section of the alarm philosophy TR would overlap and how they would resolve. He looked to the committee for input. “When you talk about the what, you also have to talk a little about the how, why, and when. So I’ve tried to capture a few aspects of those. It’s important for us to get this right from an alarm philosophy TR perspective,” Kalra said. “We don’t want to go too much into the details and end up in conflict with something that was covered in a different TR later.”

The why would be the motivation for having alarms, examples of how facilities commonly define and use alarms, examples of alternatives to alarms for bringing something to an operator’s attention (HMI, alerts, etc). “This is a living document up for feedback,” he said, “and we’ll work together as we go forward, but this is our starting point. The goal is to minimize overlap because the more overlap you have the more likelihood for conflict.”

Working Group 2, Alarm Identification and Rationalization, covers the processes to determine the possible need for an alarm or a change to an alarm; it will systematically compare alarms to the alarm philosophy.

Working group chairs, John Campbell with ConocoPhillips and David Strobhar with Beville, are currently looking for input on the scope, which will apply to different types of processes. “We talked about distinguishing between different types of applications—greenfield vs. upgrading from an analog control system,” Strobhar said. “If I just have an existing DCS and just want to improve it there, or if I’m upgrading a DCS to a new version. I need to identify how the rationalization and identification may vary with those particular ones.”

This document will discuss levels in resources with which you might approach a problem. “Comprehensive might be preferred, but everyone might not be able to do that; either they can’t afford it, or they don’t have time,” Strobhar said. In answering a question posed about listing pros and cons, Strobhar said, “Do you try to create a table where you list the different levels of effort? Pros and cons is a sure bet. The question is do we talk about how your technique might vary if I’m doing the comprehensive vs. the staged approach. It gets complicated based on how many permutations [there are].”

Working Group 3, Basic Alarm Design, covers the selection for alarm attributes (types, deadbands, and delay times) and may be specific to each control system.

A status report from Todd Stauffer of exida and Pat O’Donnell of BP pointed to three meetings so far in which the working group reviewed the charter and annexes as well as the rejected comments for those that are “TR worthy.” The group also established a framework and table of contents for the TR.

“We started with the TOC with a section from Clause 10; we said let’s review it, look at each section, and determine if we need to expand on what’s already there,” Stauffer said. “We walked through each one and looked for areas to expound upon. We have a capture point at the end for new material we think belongs in this TR but doesn’t logically fit into a section.”

One of the main purposes of this TR is to discuss the importance of basic alarm design for minimizing nuisance alarms as well as reference metrics for how focus on basic alarm design has improved performance. There will be a table of common alarm management problems and which ones can be addressed in basic design.

Committee member Doug Metzger said that was a good idea. “There are basic strategies and advanced strategies that both go after nuisance alarms. So it’s a good idea to have a common set of problems we’re trying to address and use that same template across between basic and advanced.”

Working Group 4, Enhanced and Advanced Alarm Methods, will give guidance on additional logic, programming, or modeling used to modify alarm behavior. These methods may include dynamic alarming, state-based alarming, adaptive alarms, logic-based alarming, and predictive alarming, as well as most of the designed suppression methods.

This means setting the guidelines where they are acceptable said Steve Apple of Wonderware Mobile Solutions. “That’s what we started to do with advanced alarm methods, but it didn’t make it into the draft because we didn’t want to get too detailed.” The point is to talk about the logic of why you might use it, the criteria, not just the motivation. “You first say, ‘will we use them?’ Second, ‘what are the guidelines behind how we use them?’ ”

Working Group 5, Alarm Monitoring, Assessment, and Audit, will cover continuous monitoring, periodic performance assessment, and recurring audit of the alarm system. Some of the questions the working group had for the committee were: What are the motivation and justification for alarm management? What are the recommended paths or steps for making improvements to a poorly performing alarm system? What TR is the most appropriate for this content?

Working Group 6, Alarm Lifecycle for Batch and Discrete Processes, will give guidance for alarm activities of batch and discrete processes, expanding on multiple clauses of ISA 18.2.

Meeting attendees stayed true to their structured form at the end of the meeting by commenting on what they found most helpful during the meeting—a unified direction, keeping to the schedule, following parliamentary procedures, having a passion for the subject, productive teamwork and advancement, staying focused, preparation of WG leaders ahead of time, high quality of comments, energetic group, valuable newcomer input, and diverse perspectives.