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 2 of 3 1 | 2 | 3 View on one page


The full-time team would need a process engineer, a control engineer, a supervisor with good experience of the plant and a couple of knowledgeable operators. Dealing with the first 10 alarms, the team would discover they required up-to-date documentation, including accurate piping and instrumentation diagrams (P&IDs), DCS data sheets, PLC ladder-logic diagrams, procedures, etc. In addition, the team often would need to call upon other resources either to validate the documentation or find missing information, which introduced costs, delays and resource planning issues.

The team also would discover that initially they could only get through a handful of alarms per day. After that, they realistically would be able to handle between 15 and 30 alarms daily, given the documentation checks, new documentation generation and management of change (MOC). One team found it could only do five alarms per day because of other commitments and that it would take more than three years just to get through the current alarm database.

Such a long-term, resource-dependent project with an initial capital expenditure requires formal project management. It is critical to success and should start with a program that addresses these questions: 

  • Who owns the problem?
  • What is the purpose of the project?
  • What results should it achieve?
  • What resources are needed?
  • What is the site’s readiness to change existing practices?
  • What other project-management issues related to time, cost, resources and other priorities might arise?

As part of this, the team should explicitly develop:

  • A statement of the intent of the project
  • The project’s objectives and performance expectations
  • The work breakdown structure

A Benchmark
Companies recently have put a lot of effort into resolving alarm-management issues, and the best of the best are doing this by first measuring a site’s performance against a benchmark. This benchmark usually is derived from guidelines issued by the United Kingdom’s Engineering Equipment and Materials Users Association (EEMUA) and has been broken down by one company into five classifications of performance:

  1. Overloaded
  2. Reactive
  3. Stable
  4. Robust
  5. Predictive.

Doing a gap analysis at the outset of the project can put the site’s performance into perspective against the benchmark. It also provides the opportunity to set goals and milestones for improvement. the target depends upon how bad a problem the site has and how determined the company is to resolve it. This comes back to those initial project management questions: What’s the purpose of the project and what results are to be achieved? Some firms just want to deal with the initial problem, others strive for a best-practice solution, whereas others might have a mandate from a regulator that determines the goal.

Most companies won’t tolerate an overloaded system and don’t want — but often have — a reactive system that is not useful during disturbances. So, the initial phase of the project usually is to achieve a stable system, which is defined as one that is reliable during normal operations and that provides some advance warning of a disturbance. It still has problems during a big disturbance, though. Achieving this may simply involve resolving alarm configuration problems, removing duplications and continuously addressing the Top 10 bad actors that contribute most to alarm floods. This phase often is the first milestone for the project team.

Attaining robust performance typically is handled as a separate phase. It requires another level of design that frequently involves dynamic alarm-management strategies and additional software, and thus capital. After all this investment in time and resources, companies want to see a return. So achieving a robust design may be the goal.

Some firms make reaching predictive performance a stretch goal, but only best-in-class companies attain it. Judging by the quality and content of papers from BP, they have clearly demonstrated that predictive performance and the EEMUA-guidelines performance standard is achievable.

Realism
Estimating the cost of an alarm-management project can be difficult for an engineer who has never done it before. However, a wealth of knowledge and experience is available.

Some common omissions in estimates include:

  • The cost of hiring an SME to get the project on the right track and of educating the whole team on best and adequate practices. It is very expensive to start an alarm-management project, fail and start over again.
  • The cost of software tools that are necessary to analyze an alarm database and identify problems, document solutions and implement change.
  • The internal cost of team members to participate in workshops, alarm objective analysis, DCS reconfiguration, modifications to PLC databases, changes to safety instrumented systems, fixing instrumentation and plant equipment, updates to training manuals, procedures and MOC systems, enhancements to the HCI, and process changes.

In addition, if the goal is to achieve predictive performance, the company may have to invest in state-estimation-prediction technology and new application software to do dynamic alarm handling.

Success depends upon getting the right people on the project; unfortunately, experts are always in high demand, especially in progressive process plants. therefore, using people effectively should be part of the project plan. Some members of the project team may always take part, but others may be called upon for advice only as needed.

Learn From Failure
One alarm-management project failed due to lack of knowledge and the team’s inability to read PLC ladder logic. A large number of alarms originated from the PLC and then went to a DCS for presentation to operators. the team was not able to determine the source of the alarms or understand their objectives. No one had identified the need for a PLC specialist on the team. This limited the ability to address the real issues, extended the time to achieve anything, and caused so much frustration that the team lost momentum and gave up.

Page 2 of 3 1 | 2 | 3 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