For those of you who haven't seen it yet, TiPS has an add-on feature to our LogMate product called TRAC. http://www.tipsweb.com/products/logmate/forensics_trends.asp This product was something that came out of our relationships with pharmaceutical clients. Those clients have a great need to have alarm data and process data together in the same spot to assist with variance reviews. In a straightforward implementation of the best of Microsoft, we are able to extract the process data, and align it with alarm data for any given period. There's even a relative time capability so you can view it batch-by-batch.

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.