Hence the two documents are very complementary―same problem, same goals, but from two different directions and perspectives. The alignment of ASM guidelines with ISA stages/clauses are shown in Table 1 and Table 2. Table 1 takes the topical orientation of the ASM guidelines and identifies the ISA-18.2 life-cycle stages in which the ASM guidelines are covered; and where applicable, it lists specific related ISA-18.2 subclauses. Table 2 inverts this, taking the ISA-18.2 life-cycle orientation and identifies ASM guidelines that will give the practitioner rationale, further considerations and examples when addressing each of the ISA18.2 life-cycle stages. (The tables show the author's opinion on the primary relationships; there may be other relationships not shown.)
Note that many of the ASM guidelines relate to multiple ISA-18.2 stages, as noted in the right-most column in each table.
Table 1: ISA-18.2 Stages Affected by ASM Guidelines
Table 2: ASM Guidelines Backing each ISA-18.2 Stage
It would be easy to go through the details and fault each document for not covering everything that the other one did. But that would miss the point. These are different documents, approaching the same subject from different viewpoints. Each editing team did a good job of staying true to its own approach and not trying to be all things to all people. The result is two documents that are very useful together. Here are some examples.
The very first ASM guideline shown in Table 1, Guideline 1.1, is "Establish company management support for alarm management." The ISA-18.2 document does not have a specific clause that says this precisely. However, as discussed earlier, the entire life-cycle-based organization, described in Clause 5, Subclause 5.2, provides a concrete basis for selling such a program to management. ASM Guideline 1.3 says, "Establish an owner of the alarm system and ensure adequate staffing". ISA-18.2 Clause 6.2.4 in the Philosophy section of the ISA document identifies four specific roles and responsibilities that must be made clear in the site's Alarm Philosophy document, including "ownership of the alarm system, the philosophy and related documents," as well as alarm system configuration and maintenance, resolution of technical problems, and ensuring that the alarm philosophy is followed.
ASM Guideline 1.4 is "Use a Management of Change (MOC) Process for Alarm Changes". ISA-18.2 dedicates a stage to MOC, which is documented in Clause 17, listing specific items that should be documented in the MOC process and stating that the MOC process must assure that "the appropriate stages of the alarm management life cycle are applied to alarm system changes."
ASM Guideline 2.12 and ISA-18.2 Clause 9 (Rationalization) provide very similar basic recommendations. Both documents state that an alarm must be something that requires operator action. Table 2, under ISA-18.2 Clause 9 shows this and other ASM Guidelines that relate to rationalization. Each document discusses the team approach, documentation needed, and alarm prioritization. ISA-18.2 adds a discussion on "classification" at this and other points in the standard. Among those listed, ASM Guideline 2.12 discusses several site experiences, providing information like specific types of personnel used, amount of time taken and results achieved. Also, ASM Guidelines 2.2 and 2.3 provide guidance, with examples, for making the rationalization effort more efficient and effective.
In the Human Machine Interface clause (see Clause 11 in Table 2), ISA-18.2 details specifics about alarm state presentations, such as using distinctive color, blink status and audible indications (Clause 11.3); and discusses specific items that should be on alarm displays. The ASM Guideline 2.7―"Provide effective alarm annunciation"―has few words on such specifics in the "How it Works" section, but references more details in the ASM operator interface guidelines, which were made available to the public in 2009 (Bullemer, Reising, Burns, Hajdukiewicz, & Andrzejewski, 2009). Moreover, ASM Guideline 2.7 provides more specific guidance through examples on effective visual and audible alarm annunciation in challenging environments such as multi-console control rooms and remotely located field operations.
Another case where the ASM guidelines go a bit farther than the ISA standard is with respect to alarms on process graphics. ISA-18.2 identifies that alarm information should be on process graphics (Clause 11.6.5). ASM Guideline 2.6 has a more extensive guideline on usage of alarms in process graphics, including rationale and discussion of example techniques.
Integrating safety systems
Both documents recognize that there may be cases in which the safety system, including the operator interface, must be independent of the DCS―each referencing the same standard (ANSI/ISA-84.00.01-2004). Each document is careful not to specify design of safety systems or to overlap the ANSI/ISA-84 standard. But each discusses situations in which both safety systems and basic process control systems deliver alarms to the operator.
ISA-18.2 specifically includes SIS input (e.g., SIL assessments and LOPA analysis) as part of its Identification Stage (Clause 8), lists safety procedures in its list of "other site procedures" to integrate with (Clause 6.2.19), and notes in the Human Machine Interface clause (Clause 11.10) that user interfaces may need to be separate. ASM Guidelines 1.9 and 2.15 make the general statements of intent―"Ensure that alarm management is a part of an integrated safety program," and "Provide safety system design and safety-related alarm handling." The guidelines provide some additional background, rationale and examples; then they arguably go a bit further than the ISA standard, by asserting with examples in Guideline 2.9 that multiple separate alarm systems, including safety systems, should be brought to the operator in a consistent way.