Over the past few years, the initial reason for alarm management has been hijacked. Lately, its been all about rationalization, and fixing the poor design. Bad designs have creeped up on us so numerously, that all efforts these days seem to be centered around fixing these bad designs. Some find that they can simply find all the nuisance alarms and ferret them out, and they're to a stable point. Others find that they need to sit down with the configuration and rationalize the system completely.

What this all hides is the fact that alarm management systems- originally alarm logging printers- were first designed to help us figure out what's going wrong in our processes, and use that information to fix the things that are wrong WITH THE PROCESS. That is as opposed to fixing things that are wrong with the alarms system. Which would you prefer to do?

At TiPS, many of our best customers- even when they are rationalizing units with the automated features of the LogMate (saving thousands on manpower), are still using the softwre to figure out what happened when something goes wrong. That is because the software was designed with a rich set of operator-specific tools to help figure out what happened. In fact, we  commonly hear that the operations managers first question is "what does LogMate say?" when there is an incident.

The reason why we designed control systems with an alarm printer was so that we could tear that sheet off the printer, and bring it to the console where we could compare the alarm activity to real-time results. That allowed us to decipher what went wrong, and how. These old printers, when replace with a modern real-time database, can yield instantaneous results. That's one of the reasons why, unlike our competitors, TiPS has maintained a real-time databasing schema. This yileds the ability to instantly examine any alarm scenario, and decide what was the sequence of events. With proper information, operations can decide how best to avoid that situation in the future- sometimes through alarm settings, but often through process changes. Our recent news letter talks about the notion of using your alarm management system to resolve operations problems.

So- the deep dark secret of alarm management is that some companies have (properly) identified that most alarm systems in use today are seriously flawed. There's been an awful lot of talk about how to fix them, and how to rectify the problems these flawed systems can lead to. Yes, you need to use LogMate to fix your system- as a full featured lifecycle based software, it will do that for you.

However, let's put ourselves five years into the future. You've gotten rid of all the nuisance alarms. You've documented and rationalized all alarms in the system, so that you have a full understanding of what each alarm does. You spent over 5 Million Dollars doing it with some company that wrote a book. But, YOU STILL HAVE ALARM PROBLEMS. Management is pushing- when will the bleeding end?

Well, that's what alarms are. Every alarm is a problem. And keeping alarms from happening AT ALL is the only solution. Each alarm says that I (the control engineer) have not been able to automate the system in such a way that human intervention was not required. Otherwise, the system would handle every upset automatically. I am reminded of my old friend Warren Thompson who used to talk of the control room of the future. He said it would be a man and a dog. The man was there to feed the dog, and the dog was there to bite the man if he touched the control system.

Now, maybe that's a bit much, because some types of automation are simply too expensive either initially, or from a maintenance standpoint that a human is still the cheapest solution. We will not be fully automated until we have truly commoditized control to a no-brainer cost. So, we have to accept that we will live in a world with alarms. And we have to accept as well that we need to have operators trained to know what to do when things don't work the way they should. This means we need to give them every bit of information that is possible to resolve issues and in a manner that they can use it. One of these bits of information is the old alarm logging printer. Yes, it is dead, and now replaced by a SQL file on a computer, but its value to the system still survives.

So- let me make a suggestion. If you're going to hire a company to do a rationalization project for you, and they also happen to have a package that does it, then let them use it, but don't keep it installed. If it is really good at what it does, you should be able to use it, and then throw it out and never need it again, right? Then fall back to the good old LogMate that everybody knows and loves for your day-to-day operations.

Now- if you're smart enough to start with LogMate- you're already ahead of the game. Here's an example. Suppose you've been using LogMate for years to monitor your alarm system, and perform exactly what I've discussed- forensic analysis. Now you have a leg up on alarm management activities. LogMate has a database of alarms that you can use to analyze the system. Simply send that database off to TiPS- they'll put it up on their server,and let you analyze the situation with your alarm system. Most of the alarm management efforts fall on their face if they do not have a good long-term database. This is the reason for a lot of failures we have seen. A vendor arrives on site, and downloads you alarm journal. It reflects on ly the activity you have seen over the past few weeks. And they then try to fix your alarm system for how it will run next year. You need a decent database, with lots of modes of operation to be fully representative. LogMate provides that.

Intall LogMate first. You'll be ahead of the game, and your operators will thank you for the forensic visibility it gives them into the process. After you've cleaned up all the alarms it will again revert to that usage, as well as keeping automated tabs on your alarm system.