Blog Post

What I Learned About Dynamic Alarm Management During my Summer Internship

Aug 01, 2015

Lexie Breaux

First, all of the documents that are part of the Customer’s standards were read in order to ensure that the alarms were in compliance with all of their safety regulations. These documents included the PHA (Process Hazard Analysis), Troubleshooting Guide, CPV (Critical Process Variables), Environmental limits, and the SRS (Safety Requirement Specification). The SRS document includes the shutdown system of the unit, Cause & Effect matrices, and IPLs (Independent Protection Layers). Other documents including P&IDs and startup/shut down procedures were used to tell more about the process and how it operates.

Second, I learned the difference between the DCS (Distributive Control System) and the alarm database. The DCS is the actual control system where all the alarm tags are stored. The database stores all of these points from the DCS. Sometimes these two systems have mismatched information and during the alarm rationalization, the discrepancies are fixed.

All of the tags in the unit are brought in to do a full Alarm Rationalization. The excel file we use to do this is very large! To rationalize the entire unit, you must tediously go through all of the tags and decide what should or should not be alarmed. It is also decided what the trip points of those alarms might be and what the CCA (causes, consequences and actions) should be for those that are alarmed. Doing all of the pre-work before meeting with the customer team helped with shortening the time spent at the actual meetings and helped with discussion. The customer engineers and operations team helped review to see whether the alarms we had rationalized were accurate for their process. The team’s insight also helped us know more about the process.

The next part of the alarm rationalization was the Logic and Dynamics. The Logic breaks systems into cases of operation. For example, one system may have a Run, Circulate and Shutdown case. Each of these cases is a state of operation. The dynamics takes this logic and decides which alarms will be needed in different states of operation. An example would be disabling a low temperature alarm during a heater shutdown case because it is not needed.

The last part of completing the full alarm rationalization was the Ops Limit (Operations Limits) part of the project. Ops Limits define the limits that the process is within and guarantees that the alarms will be between those limits. Different limits are also owned by different groups of owners. For example, an environmental consequence would be owned by the environmental department and a pump damage consequence would be owned by the rotating equipment department. This will help in making re-rationalizations and alarming easier in the future.

In summary, the 5 main points in completing the Unit Alarm Rationalization were:

  1. Documents
  2. DCS Versus Database
  3. Alarm Rationalization and Meetings at Customers
  4. Dynamics and Logic
  5. Ops Limits

Overall, I have learned that there is a more practical side to engineering than school teaches us. It was also really cool seeing a rationalization from start to finish and what I learned will definitely help me in my final year at LSU! Interested in interning at ProSys?

Apply here