The importance of alarm mangement lifecycle

I'd like to return to one of my favorite topics for this blog posting. The issues is design versus fix. And let me just state it in clear terms: The reason why so many people are concerned about rationalizing their alarm systems is that the systems were never designed properly to start with. They just went from a bad design to a barely functional system with lots of bandaids in place. The risk associated with these systems should make you nervous about the potential they offer for incidents.

So, let's examine how you design a system properly to start with, and keep it from heading south. In doing so, I will use the reference to a lifecycle approach to alarm management.

Note that this is the approach that is being undertaken by the ISA18 committee, and reflected in the standard document soon to come. My opinion on this standard runs contrary to the assertions of one very service-oriented vendor who would like to sell you a book, and hundreds of thousands of dollars of services. They maintain that the ISA standard will essentially be unusable by the average person, and you will need to call on them for help. Au contraire.

Upon its release, this standard will allow you to understand completely how to design, analyze, control, and yes- even fix a broken alarm system. Six sigma junkies will love it. It is the culmination of several years collaboration of the world's top authorities in alarm management. When released, it will be the penultimate resource for understanding how to manage an alarm system and prevent issues in the control room associated with alarms. You will not need to buy a book to translate it. In fact, a book soon to be released will serve to explain in illustrative detail the underlying explanations of how alarm systems work, not just how to fix them. Save your money for that book, as it will be the ultimate textbook on alarm management- written by a truly recognized independent expert in the field.

If you use the ISA18 standard to first familiarize yourself with the lifecycle, and then read the associated text to understand what each of the elements represents, you will have a suscinct guide. It will help you approach any system in whatever stage of the lifecycle you may find it. Alarm management is not rocket science. It is solid, logical engineering and watchful monitoring utilizing the data an alarm system yields. You cannot get anywhere on any alarm system without first examining the data it produces. And you cannot fix it permanently without a well thought-out plan.

What quickly becomes clear to the average person is that if you design an alarm system properly,and continue to monitor that system for any unusual variance, you can maintain the alarm system in a highly usable and optimized state. You will need to document this design, and track it just the same way you document and track any good design. But I would warn you against wasting time to document an existing bad design. Proper documentation allows you to maintain original design concepts and logic of why alarms are placed where they are. Furthermore, it allows future engineers to track and change that logic as the process undergoes changes, or as process understanding exceeds what was preceived during initial design.

Utilizing ths approach, alarms are rationalized the way we did them in the days of yore- one at a time. How does that happen you might ask? New alarms surface as a process problem that caused an unexpected alarm to exhibit itself. Alternatively they may come as a request for a new alarm or configuration. Recall that in the old days, we "rationalized" each alarm as it came into existence, because we were limited to panel real estate, and cost of wire runs, etc. If it did not meet the criteria for availability, it was not approved for service. We need to re-establish that same rule set.

In today's systems, if you have a good alarm system design in place, and you have good management of change procedures, then a request for a new alarm should be treated in the same way. Each must be rationalized by the requestor as being necessary to the operation of the unit. It must then be approved for service and recognized as being beneficial to operations for the potential load it may add. Belive me when I tell you that this process reduces the number of requests for new alarms.

If you do not start this with a good design, then a bad design will just need bad fixes. And you may become subject to a decision to call in subject matter experts (SME's) to fix the problem. This often leads to the further discovery that so-called experts are only experts in the subject- they are not necessarily experts in your process. Suddenly, you experience what we used to refer to as “Matters to which Experts are Severely Suspect” otherwise known as a M.E.S.S.

This is the reason that the lifecycle of alarm management takes precedent over rationalization. Rationalization as a project is only necessary if you have not properly DESIGNed you alarm system to start with, and then not properly MONITORed and AUDITed its ongoing lifecycle. Note that the emphasis on these words is to point out that each is a part of the lifecycle. If you properly retain the knowledge of your operators and engineers, and the reasons for why certain alarms were necessary (or not necessary), then the historical record assists any future efforts. Others can simply review the alarm configuration to arrive at conclusions based on that past knowledge.

At this point in time in the history of alarm management, many people are talking about rationalization because so many of the systems lacked any adherence to these elements. If and when all systems have been through a proper redesign exercise, then adherence to the lifecycle will take precedence, as you should never need to undertake a rationalization project. It is for that reason that you should be careful of purchasing software packages that are totally focused on a rationalization project workflow. Their value diminishes quickly once rationlaization exercises have been completed.

This is the reason that TiPS LogMate was designed to address the entire alarm management lifecycle. We want to help you get your alarm system in order and keep it that way. Whether you need to rationalize, and want to use the automated tools built into LogMate to help you do so, or you want to monitor and maintain the system, we've got your backside.

Think about it. Opt for a good design, and you will gain the benefit for years to come.
If you are curious about the ISA18 Standard, contact us.

 

What did you think of this article?




Trackbacks
  • No trackbacks exist for this entry.
Comments
  • No comments exist for this entry.
Leave a comment

Submitted comments will be subject to moderation before being displayed.

 Enter the above security code (required)

 Name

 Email (will not be published)

 Website

Your comment is 0 characters limited to 3000 characters.