How to rescue your plant from alarm overload

Everyone who has a distributed control system has encountered alarm management issues. The reason is simple: A DCS makes over-alarming all too easy. Find out ways you can rescue your plant by taking responsibility and ownership of your alarm management system.

Share Print Related RSS
Page 3 of 3 1 | 2 | 3 Next » View on one page

Another team failed because of lack of correct information and knowledgeable personnel. A DCS manufacturer was employed to resolve alarm-management issues. Unfortunately, the P&IDs given to the vendor were out of date and equipment that was out of service was not flagged. the DCS database did not reflect plant changes and, as modifications to the plant occurred, tags were reused without changing the descriptors. the vendor used its budget rationalizing and resolving inconsistencies before realizing it had focused on resolving problems with out-of-service equipment. Any of the operators working in the plant would have picked up on these errors.

Most alarm-management projects have some degree of success because of the size and nature of the problems. However, few achieve the initial goal of resolving all of the alarm-management problems. This often is caused by poor estimation of the time required and by the complexity of the attendant effects of alarm management, such as the impact on procedures, training and the HCI.

Some of the classic examples of good alarm-management projects, such as the Woodside project in Karratha, Australia, have been implemented during the last five years, but there is still work to do. In alarm management, there is no such thing as a quick fix. Different companies address the problems from different angles. Some start fresh and add alarms based on objective analysis to a new empty database. Others work with the problem database — reducing it slowly over time, first by removing duplication and then unnecessary alarms. An experienced multidiscipline team usually can address about 30 alarms per day.

Too many companies do not understand that resolving alarm problems is an iterative process and involves data collection and analysis, fixing physical problems, identifying and eliminating unnecessary alarms, making enhancements to required alarms (such as filtering, suppressing or changing alarm type from deviation to physical or vice versa), creating and updating documentation, performing MOC reviews, implementing, testing and starting over.

Good alarm-management projects start by focusing on the end or life-cycle aspects, with a goal of transitioning to a new way to maintain good alarm-management practices.
Some of the reasons a project can fail are summarized in the sidebar. In addition, alarm-management projects commonly suffer from specific problems, including:

  • Lack of state-of-the-art knowledge and reluctance to pay for an SME up front
  • No understanding of the real problem
  • Lack of ownership
  • No formal project management
  • Unreadiness to change existing practices
  • Establishment of unrealistic goals
  • Inadequate budget due to poor estimate of costs and required resources
  • Lacking the right people at the right time
  • Inaccurate, out-of-date information
  • Unrealistic time expectations
  • Focus on project, not life-cycle, aspects; and
  • Inability to reward success and accept failure.

This list certainly is not comprehensive.

A Winning Approach
Successful projects have a clear alarm philosophy that is well documented and understood by all disciplines. they also have team members with a good understanding of the EEMUA guidelines, even if they don’t agree with all of them. the most successful projects have a realistic view of the size and types of problems to be encountered, a definite focus on return on investment, and a management mandate to solve the problem once and for all.

A successful project provides tangible benefits. the project manager can see a difference in the day-to-day operation of the plant. Equipment runs better, incidents are dramatically reduced and production targets are consistently achieved; the only alarm that sounds is one that requires an operator to take action.


Ian Nimmo is president and founder of User Centered Design Services, Anthem, Ariz., a firm that specializes in abnormal-situation management, alarm management and other control issues. E-mail him at inimmo@mycontrolroom.com.
Page 3 of 3 1 | 2 | 3 Next » View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments