Alarm design for mineral process plant

[kallen88]

Hello,

I am currently helping develop a control system for a simple mineral process plant and need some assistance with alarming, in particular, when to deiced if an alarm is necessary or not. I am not 100% familiar with the process just yet but I have an idea of the critical aspects. I have a meeting with the process engineer next week to discuss but I want to show a bit on an initiative. I am analysing the PFD in order to determine where faults may occur, what the consequence of these faults are and what preventative measures can be taken to reduce or eliminate the faults. Then I will apply this to the control and alarm philosophy.

Are there any tools that are useful apart from a risk analysis or HAZOP to get an idea of what events can occur and what might cause said event. I have been using a cause and effect diagrams to determine in my own opinion but I understand this is more of a tool to use when troubleshooting. Plus there are so many possible faults to think of and this process could go on for a while. So are there any tools useful to 'fault find' in the design process and how do you deiced what events to focus on.

Thanks.

 

[Compositepro]

I'm a little disturbed by your question. The tools you mention and seek will help to organize and document your analysis of a process but cannot, in any way, substitute for a full understanding of basic scientific principles that determine how a process works. And it is not just theory that is important but experience with practical applications and attention to details like low points tend to fill with liquid and high points tend to collect gas.

 

[LittleInch]

As composite pro says - the key tool is understanding the process and what limits your equipment is designed for. You need to include automatic trips and shut offs for critical activities. As shutdown can cause significant financial impact, alarms are useful to alert the controller of processes which are getting close to, but not exceeding the trip functions (e.g. high or low level, pressure, tempearture etc) and do something about to prevent a trip or shutdown.

The problem with alarms often lies in the set points of those alarms which can be too close to either trip point allowing little time to do anything, or too low meaning alarms are constantly going off when not required. When anyhting actually goes wrong big time, the controllers can get overwhelmed with alarms and often cannot cope or see the big picture, hence sometimes alarms become ranked in importance so that controllers can concentrate on the level 1 alarms and ignore the lower level ones.

My motto: Learn something new every day

Also: There's usually a good reason why everyone does it that way

 

[kallen88]

Hello, thanks for the responses.

Compositepro - What exactly disturbs you about what I have written? I do get that a full understanding of the process is key to determine proper operational and design constraints for equipment and personnel. I have helped with the design of 3 previous pilot plants where the process is fairly simple, centering around a single piece of equipment and few process variables. So main reason I am asking this is the project I'm helping with now is of a full scale production plant and now there are many pieces of equipment and many process variables. The processes I am referring to are basically pushing ore slurry through cyclones, screens, spirals and crushing equipment and does not involve things like chemical processes, high pressures or temperatures so the relative risks associated are a little lower. I'm not saying this is an excuse not to understand the fundamentals of the process or ignore good engineering practices like risk assessment, but it makes it a bit simpler. So I wanted to see if there was a way I could organise and document the process more effectively to achieve that full understanding? As I said there is a meeting early next week to discuss the process which should lift my level of understanding.

Thank you littleinch. In the previous projects I have helped write the control philosophies outlining the priority levels of alarms and I have been using the EEMUA guidelines and ISA 18.2 on alarm management to do so.

I want to figure out where an alarm point may be necessary, seeing as my experience is a little low at the moment I am relying on a bit of a methodological theory approach. So for instance I can select a problem such as the cyclone starts roping and all the causes of this. I can analyse the causes and select the most likely to see if alarming can help the operator prevent this problem, if not the process may have need a bit of a redesign. Would this be a suitable approach or should I be doing something different?