Why did they have to call it "Philosophy?"
I loved my engineering courses back in college. I loved the science and principles behind studies such as heat transfer, fluid flow and thermodynamics. Everything could be calculated and optimized. We could even do calculations by submitting decks of computer punch cards for overnight runs on a mainframe. And get back printouts the next day covered in "syntax error." So, back to the slide rule ... Actually, the first true engineering pocket calculator with trig, log and exponential functions arrived when I was at Louisiana Tech. The HP-35 was a breakthrough.
What did I not love? The dreaded mandatory non-technical elective. I disliked going from the rigor of the laws of thermodynamics to the pointless, definitional word-chasing that was philosophy and sociology. (Ok, I exaggerate a bit here, but some stereotypes are true).
I began learning all of the details of alarm management. Now, this is also a science with principles to follow and predictable outcomes. But I was surprised and disappointed when I first came across the term "alarm philosophy document." I thought, "Oh great, here's some corporate-level wishy-washy document with a lot of words and platitudes, but that actually says nothing of real meaning."
Thankfully I was wrong. The alarm philosophy document is important and essential. It is a working document that bridges the correct principles of alarm management, to exactly how those principles are customized and applied in your own organization and with your own work practices. Alarm system problems came about because of a lack of guiding principles for creating and maintaining an alarm system, this document supplies the rigorous knowledge and principles for success.
If you have not developed your alarm philosophy (AP) yet, here is some guidance. The AP describes a "to-be" state of an alarm system, not an "as-is." It is a prescription for how to do alarms right, not a document about how you are dealing with them now. It is a comprehensive, detailed document, not a three-page overview.
The AP is also an alarm design guideline for both new systems and modifications to existing systems. It is for both in-house use and contractor use during projects for the initial alarm configuration. The first thing it does is lay out what the alarm system is for and what kinds of conditions are allowed to use it. This is necessary because distributed control system (DCS) vendors make creating alarms so easy that operators often use the alarm system for things it was never intended to handle. For example, alarm systems can become a catch-all for miscellaneous status indications.
The very definition of an alarm is important. Remember, the customer of the alarm system is the operator, not staff, engineers or department heads. It is the person at the console who is responsible for running the process. The alarm system must therefore be designed to support that role. An alarm is an intentional interruption to the operator, and every alarm had better be important if we want the operator to take alarms seriously. Many post-incident investigations have found that operators ignored the alarm system leading up to an incident because they felt it to be useless.
ISA 18.2 defines an alarm as an "audible and/or visible means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a timely response." Please re-examine those very carefully chosen words. Unless the condition meets every aspect of that definition, it should not be allowed to use the alarm system to inform the operator. Note that the standard is weak about "audible and/or visible." Since every alarm is important, we want the operator to detect them all and both aspects of annunciation are necessary to do so. It is common for unimproved alarm systems producing thousands of alarms a day to have the alarm sounds turned off. But once alarms have been rationalized, the sound needs to be back on.
If you did nothing in alarm management but ensure that every alarmed condition in your control system met this definition, then you would likely have no alarm problem at all. But if you go to the control room and look at the list of alarms in effect, or that occurred this day or week, you will certainly find dozens that come nowhere near meeting this definition.
In our on-demand webinars we discuss how to apply the definition. We provide many examples of common situations that should never be alarms in the first place, but often are.
Here is an easy one. Do you alarm something whenever it is off? Likely that is a mistake. There is almost nothing in a plant that is not supposed to be off at some time or another. Off is a normal condition in many circumstances, and only abnormal conditions can be alarms. We see alarm screens covered in alarms because some equipment has been intentionally and rightly turned off. The correct paradigm is to only alarm something that is off when it is supposed to be on. This requires a bit of thought and logic, but such an alarm is easily achievable.
Here is another example. The definition requires operator action in response to an alarm. Well, what things constitute operator action and what do not? Here are some well-accepted examples of timely operator action.
Direct manipulation of the control system to effect a process change
Directing others such as outside operators to make process changes or take actions
Changing operating mode
Manual equipment changes - start pumps, manual operate valves, take samples
Begin troubleshooting/analysis of a situation. This is a common operator response. An alarm such as "tank 104 high level" requires looking at many things that could have caused that condition and addressing the ones that did. The direct operator actions will differ based on the cause.
Contacting other people or groups regarding a situation
Logging conditions for later examination, maintenance or repair, including initiating maintenance requests
And some things that are definitely not timely operator action are:
Thinking, "Okay, that's nice to know."
Thinking, "Okay, the next shift can deal with that tomorrow."
Thinking, "Okay, the system is working normally."
Writing something down in a logbook: except for a maintenance work order
Remember, alarms exist for the benefit of the operator. In addition to reinforcing this basic principle, the alarm philosophy needs to address many other aspects of alarm system design and management. That is why a comprehensive philosophy can run 50 pages or more.
Consider a familiar example of poor alarm design: a vehicle's check-engine warning. The same indication can represent anything from a relatively minor issue to a serious engine problem, yet it does not tell the driver what is wrong or what action to take.
An effective industrial alarm should do better. It should clearly indicate an abnormal condition that requires a timely operator response and provide the information needed to support that response.
What should an alarm philosophy include?
A comprehensive alarm philosophy addresses much more than the basic definition of an alarm. The more detailed the philosophy, the more useful it becomes in guiding future alarm management activities. For example, establishing specific alarm design considerations upfront can reduce redesign work and help ensure alarms are configured consistently.
A comprehensive alarm philosophy should address areas such as:
Alarm system characteristics: The capabilities and limitations of the control system.
Alarm design principles and configuration: How control system capabilities should be used to create effective alarms.
Alarm rationalization: How existing alarms should be reviewed and modified to align with established principles.
Alarm priority determination: How alarm priority should be assigned and used consistently.
Alarm documentation and operator training: What information should be available for each alarm and how operators should access and use it.
Alarm system roles and responsibilities: Who is responsible for each alarm management activity.
Alarm handling methods: How suppression, shelving, state-based alarming and similar capabilities should be used.
Alarm system performance monitoring: Which key performance indicators should be tracked and how teams should respond to the results.
Nuisance alarm resolution: How nuisance alarms should be identified and addressed.
Alarm detection, annunciation and depiction: How alarms should be presented in the human-machine interface (HMI) so operators can identify and respond to them appropriately.
Specific alarm design considerations: How common equipment conditions and operating situations should be alarmed.
Operator response to alarms: What constitutes an appropriate operator response and how that response should be documented.
Alarm system management of change: How changes to the alarm system should be controlled, documented and communicated.
A comprehensive alarm philosophy is often 50 to 80 pages, reflecting the level of detail needed to guide alarm management throughout the lifecycle of the control system.
Many sites also use more than one type of control system. In these cases, the main body of the alarm philosophy can establish common principles, while appendices address how those principles should be implemented based on the capabilities and limitations of each system.
For example, an organization may establish four alarm priorities as its standard, while one of its control systems supports only three. Another system may offer more than 100 possible priorities. The alarm philosophy establishes how the organization's principles should be applied consistently despite those differences.
An AP is a mandatory requirement of the ISA 18.2 and IEC 62682 alarm management standards. These standards specify what an AP must address and provide recommendations for additional content.
Summary
The alarm system is one of the operator's most important tools for detecting abnormal conditions and malfunctions. The alarm philosophy helps ensure that tool supports the right action at the right time. Developing a site-specific alarm philosophy is an important early step in alarm management and the document should continue to guide alarm system design and management throughout the life of the control system.
Ready to tame your alarm system? Contact us — or check out part one of the seven steps of alarm management on-demand webinar series
Review other Taming the Wild Alarm System topics in this 7 part blog series:
Part two - The most important alarm improvement technique in existence
Part three - Silence the noise: fixing chattering and fleeting alarms
Part five - What alarm rationalization really uncovers — and why it matters
Part six - Why did they have to call it philosophy?
Part seven - Beyond alarm management – doing more with a powerful tool