Understanding Process Design

[jimpiper60777]

Hello To all!
I have been in piping design business for almost 7 years.
Considering my knowledge and experience in this field, I can do lay outing, detailed checking, and raise interesting issues in piping that some new may not have ever encountered.

I know I can read this process flow diagram and quite familiar with the system's function that a piping engineer must learn. And it does a lot of help for piping designer who will be able to know the service and processes of the line involved. I know the basic functions of valves, instruments and equipment.

However, for the past projects that I was inolved in, a big question came to my mind. How these valves, safety valves, instruments, control valve manifolds, thier locations, chains and order have been established? I mean, how to understand their relationships? Why needs automatic block valve near the nozzle of the pressure vessel, isolation block valves, drains, lines in and out of the system, and so much more that can be seen on the P&ID.


Is there a book or a guidelines or should i say "A code" that details or explains how to put those things altogether?


I believe that a piping engineer who will be able to support himself with a reasoning by fundamental principles in process design may be effective. HE may be able to predict lines need in a heat gas treatment, liquifaction system, fractionations and so much more. Perhaps, If you can predict (during FEED) or say calculate a systems' components that should be present why not?

I observed,there have been in fact a "trend" in working with the piping design. ie. designer cannot design without p&id???

Can anyone explain shed a light on this?

Your enlightenment is very much appreciated.

 

[Homayun]

Well, a lot of the issues you are talking about here have to do with the way a plant or a unit is run. How the process is being controlled, how the process is being safeguarded, how it is being started and shutdown and maintained..So all these facets lead to using certain type of equipment, block valves, control valves, Safety valves, Trip valves, bleeders, instruments, etc etc.

And I would say there is not a book that can be studied to learn all that. One can educate himself by working on a project as a process engineer.

I am sorry if I am not of any more help.

 

[ChEMatt]

The determination of the placement of valves, check valves, automatic valves, and the other bits and pieces that you see between units/vessels come from the following sources:

* Common sense and thinking through the process and what folks will have to do if they want to isolate a particular piece of equipment
* Standards - such as API, ASME
* Safety Reviews - such as HAZOP
* Process Control - what is it we're trying to do with this particular piece of equipment?
* Fluid Flow - what is flowing through the pipe, how fast? What pressure? What metallurgy is needed?

As a piping designer, your best contribution is from the last bit of information, combined with a bit of knowledge of where the flow is going. I deal with slurries often, so it is important to minimize horizontal runs to prevent plugging. A piping designer, armed with this bit of knowledge, will be better able to run the pipes between equipment and throught the pipe rack as the case may be. Other tricks of the trade such as the correct orientation of eccentric reducers before the suction of pumps or inlets of compressors are learned as you go along. But those things are quite important.

I posted a question about P&ID development a couple years ago and have learned quite a bit since then. It takes a combination of all the things I mentioned above. Everyone has a part to play in the development process, but some folks are more focused on one particular thing, such as piping layout, than others. A good process engineer needs to be aware of ALL of these things, in my opinion.

A piping designer does not NEED to know process design, but if s/he did it would help when they are coupled with an inexperienced engineer. It's always good to know as much about what you are working on as possible. However, it would be a waste of time and money, in my opinion in the role of a project manager, to have a piping designer studying HAZOPs or API specs or Process Control principals. You need to know where to put a pipe and why, and need to know how to use the software efficiently.

That being said, I ALWAYS welcome questions from others as to "why did you put that there". It makes me think and re-examine what I did. Furthermore, I may have made a mistake! It happened once.

Go out in the field if you can, ask questions, become friends with engineers who are experienced. If they are worth their salt they will help.

Hope that helps!

Onwards,

Matt

 

[jmiles]

Matt is very correct, ultimately what your asking comes froma combination of many different things. BUT the most important thing to remember in my opinion as a piping designer would be this, you can learn alot by observing how things go together, what ahs been done in the past, and essentially basing future designs off of that, however, the thing we must always be cautious of is that becomming a parrott is not always correct.

As an example i worked one pipeline job where I had determined the burial depth to prevent water freezing was 2.0m to be safe we made that 2.5m and specified that at road crossings we would go even deeper. this was solely to prevent the water in our pipeline from freezing.

Then we come across a pipeline crossing, rather a future pipeline crossing, where a 48" water line will be placed. the PM for the job insisted that we go at least 2.5m below this 48" line, because he had latched onto the idea of extra depth for crossings to prevent freezing. the truth of the matter was that 48" line would have added heat to our water line thus preventing freezing quite effectively. so an extra day of digging was done that was not necessary. its a minor difference, but it is the difference between knowing whats been done in the past and understanding why things ahve been done.

Ultimately its the why that matters, not so much the what.

(I hope my ramblings make some sense)

John