This post was written by Charles Fialkowski, CFSE, a safety systems specialist for Siemens; Luis Garcia, CFSE, senior process safety consultant for Siemens and chair of ISA's tank farm committee for the ISA84 Safety and Security Group; and Nicholas P. Sands, CAP, P.E., ISA fellow, ISA vice president of standards and practices, and co-author of the ISA book, A Guide to the Automation Body of Knowledge.
ISA defines an alarm as an audible or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a timely response. A safety alarm is essentially the same thing, but with the added metric of performance, or in layman’s terms, “how much risk can it reduce?” Risk reduction is generally measured in orders of magnitude (10, 100, 1000, etc.) If a company’s process hazard analysis (PHA) identifies and estimates a specific process hazard may be present every 10,000 years, yet there is a target of 100,000 years, it is easy to understand the company needs to reduce the risk by one order of magnitude (10) to reach this target. In general, it is a good practice for plant owners and operators to rigorously identify all potential risk-reduction layers to lessen the burden placed on their dedicated safety instrumented systems (SISs).
The industry has been struggling with alarm management issues for decades, but adding the ability to quantify the amount of risk reduction is introducing additional challenges. The newly revised ANSI/ISA-18.2-2016, Management of Alarm Systems for the Process Industries, states in its scope that the standard “specifies general principles and processes for the life-cycle management of alarm systems based on programmable electronic controller and computer-based human-machine interface (HMI) technology for facilities in the process industries.
It covers all alarms presented to the operator through the control system, which includes alarms from the basic process control systems, annunciator panels, packaged systems (e.g., fire and gas systems, and emergency response systems), and safety instrumented systems.” It provides a framework for the successful design, implementation, operation, and management of alarm systems in a process plant.
In addition, ANSI/ISA84.91.01, Identification and Mechanical Integrity of Safety Controls, Alarms, and Interlocks in the Process Industry, was released in September 2012, with the intent of establishing “a procedure to identify the process safety functions that utilize instrumentation to maintain safe operation in the process industry. In this standard, these functions are implemented by safety controls, alarms, and interlocks.”
As part of the continuing evolution of ISA-18.2, a series of ISA18 technical reports (TRs) is being developed to help alarm management practitioners put the requirements and recommendations of ISA-18.2 into practice. If you are interested in contributing your knowledge and experience to the TR development effort—and in gaining from the knowledge and experience of your professional colleagues at the same time — contact ISA18 co-chairs Nicholas Sands or Donald Dunn.
The scope of this latter standard is to address instrumentation classified as process safety safeguards by “the authority having jurisdiction” (typically the owner/operator or local regulatory agency) and to establish requirements for its mechanical integrity, including inspection and testing and documenting the inspection/test results. It is specific to process safety. As illustrated in figure 1 from the ANSI/ISA84.91.01 standard, the term “safety alarm” is recognized as an element of process safety, and in many cases, it may be the same alarm that is also covered in the ANSI/ISA-18.2 standard—so which standard would apply and why?
A process alarm may be categorized as safety control alarms and interlocks (SCAI), as defined in the ANSI/ISA84.91.01 standard. This diagram was important to help identify all the different safeguards that “might” be claimed by the owner/operator as a layer to reduce risk. These safeguards must be identified during the PHA of the process. Alternatively, ANSI/ISA-18.2 defines a safety alarm as an alarm that is classified as critical to process safety or the protection of human life. Safety alarms are placed in a highly managed alarm class that have additional requirements throughout the standard. Furthermore, the scope of the standard clearly indicates that alarm systems serve to notify operators of abnormal process conditions or equipment malfunctions. It may include both the basic process control system (BPCS) and the SIS, each of which uses process conditions and logic to generate alarms. Therefore, a “safety alarm” is an alarm as per ANSI/ISA-18.2 that can be considered a SCAI as per ANSI/ISA84.91.01.
The next question is, how much risk-reduction credit could one take for a safety alarm? Are there limits to the amount one could claim for the operator being able to step in during a critical process situation and effectively bring the process back to a safe state? Imagine a situation where a process hazard event occurred and was not originated by the BPCS. As a result, designers and reliability engineers decided to take one order of magnitude (10) risk-reduction credit for their BPCS. Also, because they identified another independent set of sensors connected to the BPCS, for alarming that same condition, they all agreed to claim another order of magnitude (10) risk reduction.
Thus between its basic process control function and its alarm function, the BPCS is now providing two order-of-magnitude (100) risk-reduction credits. Could this be considered a good practice? Sure, designers could try to argue that the BPCS they are using provides robust technology that includes independent and diverse operations to maintain their claim that two orders of risk-reduction credit would be justified. But we also must consider the human element that resides within this protection layer and that two orders of magnitude (100) in this case might be the recommended maximum limit in the amount of credit taken. One might also argue that if the safety alarm was connected to separate and independent sensors, had a dedicated HMI alarm panel, and was programmed with a safety certified safety control system capable of meeting safety integrity level 3 (SIL 3), they could justify taking even more risk-reduction credits.
Yet many designers, with reason, do not feel comfortable with this approach. It has been the center of ongoing debates about where we draw the line on overstretching the claims of safety alarm performance. Considering that most process safeguards are “dormant” in the sense that they would react only when predetermined process hazard conditions are present, it is the owner/operators’ responsibility to ensure that their performance is available at all times. IEC 61511-1, second edition, Functional safety – Safety instrumented systems for the process industry, gives requirements for the specification, design, installation, operation, and maintenance of a SIS, so that it can confidently achieve and maintain each safety instrumented function’s performance level (e.g., SIL).
Although this process has been well understood for years, it is not possible to predict or calculate human performance, only to estimate it. With humans (by definition required to react-operate in the presence of an alarm), there are variables that cannot be accurately measured or taken into account in operation environments.
Although there is guidance and “good practices” that avert fatigue and stress, questions such as “Does the operator have enough time to react to this alarm?” become critical. Could a designer confidently evaluate risk based on the premise that given 100 opportunities, the operator would fail only once reacting to an alarm and manually taking the plant to a safe state? ANSI/ISA-18.2 provides guidelines on how to design and manage the whole life cycle of alarm systems. Follow the standard and utilize the ability of the modern BPCS to deploy advanced process graphic HMIs, which incorporate muted color schemes that are clear, simple, and well-arranged to reduce stress and eliminate unnecessary distractions to the operator.
Figure 2 shows example metrics from ANSI/ISA-18.2. It is based on rates necessary for the operator to detect an alarm, navigate within the control system to the relevant data, analyze the situation, determine and perform proper corrective actions, and monitor the situation to ensure the alarmed condition is successfully handled. Yet these are averages that indicate there could be moments when the rates are much higher. Using key performance indicators is a good methodology to obtain real values and optimize them.
When considering the performance of “safety alarms,” it is implied that the failure of the operator to react propagates to a dangerous condition. IEC 61511-3 did provide guidance on claimed levels of performance with respect to alarms, as shown in figure 3.
Safety alarms facilitate taking credit for the action of an operator to take the plant to a safe condition. They are defined by ANSI/ISA-18.2, and as SCAI by ANSI/ISA84.91.01. Safety alarms should be considered in the PHA and included in the IEC 61511 safety life cycle and managed per the ISA-18.2 life cycle. Other points to consider when evaluating your safety alarms performance are:
Safety alarms have potential as effective layers of protection, with the possibility of a risk reduction factor of up to 100. In practice, that risk reduction factor is difficult to achieve. In fact, there may be facilities where alarm system performance or individual alarm performance would indicate that no risk reduction should be taken.
About the Author
Charles Fialkowski, CFSE, has been a safety systems specialist for more than 20 years, with a focus on burner management (BMS), fire and gas, and high-integrity pressure protection solutions. He is a voting member of the ISA84 committee and an ISA course developer and instructor for SIS and BMS. Fialkowski received his electrical engineering degree from Oklahoma State University and is currently the director of process safety with Siemens Industry, Inc.
About the Author
Luis Garcia, CFSE, has been a specialist for more than 20 years, with several publications in the Americas, Europe, and Australia. As a member of ISA, he chairs the tank farm committee for the ISA84 Safety and Security Group. Garcia is a process safety course developer, and he teaches several courses in process safety in two languages. Garcia graduated from Liverpool University, U.K., with a BEng in metallurgy and material science. He graduated from San Joseph Technical College in Argentina as a mechanical engineer, and he is currently the senior process safety consultant for the Americas with Siemens Industry, Inc.
About the Author
Nicholas P. Sands, P.E., CAP, serves as senior manufacturing technology fellow at DuPont, where he applies his expertise in automation and process control for the DuPont Safety and Construction business (Kevlar, Nomex, and Tyvek). During his career at DuPont, Sands has worked on or led the development of several corporate standards and best practices in the areas of automation competency, safety instrumented systems, alarm management, and process safety. Nick is: an ISA Fellow; co-chair of the ISA18 committee on alarm management; a director of the ISA101 committee on human machine interface; a director of the ISA84 committee on safety instrumented systems; and secretary of the IEC (International Electrotechnical Commission) committee that published the alarm management standard IEC62682. He is a former ISA Vice President of Standards and Practices and former ISA Vice President of Professional Development, and was a significant contributor to the development of ISA’s Certified Automation Professional program. Nick is the co-author of the ISA book A Guide to the Automation Body of Knowledge, and has written more than 40 articles and papers on alarm management, safety instrumented systems, and professional development. Nick is a licensed engineer in the state of Delaware. He earned a bachelor of science degree in chemical engineering at Virginia Tech.
A version of this article also was published at InTech magazine.