Autodesk Plant 3d P Amp;id Tutorial
Ashely Wolfgram
So you are back for more in Part 4? After all we went through in Part 3, those still standing probably deserve a medal or something. That said, unlike Part 3 where we really covered a lot of detailed "nuts-and-bolts", this part will be a comparative piece of cake. Kind of like the last day of school where you know you still need to go and it might even be kind of fun, but you don't have to do any real work and the stuff you do take home will be memories not homework. That's the frame of mind you need to have for Part 4, ok? But before you take this as a cue to start shooting spitballs at your host, sit up straight because this part is vital to your understanding and development of clean, clear, odor-free P&IDs. Since this series is kind of long (hey, who snorted!?), let's get the requisite recap out of the way for those who missed the previous parts and need to circle back:
Up till now, we have spent a great deal of our time focusing on the first lead sheet, D001 - Instrumentation and Valves, provided along with other drawings in the supporting file download to this series. In this Part 4, we will turn our attention to the remaining lead sheet, D002 - Codes, Tags, and Labels. As I have mentioned previously, D002 is an example lead sheet typical of the ones I have
used in the past. It may look different from the ones your company uses and that's OK. It's not as important how a company prefers to do labeling on a P&ID, only that they do it clearly, consistently and based on a robust system that is amenable to future change and additions. An extensible tagging system if you will. That's a concept that may be a bit unfamiliar to some so I will discuss that as a sort of prerequisite. Hang in there, I see the finish line...just around the corner!
While P&IDs are representations of the process to the casual observer, their underlying structure more closely resembles a relational database. In fact, for those of you familiar with today's common computer aided drafting packages, you may realize that a CAD drawing is really a database of objects assembled in a structured manner. Even if you reuse the same object over and over in a drawing, the CAD system keeps track of it with a unique identifier. This is very similar to a process plant in that, well for starters, we apply tags to keep track of equipment, piping, valves, devices, etc.--things that we reuse over and over again in any given process design. So I am here to tell you folks, when you design a process and develop the P&IDs in CAD, you are really assembling a database along the way. This isn't lunacy with half a bowtie. I'm serious and I would urge you to get familiar with relational database design, if only from an academic standpoint. Like object-oriented programming, these abstract concepts are extremely valuable towards implementation in our line of work. Some examples? Ok, behold my exhibits--like a database, a process plant illustrated using CAD on a set of P&IDs:
There's more than just the above but I will rest my case. I hope you agree that while the tags and labels themselves are self-evident, the real power is in the underlying tagging system used. And so you're still thinking, "why must a tagging system be so robust and extensible? I mean, come on Bob, aren't you making a mountain out of mole hill?" Well, glad you asked; the answer is quite simply because most plants change over their useful life. Change comes from a lot of different angles:
The key take-away from the list above is that the P&IDs serve initially as the process definition upon which the plant is designed. But then they serve operations long after the plant is built. This is why earlier in this series I espoused the need for engineers to be routinely, actively engaged in ongoing operations. Not only will you learn a lot about the plant that you yourself may have helped build, the feedback you receive will be invaluable to maintaining a safe operation. Plus, you can implement the lessons learned on future projects. Now that I've driven home the importance of a structured tagging system, let's turn attention to the meat of this Part 4--the actual tagging of equipment and devices.
Lots of companies use what appears initially to be an intuitive, simple system to tag equipment. It later reveals itself not to be very intuitive or robust. Let's pause for fictitious example (that bears no resemblance to my past, really). GitRDun Process, Inc. has decided to build a new plant to produce Trimethylkabif, a precursor to a drug that yields quick weight loss, improved memory and muscle tone while eliminating irritable bowl, gastric reflux and attention deficit. The process folks start out tagging equipment as follows:
And so on...Life is good. Later on, though less common equipment starts getting added, and this starts to stress the "intuitive" nature of the system. For example, a centrifuge is initially tagged C-1 but now they need to add a conveyor but C is taken so they decide to call the conveyor CO-1. Now they think, well, we will just revise the centrifuge tag to CE-1. Crisis avoided...But wait, later they need to add a chemical feed package and want to tag that CF-1. OK, that's cool but then a bunch of cross flow filter modules is added they decide to "steal" the CF label for those and change the chemical feed to CE, no wait...can't do that, CE is taken by the centrifuge. So they bite the proverbial bullet and call the chemical feed skid CS-1 where S is "intuitive" for supply. Right? Try again quiz kid. Nobody is going to see that as intuitive. And then one day, it hits GitRDun's process engineers that their initially conceived so-called intuitive tagging system is a heap of broken confusion and nobody knows their CE's from their CO's. Cue the Jackson 5 song A B C, simple as 1 2 3!
To avert the problems inherent in the above example, many process industries utilize a numeric-only system for tagging equipment. This helps simplify the logical categorization of equipment during the process design phase. Moreover, a structured tag system is more intuitive for the development of design documentation, operating procedures and training, and general documentation upkeep/maintenance. With that in mind (and considering the points presented earlier in this Part), the following method is but one example of how to tag process equipment using an extensible system.
Area Number, AN Most sizable process plants are comprised of multiple areas. An area is a physical, geographical, or logical grouping determined by the site. It may contain process cells, units, equipment modules, and control modules (more details can be found at isa.org). To facilitate a hierarchical organization of equipment, equipment tags should then incorporate area designation.
A small or simple project may have only one area. Conversely, larger more complex projects may have multiple areas. The assignment of areas is at the discretion of the process engineer and can be subjective. The only general rule that I like to employ is that common equipment that serves multiple areas, e.g., utility and infrastructure system be placed into a "Common Resources" area rather than be made a part of any other process area. Once areas have been designated for a particular project type, engineers should strive to maintain common area designations on future, similar projects. For example, the areas shown in the figure above may be defined on the lead sheet for a fictitious project.
Equipment can be identified based on its type using a numeric system such as the simple one shown below. In cases where equipment has multiple functions, user discretion is advised in selecting the most suitable type code.
This is the consecutive numbering of like equipment in a particular area. The sequence begins with 01. All equipment is to a have its own sequence number. The use of alphabetic or other tag suffixes is to be avoided.
Using the system outlined above, a four-digit system emerges that may not be instantly recognizable in terms of what the specific equipment is (or where), but it will eventually become very familiar to those who are intimate with the plant. A few examples using the area numbers defined above are provided below:
It is up to your company to decide on the final formatting, location (some companies like to put certain equipment labels near the top of the border), and which particular specifications should be included along with each major equipment label. The system presented here is fairly simple and broadly applicable. Irrespective of these details, I highly recommend that every piece of major equipment receive a label with a similar level of detail.
A benefit of using four digit equipment numbering system such as the one presented above is that the tags lend themselves toward application in defining associated instrument loops. This makes grouping equipment and associated instrumentation devices more logical. Think back to our friends at GitRDun Process, Inc. Their tagging system consisted of tags like P-1, AG-1, CE-2, etc. These tags are not amenable for use in defining instrument loops. However, a four digit system does neatly tuck into instrument bubbles and when you think about it, most instruments and devices serve or are primarily associated with a piece of equipment. And even when that is not the case, they can readily borrow from the equipment type code "9" in cases where, for instance, a pressure gauge on an air header serving the entire area must be defined. Considering the above points, the following instrument and device tagging system is but one effective way to tag instruments and devices:
A suffix is provided to accommodate instances were many devices of the same type are associated with a given piece of equipment. For example, a vessel may have many lines connected to it, each having its own actuated valve. To resolve these instances so that each device has its own unique loop number, there are two suffix tag methods that can be employed,
c80f0f1006