Once you have analyzed the issues (the "A" in DMAIC) that led to a badly performing alarm system, you need to now institute the improvements (I) identified as necessary to resolve the current situation. These MAY come in the form of a rationalization exercise, if a system redesign is called for, or they may take other forms. Often, the information that this exercise yields allows you to make a prioritized list of improvements. If you need help in that area, we have several people who can help you get there.
In the long run, a rationalized system is extremely valuable. Many will tell you the effort itself is an education process and yields greatintrinsic value. However, such an effort runs the risk of dominating the scenery from a management viewpoint, and returning very little obvious value for its effort. In the future, regulatory issues may require a complete documentation of the system, in which case this may become a requirement, but other pressing issues should not go untreated at the expense of the effort.
In other words- use good common engineering judgment to preserve the capital to perform that task when it is absolutely required. Build respect from your management for wise use of the resources they put at your disposal. That will yield returns in the form of political capital that is necessary to succeed.
All roads lead to the logical last step of control (C). Put the proper controls in place to see that what you have fixed does not revert to its former broken state. The proper way to do this is to institute continuous monitoring (usually in the form of KPI's- Key Performance Indicators) that allow you to know when the system is getting out of control, and requires a revisit. Additional treatment is even easier, as all the methods, measurements, and tools are in place for quick updates. These ready measurements yield speedy- even automated- analysis and improvement.
The real secret here is that you don't want to look back at this problem in three years and find out you blew your entire capital on resolving only a part of the issue. Be aware that there are others who will try to convince you to take that path. Avoid that trap and make a few myths of your own.
Alarm management is neither a secret "void", proprietary to one company, nor is it rocket science. Most of the information needed to perform Alarm Management activities (the how-to) has been published in public documents. (see www.tipsweb.com/amlibrary.asp ) And, as stated, the EEMUA dcument gives a very concise view of the technical expectations.
So, buy a copy of the new EEMUA 191 Guide, and you will be 80% of the way there. It tells you how to measure, what to examine, and how to go about it. (Order one at www.eemua.co.uk )
If you're looking for a book on the subject, save your money until one comes out from a true expert on the subject- one who has no service sales axe to grind- one that addresses more than just the rationalization side of alarm management. Until that time, there is plenty available in the papers (www.tipsweb.com/amlibrary.asp ) and EEMUA (www.eemua.co.uk ) guidelines.
Mendacity stinks. Don't get it stuck to your shoes.
]]>Examine TCO. This is just a primer. You'll find more to it than I have listed. A good look at these costs on the front end can help to avoid a massive unplanned outlay.
]]>
This same friend was noting that one service company out there claims that they have a 7-step approach to alarm management. Another claims a 6-step approach. I'm trying to figure out what it is supposed to cure you of, since everybody that has tried them is still looking for answers. It's like the Britney Spears of rehab programs. They want you to have to return for rehab often and expensively.
This friend advocated a 12-step approach which stole from the famous AA aproach. A few conversations later, and shazaam- the concept was born of - Alarmaholics Anonymous. - We urge you to join if you share the symoptoms, and are ready to solve the problem. Help us end the senseless addiction to more alarms. What are the symptoms? Here are some:
Have you been sneaking in at lunch when nobody was watching and putting an alarm on the system?
Do you need an alarm when you get up in the morning, and perhaps do you prepare one before you go to bed at night?
Do you have dreams about alarms and you can't reach the acknowledge button? (this one came from a client)
Do you feel you can handle a larger number of alarms than others?
Do you keep a small alarming system in your pocket in case you need to be alarmed in a place where you might otherwise have not had access to them? (Crackberry users apply here)
When you arrive at work, do you just not feel right until you've had your first alarm?
If you go to a party, is it important that the house have alarms for you to feel comfortable?
Do you prefer to have your alarms alone? Do you find yourself not wanting to be in a crowd when an alarm goes off?
Do you feel that others don't notice that you are dealing with alarm issues every day?
Do others tell lies for you to cover up your alarm problem?
All of these can be symptoms. Please e-mail me if you have more. So here's the 12-step approach:
1. You have to admit that you have an alarm problem, and you want to solve it.
2. You must believe that you can be helped.
3. You're willing to ask for that help no matter what it means.
4. You are ready to inventory how big the problem is.
5. You begin by admitting to others that you have an alarm problem.
6. You are prepared to resolve whatever defects are found.
7, Now- make the call to ask somebody to help you. (TiPS has operators waiting...)
8. Make a list of all the problems this has caused besides just the alarms themselves. (We call this the situation awareness approach)
9. You fix those problems wherever possible except when the cost is greater than the return.
10. Continue to inventory and track the problem symptoms. (KPI's come in here.)
11. You now enter a greater path of situation awareness understanding, and study all of its nuances. Continuing to keep a monitor on potentials for back-sliding.
12. Have a spiritual awakening as a result of these steps, and want to spread the results in the form of assistance to others who are trapped in the same issues. (Attend TiPS User group meeting.)
This was written with a tongue-in-cheek approach, but as I examine the steps, I realize how close they are to what actually has to be done to resolve an alarm management problem. And I can guarantee you that every alarm management problem is so different that there is no tried-and-true 6- or 7-step approach that will cure them all. Each alarm management situation needs to be considered in its own standing, and an approach crafted to fit the particular situation.
As I write that last paragraph, I also note that there is another service company who advocates that they have utilized four drastically different approaches depending on the circumstances. I believe that is getting a little closer to the reality of the situation. But they negate this idea by then proposing the aforementioned 6-step approach.
Do you have an alarm problem? We can help. We've been helping people SUCCESSFULLY resolve alarm issues since 1990. Come to see us at the TiPS/ Expertune user conference. Held in Beautiful Austin, Texas- we promise to have at your availability the world's leading experts in alarm management. Sure cures to alarmaholism. You can schedule some private time with these experts, and hear their presentations. Product training is available.
Yep- LogMate (http://www.tipsweb.com/products/logmate/) is the sure cure for Alarmaholics. It won't just help you inventory the size of the problem, and get it behind you- it will keep you informed should it ever rear its ugly head again.
]]>So-to borrow from Gilda, a lot of you are probably wondering "What's all this talk about rations on libations"? Well, I'm here to enlighten you. And like the "Oh-well- Never mind." I also realized they're talking about Rationalization. Was that ever a shock. I was wondering why so many people were inviting a service company to come in for a project that never seemed to make anybody much better off. Especially if it meant they were cut off on libations. Here's what my research has found.
To start with, I looked up the word RATIONALIZE in Websters. ra·tio·nal·ize: to attribute (one's actions) to rational and creditable motives without analysis of true and especially unconscious motives (rationalized his dislike of his brother) broadly : to create an EXCUSE or more attractive explanation for (rationalize the problem)
So, do I need for people to come to my plant and make up excuses for my alarms? Rationalization as a word and a practice is at the least overused, and is nominally something done to make an excuse for the fact that we put in a bad design to start with. So, let's re-look at alarm systems as a design problem rather than a fix-it problem. If you get the design right, it's fixed for good.
Perhaps we should look at the problem in the way that is supported by the ISA's SP-18 committee. As already stated, the fact that you have a bad alarm system is due to the fact that it was not designed properly to start with. Or, perhaps it was designed properly, but it was not engineered properly with the protections and safeguards in place to ensure that it would not grow to an unmanageable state. That is because there was no attention paid to the alarm system design lifecycle. The upcoming ISA SP-18 specification will pay particular attention to alarm system design lifecycle. The point is that if you put the proper design in place, and install proper safeguards and practices, your alarm system should NEVER become a problem. So, let's stop paying so much lip service to alarm rationalization, and instead pay particular attention to alarm system design and the tools to protect its integrity.
How do I do that?
Alarm management is not rocket science. There's no special algorithms, and no special proprietary secrets necessary to make it work. The EEMUA 191 document is written just for those who need to know how to get their arms around it, and it's not really that bad to read. You can buy it with your credit card at www.eemua.co.uk. If you have designed your system such that it is now out of hand, an alarm system lifecycle review will tell you that you need to rectify that to get it back within a state of control.
In the late 80's and early 90's there was a lot of talk about process optimization. There were people who would come to your site, and optimize your process. When they left, things ran well- all the loop controllers were tuned, all the targets were properly set, and things seemed to run fantastic for a few weeks. A few weeks later- back to square one. They did not install the tools to protect your unit from falling out of an optimized state. In fact, they did not want to install such tools, as that was how they made money. If they did install a tool, it was so rudimentary as to make you need their help anyway.
Such is the state of alarm management that is being sold by a handful of service companies. Yes, they offer software packages, but it is not in their best interests to make that package address your alarm system lifecycle. If it did, their income would drop drastically.
What is the pattern? A team comes on site- does a rationalization, and all is well for awhile, and then we're right back where we started. Why is that? It's because to be successful, we need to institutionalize and internalize the processes associated with good alarm management. And we need to correct the bad practices that allowed the alarm system to get into the shape it is in to start with. These need to be incorporated as a part of our internal processes and practices. Just as we did with process optimization (if we did). And as Mr. Ian Nimmo says (www.mycontrolroom.com) you need to consider all the factors associated with good SITUATION AWARENESS (his term- read his papers).
What is meant by that? It's simple- other than absolute nuisance alarms- all alarms exist for a reason. Unless you discover and resolve the cause for an alarm, it makes no sense to get rid of it just for the sake of reducing alarms. It will simply reappear, or- lead to an incident. Too few alarms can be more damaging than too many alarms. This means that some alarms just cannot be reduced without additional work around the control automation subsystems. Some have learned this the hard way on some of their initial rationalization attempts.
So- just what am I getting at?
Some service vendors out there want to sell you a rationalization project. They would also like to sell you a product which supports rationalization the way they see it. And at least a few of them have a very narrow view of the subject. They do not recognize the lifecycle aspects of an alarm system, just their desire to rationalize. So what do you do with their product once you've rationalized? Well- its only valuable if you need to rationalize again, and it is their goal to ascertain that need will exist. That's rather disappointing if you've designed a complete bid process around finding a product that will help you rationalize your systems. Quite frankly if that product did what it was desired to do, you could use it once and throw it away.
Much like the Webster's definition of the word rationalize, their motives are to create a rationale to hide the true motives behind their actions. i.e they've rationalized rationalizatrion, and made it sound as if it's a final answer when it is not. It's ignoring the causal drivers for bad alarms Essentially, it is akin to fixing a flat tire on your car everyday,rather than finding why it goes flat.
Ignore the noise you're hearing in this area long enough to consider a lifecycle approach to alarm management. Think of your alarm system as a system that needs to be properly designed to start with. If it is not, or was not, then rectify that situation, but be certain that you consider the need to get the system under control. There's a lot that's been written on this issue, but its not attractive because it says you have to alter practices and procedures and perhaps even take on additional automation changes rather than just doing a project and checking it off the list of to-do's.
So, if you have a new alarm system, put the tools on to start with to be certain it is properly tracked and kept within reasonable limits. You'll save massively in the years to come. If you have an old one, consider what is needed to get it back to a state of good design.
Yes, excuses may thus have to be made for your existing alarms, but your mindset will be one of getting it within a realm of control and tracking to be certain it stays there rather than just having to re-do it every six months. And the tools you choose will support this approach rather than one of continuous rationalization.
Place rations on their libations and they might come to the same conclusion...
I'll be addressing this issue more in the coming months.
�
]]>I recently attended a presentation where the discussion was mainly focused on alarm rationalization. One of the reasons given for alarm rationalization was to reduce the number of floods. There was disagreement about what that meant, and several opinions offered. Prior to that I had been at another meeting where half of the group seemed to think they were in a state of constant flood, while the other half seemed to think that they had no alarm issues at all. At this point, I realized that perhaps everybody does not measure a flood using the same metrics. So, that gets us to the root of today's subject - just what is a "flood"?
According to EEMUA guide, a flood is anything exceeding 10 alarms in 10 minutes - or one per minute. I have looked at enough data to tell you many units are in constant flood by that measurement. However, the operating team does not perceive themselves as being in a flood condition. It is simply their normal alarm load. That team considers a flood as a group of alarms that they simply don't have time to deal with before something bad might happen. In other words, alarms associated with an upset condition, an equipment malfunction, or a process wobble, and perhaps a potential incident in the making. Often, a flood consists of unfamiliar alarms since they are outside of normal operating conditions and a range of normal training/familiarity.
That leads us to the unusual conclusion that "flood" as specified by data is not necessarily a flood to the operator. The operators know why the alarms are there, and they are essentially ignoring them because he knows they will not lead to anything significant. Some of them may even be there because they elect to leave them active for any number of reasons. In fact, once innured to the sound of the alarm annunciator, he is so comfortable with these alarms that he'd probably feel uncomfortable if they were not there. It's kind of like the friend with the overly talkative spouse. Did you ever notice how they were able to function through the incessant prattle despite the fact that it was starting to drive you up the wall? The human mind is capable of ignoring things in this way. This is why in the case of many incidents, ignorance of alarms has been noted as a contributing factor. Ignorance is a strong tool, and is in fact can be a good quality in the right circumstances. Soldiers learn to focus on their goals with bullets flying over their heads. Air traffic controllers learn to analyze situations under circumstances that are increasingly pressurized. Beekeepers learn how to ignore even more.
So, how does this relate to EEMUA guidelines? Simply stated, EEMUA guidelines are not applicable to a unit until that unit has observed, and put into practice ALL of the EEMUA recommendations for alarm management. Paradoxically, if you do not clean up your nuisance alarms, you will not pass the EEMUA spec of normal alarm state, yet your operator may not feel that he is in any state of disrepair. The EEMUA benchmark becomes vital only at the moment you accept the first tenet of the EEMUA documant:: Every alarm has to have an associated operator action. Subject to those conditions, every alarm that occurs beyond the allowable level contributes to a flood. On the flip side, every alarm that does not require action may not be contributory to a flood. From a purist viewpoint, it is, but not necessarily to the operator who is ignoring it. So why all the rush to rationalize alarm systems to reduce flooding? Does it really work?
Our data shows rationalization costs a lot of money, but doesn't necessarily solve the problem. Thus the reason for all of the papers purporting new cost-effective methods. In fact, our experience shows that the most bang for the buck comes when you get rid of all nuisance alarms, and using the information around the others to point you to the situations for which they exist. In other words, it points to Situation Awareness as the cure. This is contrary to all the written expert opinions currently in print.
Much study has been done surrounding this problem by the ASM Consortium (ASM is a registered trademark of Honeywell). Their members were the first to explore alarm rationalization some 15+ years ago. Shouldn't that mean they are now satisfying the EEMUA constraints of the EEMUA 191 report which they co-produced? Their evidence says no.
See the paper they published on this issue.
Yet, their members don't seem to think they have drastic alarm problems, and many feel they have the alarm problem pretty well in hand. Not totally resolved, but in hand. And that's fifteen years after having started. Again that points to the fact that perhaps the problem solution does not lie in all of the things they've tried. Again- I point to a study in Situation Awareness as the required answer. That is the real jewel they have uncovered.
As a short diversion, another path has been taken lately that deserves some attention- tools that will resolve the issue once you have fixed the basics. These tools are based on principles for smart alarming, or state-based alarming. I have met lately with DCS providers and learned that tools are coming which will address this situation in most new DCS systems. I think you'll like them once you see them. Unfortunately, most require system upgrades to recent releases to make use of them. Where does that leave us with respect to legacy systems which will be with us for many years to come?
It has not been TiPS policy to recommend tools that attempt to handle alarm dynamics POST-DCS. There are many reasons for that. Read my post on dynamic alarming to see a few. However, we have seen some tool sets that deserve consideration.
The first is from a company called UReason. See their website at http://www.ureason.com/ . These tools allow for a super-imposed alarm handling screen that "subsumes" alarms, creating a display that makes more sense. For example, it will recognize patterns, and reduce the alarm count automatically by knowing such things as when a pump shuts off, or when a start-up or shut down condition is occurring. Their OASIS system will use pre-designed filters to deliver only the information pertinent to the situation. In other words, those seventeen alarms you once received will be subsumed, and replaced by a single alarm that tells you the pump is down. Or, if the pump is automatically replaced, it may not bother the operator with the information at all - only sending its data to maintenance for service follow-up.
Note that the level of attention and maintenance for such a super-imposed system is increased to levels beyond even the maintenance you have NOT been providing to your alarm system. However, for those who have gone to the trouble of cleaning up their alarms, this could be a next logical step. WARNING!! DON'T TRY IT WITHOUT HAVING CLEANED UP THE BASIC ALARM SYSTEM FIRST. As a voice of experience from one who has tried it both ways, I can tell you that it has no chance of success if you don't do it in the right order. Also, don't try it in conjunction with complex state-estimation models. They have never worked, for a variety of reasons. Handle only the simplest configurations first, increasing your complexity to a level as you see the operations team can support it. The rule here is that if it must be maintained by engineers or mathemeticians, then operators will not receive sustained benefits from it.
To be fair, I should state that I have seen cases where complex model-based systems did work, and were maintained past their initial installation for some period. All of these successful examples share two common traits. The first was that the problem could not have been solved any other way. The second was that the value of solving the problem was so great that it justified the PhD mathemetician who had to be kept on the problem. Note that one other issue was that the PhD mathemetician's interest was also maintained because there were enough twists and turns to the solution that it required his ongoing inventiveness to keep resolving new issues. Perhaps more of these would be in existence if somebody were to offer an inexpensive and efficient expert system package...
We have also seen products from a company in Louisiana called Prosys. http://www.prosys.com/. Having not seen their tools first-hand, I can only guess what they have from descriptions of their products. The approach is similar - a replacement of the DCS alarm screen, but giving a more powerful view to the operator. My understanding is that they have a few examples of these having been installed and maintained for an extended period.
With proper implementation of these tools - not trying to take on the world, but simply to give the operator better information, it is possible that flood management - the holy grail of alarm management - may be within reach. We're certainly heading that way.
]]>The comment from a battle-scarred veteran was "Yes- our management is asking that same question. They want to know what they have received back for the $x Million (it was a shocking number) they've invested in all of these rationalizations, etc. They noticed that the control room seemed a bit quieter, but they still saw the same shut-downs and plant upsets as before."
Their answer to management was that they wanted to work with the same vendor who had not yet solved their problem to invent plant state estimators, and develop a smart alarming system. WARNING Will Robinson! Aliens approaching. Be careful of what these aliens promise you. You'll be stuck with the result, and they'll exigrate back to their home land. Management's response back was "You mean we haven't already got that for what we've paid?" I repeat my mantra. You ain't seen an alarm flood until you've seen a smart alarm flood. As a veteran with battle scars in that area, I've seen too many brilliant people wreck their ships on those shoals to bet that a service provider is going to resolve this problem.
Don't take this wrong- the vendor they hired did just as promised, and did a good job of rationalizing their alarm system. Its just that at the end of that alarm rationalization rainbow, the leprechaun didn't have the pot of gold they'd hoped for. This is not necessarily the service vendor's fault (though promises were PROBABLY made to get the project started). It should have been obvious that a simple rationalization could not solve the problems that made the system get bad to start with- after all , it didn't change any processes, just an underlying configuration.
Again- a warning. This alarm management stuff is NOT rocket science, and reducing alarms is not the end resolution of your problems. Alarms are the automation backstop of the plant, and thus the best indicator of your problems. But, other than nuisance alarms which are easily dispatched, the real bottlenecks lie elsewhere. So, perhaps you can save all that rationalization money and invest it instead in the bottlenecks your alarm system is pointing to. Upgrade your control room. Redo your graphics. Increase your maintenance interval. Install better communications. These (and their cousins) are usually the root cause of alarm problems.
So- lets take this smart alarming thought process a step further- because I've been there and done that. Suppose you and I- with our vast intelligence- sat in a room and came up with every possible scenario the plant might face, and designed an expert system that would automate the plant through and past each problem. Well, guess what- we'd miss. And the ones that caught us would be the no-brainers that we were too smart to think of. We used to say that the solutions we offered didn't solve the problem, but only confused you more than before. However, we felt you were confused on a higher level and about more important things.
Alright- where is the ROI on alarm management? Actually, it's pretty easy, and it has to come from operations. How many times have you lost a pump, and how much did it cost? If you can avoid a lost pump due to a clearer message, what does it save? The answer to this question lies in benchmarking pre- and post-alarm management effort. Problem here is- if I do prevent a lost pump, how can I claim that savings if I don't know whether it would have happened otherwise? I cannot run parallel timelines and see what happens in another universe with different decisions...
So, let me help you get true ROI out of your alarms management investment. Don't bite off too much too quickly. Put the measurement tools and benchmarks in place up front. Let the data tell you where your problems lie. If you have a problem that can be solved by alarm rationalization, analysis of the data will indicate that. If your problems lie elsewhere, analysis of the data will indicate that. But don't put the cart before the horse. Don't spend $5Million on rationalization exercises that will produce no measurable effect. If you've got $5Million to spend, let the data point you to where your problems lie.
I suspect you'll learn that your alarm data will point you to several areas that seem obvious once you've seen the data. Oh- and stop looking at alarm management as an ROI exercise- it's NOT. It's really a RISK MANAGEMENT exercise. You should be looking at the dollars you are putting at risk by NOT optimizing your alarm system. This is always the scarier side of this equation, but infinitely more realistic. We'll have more articles dealing with this issue in the future.
]]>Cool- huh? But, that's not the data I want to discuss. The item I'm interested in today is that of the process data's importance to alarm management during the rationalization exercise.
Rationalization is something which TiPS advocates should be internalized as much as possible, and in most cases, should be under the realm of operations management. I expand on this philosophy in a two-part technical paper series. YOu can see the first installment of that series at http://www.tipsweb.com/downloads/A_Practical_Approach_to_Alarm_Management_Part_1.pdf
The process of rationalization often is one of the few opportunities for the DCS/ instrument engineers, control engineers, process engineers, maintenance and operators to sit together in a room and talk about how operators use the control environment. The tools involved are what each of these other factions work to have available for what the process engineer hopes is making what is planned. As such, there is a lot revealed about just which pieces are used, and how they are used, maintained, and intended. This process is thus very valuable. In fact, it is so valuable that it should not be shopped out to a vendor, except as an enabler, or as an internal partner to the process. Much of the time spent with a vendor is in the process of educating them to the level of what your internal people already know. The exception here is that alarm management specialists DO have a knowledge of the process necessary to accomplish a good project, and a partner in this process has a stake in making things work. Bottom line- avoid strictly project work except to fill in the blanks.
I used to visit an operations manager (who shall remain nameless) in Canada who told me a story which I'll share.
"I've looked this process over from a historical standpoint, and discovered we're operating at about 150% efficiency. I base that discovery on the fact of all of the justifications that have been put through for all of the projects we've performed over the past 10 years. Each small project was justified to get, and post-audited as receiving x% improvement. Well, all those improvements added up equals 150% or thereabouts. Now, we both know this can't be true, but it's taught me one thing. That is the importance of having continual projects in the plant. It seems that projects cause people to be interested in what we're doing, and they continue to fight against the natural tendencies for things to return to chaos. (remember the second law of thermodynamics- all things tend to greater randomness- it's still true). So, I like to keep projects going that keep people communicating and pushing each other. Otherwise, they get bored, and things fall into disrepair."
That's an interesting concept. I get from that the need to communicate to one another what is going on, and what is working, and what is not.
Years ago, I was doing some modeling on a unit. I was using one of those fancy Neural Net packages. (Not the nets with scribed steel handles- those would be knurled nets- totally different) Again- no names. I was told by the engineer who gave me the data that two specific variables were the most important variables to the control of the unit. Guess what? They were flat-lined. The engineer thought this was possibly correct, as they needed to be relatively flat to accomplish tight control. No- I mean they were flat-lined. NO data change at all. Just one value. In talking with operations, those sensors had been dead for over two years. They had developed other methods to accomplish control (essentially things which mirrored the action of these variables). Without that discussion, and a review of the data, the engineers would have never understood how operations was controlling the unit. This is just one story among many where similar discoveries were made. Neural nets were cool for the fact that they renderd the sensitivity, and data range of the variables involved in the model. I could go on, as that's fun stuff to talk about, but let's get back to how this relates to alarm management.
The point here is that the rationalization process allows a unique opportunity for a thorough operations review. TREAT IT AS SUCH, and you will benefit from more than a rationalized alarm list out of the exercise. One of the most overlooked items in this process- and you will not see this in any book, guidelines, or paper yet published- is examining the data activity around the alarms you assign. What does that mean?
Within the rationalization process (assuming you rationalize the complete operating unit), you will end up with a prioritized list of alarms. For at least the top priority alarms, and safety critical alarms, examine the data activity under these alarms. If you have time, you should do it for ALL configured alarms. To do this, you will need access to your process data historian, and the statistical toolkit it contains. Examine the data distribution, range, and standard deviation of each of the sensors you have rationalized. What do you see? Is it what you would expect? Why or why not? Have you assigned a high priority to alarms on sensors that are flat-lined? Have you assigned a low priority to an alarm on a sensor that is all over the map, and reflects something important to the process? This is just the tip of the iceberg of the discoveries you will make with a process data review of the important variables.
With this data in hand, and the process specifics it reveals, intercommunication between these factions of your plant is priceless. As my Canadian friend would point out- it forces communication for the purpose of a project that might not otherwise have happened. It gives people who might rather avoid each other a reason to have to talk. And that's valuable to your operation.
Lastly, let me take this opportunity to also issue a warning. There is a practice being proposed by a service company which they call "focused rationalization" or something like that. RUN AWAY from this methodology. I point to my earlier logic to help you understand the danger of this approach. The method of this madness is to focus rationalization efforts only on the alarms which have activated recently, or ones you designate as important. On the surface, this may sound rational.
Where does it fall apart? If you have alarms which do not activate because they are flat-lined, they may not get rationalized. If you have a sensor which is being used by operations to take the place of that sensor, you may not even place a properly prioritized alarm on that sensor. And even if one is identified as important- is it valuable to have an alarm on a flat-lined sensor?? A review of the historical process data would reveal this. Additionally, we all know that by Murphy's law, it will be the alarm which hasn't activated- and the operators therefore had little experience with, that will be the one which will cause the next incident- the one we ignore because it never activates. This method must have been hatched by somebody with very little statistical process data experience. It is statistically unsound, and could be very dangerous to your process. Unless you like talking to regulatory bodies and lawyers.
TiPS advocates that if you are looking to reduce your rationalization effort, it must be with a consideration of overall process unit risk. And any unit which is slated for rationalization must be FULLY rationalized. You can read more about this in our recent two-part series on Practical Alarm Management. The first part is available on our web site now, and the second part will be released next month. I hope you will read it, and comment.
]]>In the late 80's software was passing from the mainframe domain to the desktop PC. It was an exciting time. Those software companies who had invested huge sums in mainframe programs told their clients that PC's were "just a fad" that would pass.
This was a mistake. They failed to realize the inherent desire of engineers to be in control of their own technical solution domain. They also missed the fact that the mainframe IT organizations were back-charging their departments with horrendous usage costs for each "CPU-based time unit" that they made the mistake of using. This charging method meant that users tried to limited usage (or their boss did) to avoid interdepartmental charges, and that was exactly the opposite of what you wanted engineers doing when they were trying to resolve tough process problems.
Those software companies who saw the writing on the wall invested in the major task of rewriting their software to take advantage of both the new availability the desktop machines offered, and the desire to have it there. Then there were others. They saw the desire, and understood the market change, but didn't want to make the investment, hoping they could continue to milk the investment out of what they had already written. So they wrote "wrappers". These were interface programs- shells essentially- that allowed the user to access program basic setup within the PC environment, and then fed the information in batch form to the mainframe. In some circumstances, the complexity of the application justified this approach, as PC's of the day weren't quite powerful enough to replicate the application. In others it was simply laziness and greed, or perhaps some hope that the naysayers were right- it was just a fad, and they were better off waiting until things changed again.
This pattern is repeating today in traditional process industries.
History repeats itself
Unfortunately, in the process industries, there is not a large appreciation for software standards of practice. This is not true in some other industries- financial, and risk management are two that come to mind. As a result, many of the software vendors who service the industry are hoping that most of their users are not aware of the thin-client revolution. The cost to redesign their applications (again) could be horrendous.
Living around Austin, Texas, we have seen software standards taken to their ultimate test. We were in the center of the dot-com (dot-bomb) revolution. The software platform necessary to support the dot-bomb revolution had four basic requirements. It had to be quick to develop; it had to be easy to install; it had to be easy to use; and it had to be cheap to maintain. Without those elements, you could not expect to sustain the minimal profit margins that these companies were expecting to make up in volume in a quickly evolving market. In many cases, it turned out that the volume was zero, so low percentages of zero caused for shuttered companies (and a flood of used Herman Miller chairs on ebay).
Shuttered companies aside, the design techniques and development platforms to support this software revolution are newly available. They are phenomenal in their value and reach. And they enable better software. Those willing to make the herculean effort to redesign on these platforms realize the instant resultant lower TCO (Total Cost of Ownership) for their clients. They also guarantee extended viability for their products as interoperability issues come to the forefront. this is very similar to the revolution caused by the introduction of the PC desktop in the '90's.
I want to sing the praises of the MS ASP.NET architecture. TiPS Inc. has made the large investment over the past few years of redesigning our products to work within this architecture. As a result, we become instantly interoperable with any and all other products built under this framework. Our clients avail themselves to our products over a true thin-client route that requires a dedicated investment to undertake and maintain.
unfortunately, this architecture allows the use of a ".NET wrapper" just the same as a PC allowed the use of a menu-driven batch file to be created. At any rate, it is only a wrapper- not a true thin-client application.
Buyer Beware
I recently saw a company advertising their "software suite that was built on MS. NET" Hah- the "suite" is a container built on .NET that then allows web-browser interface to these legacy applications. Their products they want to sell you under that container are still legacy products built several years ago. I guess the container or shell makes it viable to say the suite is "under" this framework.
In other industries, as mentioned before, the first questions asked of any software sealesperson are the right questions. They stop you mid-feature description and ask: Is the APPLICATION itself built on a thin-client architecture? If not, what is it built on? Any other answer causes no further questions to be asked. Yes, they will allow you to finish, and polite ones don't even look at their watches. These users have learned the Total Cost of Ownership (TCO) has very little to do with features of the software. Modern architectures allow any software to add features on request. But a bad architecture will live with you for many years, and make you wish you had asked certain questions up front.
A quick check you can employ is how does the application deploy clients? Do they have to be installed (even if automatically) on each machine, or do you just open up a standard application such as Internet Explorer, and have instant access to the application? Lack of a true thin client is a sure sign of a cluged application infrastructure. True .NET applications make full use of web services that is integrated into the microsoft framework.
Other signs to look for are: What about integration with MS SQL, and true real-time access to the SQL architecture? How long does it take to perform a query on real-time, instantaneous results? Are results available in real-time, or does data have to be batched in for occasional review? Does a different application require installation of another module?
What about ease-of-use? Does it seem intuitive to use? Can you just click on things and start to get answers? Is there an effort towards two-click resollution? Recall that this is the model that Microsoft brought to the industry. As an example: Though MS Word will do a lot of things, you can get in quickly and make a letter without ever studying all the intracacies. True industrial applications should offer this same level of ease of use. True .NET software developers strive towards two-click resolution.
Lastly, what about upgrade and maintenance issues? How much disruption is the release of a new revision going to cause when I need to install it throughout my system? Do I go to one point, and I'm done, or do I have to find all users, and upgrade their clients also? Vendors who are short on architecture usually try to lead the argument with features, or point to their strong services surrounding their software.
Review these issues when you are studying software purchases. You'll find that for many, software is a side-line to their main business- normally services. Such companies cannot usually be expected to keep up to date on the latest software development issues. As I have already mentioned in a previous post, that is not important to them if they are also going to be the users of the software. They know the command-line syntax to get around all of their software quirks.
We perform to these standards, but then, we live in the middle of the Austin software think-tank. The'd laugh us out of the neighborhood if we didn't perfrom to standards.
In sharing this with you, I am revealing the biggest fear of any software company. Someday, somebody will write the operating system that is so easy that 16 year olds will build what we've invested so much in within a three-day period. The tools will just be that easy. It hasn't happened yet, but the new software out there truly does offer levels of development speed and inter-operability that were previously unseen. For those few of us who have invested in this infrastructure, our clients will reap the benefits for many years to come.
For those of you who wish to understand this a little better, study the way vendors advertise their software in other industries (CRM, for instance) Go to their websites, and review their software descriptions. They don't even mention features. They just talk architecture. Sometimes, its difficult to even figure out just WHAT their software does (feature-wise). That's because their market is matured to the point that several generations of software maintenance have shown where the true costs of software reveal themselves. So, be aware, and ask the right questions, and watch for uneasy squirming. Educate yourself to, and examine what is termed "Total Cost of Ownership" (TCO) issues. Your company will be glad you did.
]]>1. We focus 100% on software development and deployment.
2. We focus 100% on alarm management.
Why is this valuable to you?
Using your own software to do project work is somewhat like drinking your own bathwater. You probably can do it occasionally to let you know how bad it is, but you don't want to make a habit of it for fear that you begin to think its not all that bad.
Software by its nature is like a child to those who develop it. When the first person makes the first remark about the lack of inherent beauty, you are ready to take them to battle. However, it is only those who are willing to listen to the voices of others who ultimately win the war and actually make battle-hardened software. If I'm willing or employed to use it myself, I simply elbow the naysayer aside, and go to work.
Let's examine the difference. If I always use my own software, then I don't really care about its inherent lack of usability. In fact, those of us who have ever used command-line programs know that they are the best. Once you learn to speak the language - you can bypass a whole level of manipulations and go directly to the point of solution you desire. This is great for those of us who want to immerse ourselves in one program, and live with it day-in and day-out. But what about those who have more things to do than just run one program all day long? That portion of society needs software that is designed with ease of use in mind. And for that, there is nothing more telling than having to sit NEXT to somebody else who is using your software, and finding where they get trapped. There's a goal in the software purist side of the industry for "two-click resolution". That means you strive for no more than two clicks to the next drill-down the user needs in any given situation. We're not fully there (nobody is) but it is our goal.
As a software company, think about the trouble we would get into if we just made our software hard enough that they had to hire us to use it. Or scared them into the "don't try this at home" model.
At TiPS, we instead try to make a practice of working elbow-to-elbow with our users. In fact, for many years, that was probably our biggest weakness. Rather than convincing the managers to buy our stuff (i.e. in volumes and based on a good PowerPoint presentation), we were convincing the users to buy it. And they did. In fact, we have more alarm management customers than any two of our closest competitors. And that says something. Our software is the clear choice of the end user. That is because of this closeness we've shared with them and our ongoing attempts to be certain that somebody else besides us could use our software.
It is TiPS' continued goal to make our software more automated, easier to use, and more adaptable with every line of code we write. Its not good enough to just perform a function, and add that to the laundry list. It's only good if the end user can easily access that function, and it fits with every thing else he has to use the product to do (i.e. he doesn't have to load up another application to do it. Does this sound like anybody you know??).
Don’t get me wrong. We use our own software, we just don’t solicit project work with it. But we do run through terabytes of data, and set up demos for people on our servers with their data, so they can see how easy it works. And we do come up with new and easier ways to analyze data by the continuous analysis we perform on data sets.
That leads to the second point. Because we focus 100% on alarm management, its what we do best. It means the conversations in our halls always revolve around how we can do something better for our clients. And we don't worry about how well that fits with our latest driver sales or advanced controller, or whatever. It simply has to be able to resolve your alarm management issues, and do that task better than anybody else.
Two recent major corporate contracts signed with companies who did extensive product analysis (both were approximately 6 months in duration) tell us that we're doing something right. We intend to continue to do those things right, and continue to do them better than anybody else.
If anybody asks you if TiPS will come out and perform a job with their software, just tell them, "No. They automated the task for me, and I was able to do it myself. And I used less effort than if they came on site, and I had to teach them all the ins and outs of my plant." If you do need extra manpower to perform a full rationalization, there are others who provide that service, and do it quite well.
Oh - one last point. We will NOT take your data and share it with the world. Though we've reviewed more alarm data than any other company, I don’t know ten customers who want us showing ANYBODY how bad their alarm system used to be.
]]>C.A.M.P. or Certified Alarm Management Professional almost made me fall off my chair laughing when I first saw it. So, just to be certain, I pulled out my Webster’s and looked up the definition. "camp- something that is considered amusing not because of its originality, but because of its lack of originality." Yep- that fits the bill.
I noticed first that some company offers a two-day training course. For $1200, you're allowed to go sit in front of them and get a two-day sales presentation. For that you receive a certification as an AMSS. (Alarm Management Sucker Supreme?) I laughed, and asked an attendee (yes- one of my clients wasted his money). He said he knew more than the teacher did just from the papers I'd sent him to read. Paid his money, got his certification.
Then I noticed that another company - not to be outdone - had upped the ante by making their focus around the 150-page book/brochure they recently wrote (Note: buy it at your risk, or just wait for another upcoming seminar where they will give it away so they can advertise the number of people who have read it). Additionally, with their training, you get continuing education credits from an organization willing to dole those out for people who are never even tested for what they have learned. And you get to be CAMP. Totally un-original. That is so "last week"- as my daughter would say.
OK- I'll repeat my mantra. Alarm Management is NOT rocket science. I KNOW THIS- I used to work as a rocket scientist designing and testing equipment for the space shuttle. It's simply good logical engineering, and a lot of bookkeeping. It is not a PROJECT, it is a PROCESS, and adjustments to your operations processes. Anybody who can make an alarm can remove an alarm. The goal is not to reduce alarms, but to balance to the proper amount of alarms. Too few alarms is WORSE than too many alarms.
So, if you need to hang a plaque on your wall, TiPS has decided that we will start issuing certifications. We're not going to preach to you about how good our products are for two days. Simply send us the money. We'll send you a L.A.M.E. certificate. That stands for "Local Alarm Management Expert". And when anybody asks who is the local expert on that subject, you can show them your certificate hanging on the wall. And if OSHA or EPA comes by, you can show it to them and it will have just as much value to them as the other guys' does. And if your company has a benzene spill because some company rationalized away the alarm that would have prevented it, then you'll at least have a L.A.M.E. excuse...
All kidding aside, stay tuned to TiPS website www.tipsweb.com where we will soon be announcing an alarm management training program to be taught by true alarm management professionals- ones who have been focusing in it, and contributing to both companies and specifications like EEMUA, ASM, and ISA for decades. We have decided that rather than hiring somebody and hanging a sign on him that says he's the expert in alarm management, we would go to the industry, and find those persons who truly are, and offer their training up as an independent offering. We have already done this for several of our clients, and it has been an overwhelming success. That means you won't hear a pitch on anybody's software- just the facts, and the technical information you need to get you moved past your current level of enlightenment.
It also means our goal is not to scare you into how complex it might be so that you'll have to hire us to do it. We believe that we can simplify it to the point you'll see you can do it yourself, or hire assistance under your direction. Let's get your alarm management system properly balanced without making a mountain out of a molehill. And let's do it without a bunch of lame certifications. If you want real certification, review the ISA's programs that require training and testing before offering certification.
]]>A lot of papers continue to be printed on this issue of rationalization- each professing to have the answer. I guess it’s a good thing everybody did not jump on the advice of the first one. Some of this confusion seems to be deliberate obfuscation by vendors who hope to distill a sense of fear in you. Conversely, some of the confusion seems to be with the very definition of the term itself, and the prevailing assumptions made by those who hear the definition. I will try to add some light.
There are two forms of alarm rationalization. The first is the design approach, the other is the data-based approach. It seems in the process world these two worlds are continually at loggerheads. The design guy is stuck on how many theoretical trays are necessary to make a distillation tower simulation converge properly. The data guy is worried about how many real distillation trays are collapsed in his tower, and what he must now do to get the desired separation based on the current data. Each is important to the eventual result, but neither seems to understand the issues of the other- or respect them for that matter.
Let's examine the design approach first. This approach says that if an alarm system is properly designed, then it should run properly. That means that you assign only alarms that MATTER- or have a defined operator action. You design those alarms to be observant of the timing, safety, environmental consideration, and potential costs associated with each alarm. You balance these issues within the alarm configuration as a whole to assign the proper priorities to the alarms you have assigned. Incidentally- EMMUA says that you should thus end up with 80% low priority, 15% medium, and 5% high priority if you do this right.
And to do this you really don't need to know how many alarms per hour your operators are dealing with. The only dataset you need is the current alarm configuration. Some have told me that this is all that is required to rationalize the alarm system. If properly done, you will meet all of the requirements of the EEMUA 191 guidelines, and will avoid floods as best as possible without adding a layer of dynamic alarm management. After instituting this process, then if they get too many alarms, then they are operating the unit wrongly (assuming your design information is correct). This can then be adjusted for poorly-communicated design issues, and you are finished. Add the data to a configuration knowledgebase, make it available for the operator to view when trouble comes, and you are finished. This process should be supported in workflow and tools by any good alarm management tool kit.
The other approach is the activation data-based approach. Bring all alarm activation information into a database. Review this data statistically to examine what are the issues that are affecting the operator. Resolve these issues by getting rid of nuisance alarms, and rectifying the configuration to reduce those most prevalent alarms. Find out why those alarms that are occurring exist. Find paths toward replacing alarms with other methods that create the same operator "Situation Awareness" (see www.mycontrolroom.com). This can be operator graphics, communications, redirection, or a myriad of other methods. Some tell me that once the bothersome level is reduced, their job is done. In this manner they "crawl" their way into a rationalized system over time. Statistically, I guess its possible if you keep at it without ceasing.
At TiPS, we advocate a balanced mix of these two methods. The best projects include a mixture of both. They also include operator training, an alarm philosophy, a management of change procedure, and an ongoing audit and maintenance of the results.
I recommend you examine both of these methods, and use the parts of each that are able to be accomplished knowing your current management disposition, personnel availability, and other issues that come to bear. There's more to it than I've discussed here, but I think you get the general gist. The hardest to justify is the design approach, because it usually entails a large project. A "nibbling" approach can get rid of a lot of noise. However, you should recognize that if you only look after the bad actors, it is the bad actors that have not occurred that may jump up and bite you when you least expect it. The design approach allows you to anticipate the bad actors in advance of their potential damage. It's the ones we don't anticipate that always get us.
We will have a white paper coming out soon that discusses this in more detail, and with an eye to the risk associated with each method. We refer to this mixed method as a balanced approach. We don't intend to patent it, or claim intellectual property to it. It's just good logical common sense, and an approach that many of our clients use successfully. After all, good alarm management is just good common engineering sense. There's no patent on that- you either have it or you don't.
]]>First- I'd like to state that we always welcome people to Georgetown, Texas with the byline "The Alarm Management Capitol of the World". Any of you who are in the region are welcome to stop in, and we can show you the spot out on Lake Georgetown where Ted Stoltenberg managed his first alarm. It's a small lake- good for skiing and fishing and such, but without properly managed alarms- well it wouldn't be pretty.
Alarm management practices were first undertaken when it was recognized that alarm logging printers were unreliable. So, it was a call of necessity and perhaps the expedience of a vacant need that cause Ted to build the first alarm management package. In those early days (around 1992- see the links in our website http://www.tipsweb.com/about/history/) the first versions were written to run on the VAX platforms that were so prevalent on control systems in those days. Their design was to take the data that was pushed to the printer port (the alarms and events) and store them first into a file. This file was then available for use in process forensics, and on-line to see what was happening when the alarm log was scrolling off the screen. As the technology advanced, a full database was added. This allowed for proper field assignments of the data, and thus searching and sorting and database manipulation techniques.
With customer requests, we soon upgraded the technology to include statistical analysis of field content so that frequencies of alarms could be tracked. When the EEMUA document was released, these analysis were upgraded to include all the important measurements recommended by EEMUA, and an industry- unique engine to use EEMUA guidelines to calculate alarm priorities given safety, environmental, cost and maintenance factors.
Prior to today, that package has been entirely re-written to reside on the most advanced MS ASP.NET platform. That means it is the only product with a full thin-client interface for ALL functionality. I'll write more on that point at a later date, but what that means to you is that you don't have to install client software on every machine you want to use it on- just open up a browser window, and point it at the proper (protected) address to use the application. With proper security allowances, you can do this poolside.
What are some of the other turns that alarm management has take along the path? Having been at both Pavilion and Gensym when this market was developing, and having sat on the ASM consortium for a few years, I can tell you a little about the interest level that drove its rise to fame.
The Abnormal Situation Management /ASM (now copyrightred by Honeywell ) consortium was formed as a joint venture between the National Institue of Standards Technology or NIST (that means your taxpayer money) and industry. Industry meant several concerned parties from the manufacturing arena. NIST funded the lion's share. Honeywell moved in quickly to become the vendor sponsor to ascertain that the discovered technology would come to market. I don't think it was expected that it would come to market quite in such a protected manner, but that's another issue. One of the first goals of the ASM consortium was to identify how to tackle the alarm management problem. Recent (at that time) activity at a refinery in England caused them to have a great concern, and they were involved in funding an effort to write a specification which eventually became the EEMUA 191 spec. (See more on this spec and others through the link at http://www.tipsweb.com/about/resources/) The ASM and its members co-sponsored this publication, and contributed much information to its development. This specification has become the defacto guideline for alarm management. The ASM also has published several documents and guidelines on alarms and alarm management. Some of these documents are available on their website www.asmconsortium.com and again, I remind you that ASM is a copyright of Honeywell. Today, some of the same effort is going on to write a modern version of these specifications within the ISA. It is called the ISA SP-18.
As the ASM consortium began to wind down, several of the members have leaked out into the conuslting community. We work closely with two of those. Dr. Doug Rothenberg, ex- of BP, and their representative to the consortium prior to having swallowed Amoco, now runs a consulting firm out of Ohio called D-ROth Inc. www.d-roth.com He is also the leading trainer of ISA members in alarm management, holding both classroom, and web-based training seminars around the US. We connect Dr. Rothenberg with our clients when they need grounding in the basics of alarm management or need to understand best practices associated with alarm management. He assists with creation of philosophies, and also establishing the processes necessary to perform and retain the benefits of a good rationalization process.
The second we work with is Dr. Ian Nimmo. Ian coined the phrase "Situation Awareness" to refer to the environment that you try to create in which you want to inform the operator whether he should get up and do something or continue stasis. See more at www.mycontrolroom.com. Ian has made a great study of all of the factors that effect alarm management, and his company- User Centered Design Services or UCDS- consults with companies who want to learn from a man who has spent more qualitative time in control rooms than any other person on the planet. He used that time to quantify the many factors that effect operations efficiencies, and how they interplay- witnessing the emergence of the alarm system as the ultimate garbage can for those things we've decided we either cannot or do not want to resolve.
These two companies carry some of the basic answers to true alarm management. Their personnel are not hirable by large companies, except as consultants- they simply desire to be independent. We work with them because we cannot hire persons who have their experience, and we respect their independence. Check them out- they truly can help you to understand the true gist of the problem that is often identified as a poorly performing alarm system.
So, where is alarm management heading? Contrary to the belief of others it is only begining to be used to its fullest potential, and will have a long and very valuable contribution to digital control and information systems. The alarm problem is only getting worse, as alarms can now be created at the instrument level, controller level, DCS level, and HMI level. Fieldbus adoption only exacerbates this issue, not simplifies. We'd like to think that dynamic alarm management will soon answer a lot of the problems that normal alarm management now undertakes, but you first have to have a clean NORMAL alarm system to extract maximum value from dynamic alarm management, and few people have that. There is a leading edge out there (and I DO NOT mean bleeding edge) who are taking advantage of dynamic alarm management, and seeing great results. But these are people who have undertaken a commitment we don't see among the majority of companies in alarm management awareness. If more understood the benefit, perhaps more would start down the path.
Watch TiPS website in the future for some announcements of tools that will change the way companies use alarm management tools, and interact with higher-level decision making engines. It is truly our goal to make the normal path easy to take, and as automated as possible. We believe thefirst level of this problem should be able to be resolved by operations personnel- those who it effects the most. They should be able to do it with tools that are automated enough to require a minimum of input from engineering. After all- that's the job of a good engineer- to figure out how to do things, and automate it so that the engineer doesn't have to be involved. In that way, those most effected by the outcome can control the process.
It looks like some others would like to convince you that this problem is difficult enough (and to make their tools complex enough) that you will always have to have them involved. Wrong answer. The tools should simply contain the ability to escalate any problem when it truly does become something that somebody working on shift doesn't have time or simple tools to resolve.
We've been with you in the past, and we'll be with you in the future. Stick with us- we'll get you there.
SMApple 5-15-06
]]>How can one know if this is their practice? Generally, its a simple process. Look at their software versus services mix. Most professional software companies, do not mix more than 10 to 20% of their income from services. Any more than that, and it is not a software company. It is a service company which offeres a software package to drive their services into other areas. You can generally expect that whatever the software component price of their offering is, you will spend the appropriate and commensurate amount on services- almost always matching or exceeding their corporate percentage breakdown (it varies if they have multiple packages). If you think you willl get by without that expense, be aware that they are professionals at extracting that service dollar from you once you have their software, especially if you don't have the time to use it to its fullest extent. And you generally don't.
The second thing you must examine is company motive. Is there a desire to increase the ease of use, and general client-oriented value of their package? The truth is that the harder the software is, the more time on site, thus the more services income. Service companies alften have internal arguments with their developers about whether they should include certain ease-of-use features. Often, this is guarded under the guise that it may reveal certain intellectual properties that are the company jewels. Additionally, few clients will chance the path themselves, having been warned off by the last brave soul who believed the sales guy who sold them the package.
What does this all mean to you? Buyer beware. If you are offered an unbelieveable price on software, you should know that the service bill will soon be coming. Opt instead for the company who strives to make its software easy to use, so that you can select the people that you want to hire to perform services operations, should you decide it is outside the realm of your time commitments.
SMApple 5-9-06
]]>Let's suppose you've done a lot of work to get alarms to a point where your control room is quieter. It is. But you still have the upsets- alarm floods and all. You had promised management that the $5MM they spent on alarm management and all the rationalization, etc. was going to solve this problem.
What is the solution? Why- we need smart alarms- or dynamic alarming. The same vendor that promised solved alarm problems has a new solution to offer. We'll make a plant state estimator, and change alarm settings on the fly to reduce alarms as the plant enters different states. Or better yet- we'll be able to avoid alarms entirely, as it predicts what is coming- kind of a better verision of the previously promised dream world where you had reduced the alarms to such a point that your OPERATORS were now able to predict what was going to happen (the so-called "predictive" alarm state- you can read the babble on other companies' web sites- we do not condone the concept).
I want to help you get your mind into a set where you understand two basic differences. One is the class of alarm management performed AFTER an alarm has been created. The other is the actual creation of an alarm message, and/or perhaps making a decision about alarms based on real-time data which is streaming into a database from a running process- better termed alarm handling than alarm management.
First- let's address the post-alarm creation issue. Within many instrumented systems- the DCS, the basic instrument, the HMI, or other digital information system, there resides an alarm processor. This alarm processor is designed to set a bit to true (or false) if a certain condition in the data associated with a specific tag does a certain thing. For instance, the data may exceed a value- either above or below. Or, it may make too large a change across too short a time. Or a handful of other things. This creates an alarm. The digital information system is set to then announce that alarm in a common format, so that it can then be recognized appropriately, handled by an operator, and logged for historical and troubleshooting purposes.
Alarm management systems are not designed to interfere with the creation of this alarm. They are instead designed to deal with the information once the alarm has been created. They database it, putting its information into fields in a database for later sorting, searching, or analysis using statistical tools. (they also do other things, but that was the primary use) With time, these tools have grown more powerful- they now database the information in real time, and make the information immediately available for action by an operator. They also track the alarm configuration database, and associate engineering informaiton to each configured alarm or tag. TiPS does this. (http://www.tipsweb.com/products/logmate/). For this reason, some companies have actually used our system as the real-time annunciator and display for alarms to their operators. This is not the design of our system, but is one use we have seen.
With this "semi-real-time" alarm handling, there are some very basic dynamic alarming functions which can be undertaken to reduce alarms in times of potential flood, or just to reduce control room over-information. In LogMate, using the SIGNAL (http://www.tipsweb.com/products/logmate/signal.asp) package, it is a very simple process to review the alarm information that is coming in, and using logical tools, to write messages back to the DCS which can dynamically change the alarm configuration. This can be useful for many simple cases. The first is when you have a piece of equipment which trips, and causes a series of alarms. Suppression of the other alarms is a simple matter of setting a logical filter to trap them, and suppress them.
The second case may be state specific. By setting up a specific state table, it is a simple matter of defining the logic to trap plant state changes (tractable ones, at least), and using that information to alter the alarm setup. This can be extremely handy for times of start-up, shut-down, or various product states. Not complex, but can be if you want it to be. The nice part about this is the SIGNAL application also allows an easy port to tie in higher-level applications. We do not attempt to offer these types of applications, but perhap