An Alarm for Each PID Controller in DCS

3 Mile Island Incident is definitely an eye opener.....!

But I still dont understand the mentality of some end users who insist on providing alarms on such controllers, and then blame the EPC/Control System Vendor for generating nuisance alarms .....

Refer these users to the approved P&IDs and the HazOp Study report.

Agree fully. If you want to get more out of it, I suggest you take a next step and do an Alarm Objective Analysis (AOA) workshop with all the right dudes (and gals) to rationalize all your alarms.

End user you mean the customer. So your going to argue this with them and loose.

He is the customer give him what he wants. Or he may find someone that will.

Determining the need/want is the subject of the HazOp Study.

OP should be contractually bound to follow customer's (collective) procedures. Said procedures should include hazop, operability studies, etc., conducted with proper representation and documentation. No individual, even an individual customer rep, should have the authority to bypass or negate those. Every project team member should be a gatekeeper.

Perhaps they are refering to deviation alarms (standard option in most DCS systems)

This is simply an alarm that will notify the operator if the process deviates more than 10% (assuming the alarm is set at 10%) from the setpoint.

Using this will normally also neccesitate alarm delays - to allow some time for the process to reach the new setpoint in case of adjustment.

Have you actually received this request from the end user, or is there a big engineering firm in the middle of the job data flow? We often get strange requests on jobs here and comply, only to find out well into the job that the end user did not request this, and indeed does not want this, but rather some green engineer at the engineering firm handling the job put this in the spec package. Then we get to argue over who pays for the unrequired items cost and the cost of the correct items added to the job.

There have been some excellent comments placed, and I would like to throw my two cents worth in.

First of all the requirement for alarms for a control or indication is defined during the HAZOP, HAZAN, SIL studies, etc. and the previous experiences from other projects.

These studies will indicate the need for a H, L, H/L, HH, etc.

The function of the H and L settings is generally as an alarm per se, while a HH or LL will generally be used for tripping a safety alarm and shutdown.

Now then what in my limited experience I have found is that in some instances the alarming functions are so overdone, that instead of alerting the operators to an upset condition, they just ignore them due to the fact that there are so many they cannot respond to all.

Based on this I generally suggest that the alarm or trip functions be limited to variables that could have immediate shutdown or hazard results, though it is the process departments decision which signals have what priorities.

When a control room operator gets inundated with dozens to hundreds of alarms its impossible to detect which one is first which one may have higher priorities or even if the alarm was a spurious one. In these cases the operator will generally cancel all the alarms and call either a supervisor or an engineer to have them detect the faults, problems, and potential solutions.

Finally the use of alarms needs to be optimized so instead of an operator silencing them he actual performs corrective actions.

Pre microprocessor's, DCS/PLC, alarms were allocated to windows in boxes at a cost of about $140 each. Care was taken in the selection of alarms. Post DCS/PLC we have introduced a situation that has been and will continue to be, a major contributor to industrial process "accidents". Alarm management is generally carried out at the end of a new project. By then the programmers just want to go home, so with the best will in the world the end user is left to carry out this very important activity.

I asked my colleagues a few months ago to give me a report on the amount of alarms received during a 24 hour period at our major coal fired power stations in Australia. You may find this difficult to believe but they averaged out at 79,000 per day!! Some of our major disasters down here, and throughout the world, can be attributed to "alarm swamping" .

There are a number of good books published on alarm management. Make a start by getting a copy of the ISA document 18-2. It has some very good guidelines.

Have never come across alarm settings on a P & ID. Could be a good idea. I insist that any alarm changes are reviewed by a qualified committee who meet weekly. 3 Mile Island was not an alarm issue but failure of the system to correctly indicate the position of the pressure relief valve, which I suppose could have created an out of position alarm.

I think back to when we moved away from the conventional control panels to the modern HMI graphics. We made so many mistakes. We took away pattern recognition, we used red and green for motor states when 3 out of 10 operators have red/green colour recognition problems, and now, I'm having to fight the IT department who consider themselves qualified to getting into the process control world. Isn't this new technology great?

On a lighter note we thought we could introduce voice recognition for plant control. Operator would read a paragraph so the system knew he/she was on shift. Then they could control with voice commands. Unfortunately some of them stutter.

<...never come across alarm settings on a P & ID...>

Likewise. The settings need to be stated on a separate Alarm Schedule document. Then, should an alarm need changing, the Alarm Schedule can be changed post HazOp study for the need for the change, which is easier to do than altering the P&ID.

A situation where programmers have to use their initiative rather than work in response to approved design documents is a 3-Mile-Island waiting to happen. However, it also exposes weakness in the testing regime, which is a major component of commissioning; it is not possible to correctly commission a plant where the design intent is inadequately stated beforehand - all one can do in these circumstances is turn it on and hope for the best!

Needless to say, a document control system needs to be in place at each facility to make sure all changes of intent and records of test are correctly documented.