Hector Torres’ question
What is the best way to convey information to design, build, run, and maintain a process control system in a common format that can easily be created, modified, and understood by all disciplines involved?
Answers from Hunter Vegas
Wow….if I had the answer to that I would likely be a rich man. I will say that I have gradually created a reasonably workable system over my 30 years of doing automation systems. I’ve held positions in production, engineering, and consulting so I’ve seen some pretty good (and stunningly bad) examples of what works and what does not. The key point to understand is that the documentation needs of each group – from design, through construction, and on into production/maintenance all vary considerably so there is no one method that will make everyone happy. However it IS possible to create a documentation format that works for design and construction and then can be gradually “morphed” into a format that meets the needs of production. The specific formats will vary somewhat with industry but I’ll address as broad a group as I can.
This is probably the most useful document an instrument engineer can have and it is always my starting point for any major automation project. Basically it is a list of every single instrument in the plant and is usually used as a means of giving out new instrument tag numbers to avoid duplication. The taglist as a minimum should contain every instrument in the control system but many include EVERY instrument with a tag including local thermometers, pressure gauges, relief valves, etc. It is critical that each instrument be given a tag number that can be referenced in all of the other documents.
NOTE: The assigning of tag numbers is a whole other topic of conversation that I won’t delve into now. However it IS vitally important that the numbers be assigned in a simple and meaningful way. Many plants have been seriously burned by tag numbers that have been doled out in an unwise or haphazard fashion.
Practically every other piece of documentation will key to the tag list in some manner so it needs to be done right. Some people use Access databases but I find a standard Excel spreadsheet to be much easier to use and simpler to manipulate. The basic taglist will have the following columns as a minimum:
1. ISA Prefix (LT, LV, FV, etc.) Use the standard ISA methodology
2. ISA Tag number 100, 101, 1000, etc.
3. ISA Tag Suffix (A, -11B, etc)
(Note that if I split the prefix, tag, and suffix into separate columns, this gives me a lot better means of sorting. If I have multiple plants with duplicate tag numbers, then I’ll often add an “AREA” or “PLANT” number or letter column in front. In that way, if one plant is Area 10 and the other is Area 07 then I can tell the difference between LT-10A in area 10 from LT-10A in Area 07.)
4. Description – This is usually a LOOP description, not a device description. We’ll usually use this as the description on the loop sheet as well as the description of the control module in the control system.
5. Device Description (Magmeter, Control Valve, Open Limit Switch) – This column isn’t necessary but helps the user quickly figure out what a device is.
6. DCS Location – This is usually a couple of columns that include: CONTROLLER, RACK, SLOT, CHANNEL, etc. The specific columns will vary depending upon the architecture of the system. NODE will usually be necessary if the device is a bus type device (ASi, Fieldbus, Devicenet, etc.)
7. Range Lo, Range Hi, Range Units – Some people combine these into one column, like 0-100 PSI, but over the years I have found it better to have individual columns for each number.
8. Loop Sheet Drawing Number
Beyond that list, there can literally be hundreds of more columns and this is where the “morphing” comes in. On a large project (especially a retrofit project), I will build up a large chunk of the configuration data in a large spreadsheet and the engineers can use this spreadsheet to auto generate a great deal of the new control system code. So a partial list might include: Module name, Graphic name, Alarm Lo, Alarm Hi, Alarm Units, Direct/Reverse Acting, Square root input, SP Hi limits, SP Lo Limits, scan time, filtering, output hi, output lo, output units, output hi limit, output lo limit, historian resolution, … you get the idea. In addition, I will usually add columns that are used only for the configuration process. These might include details on simple module types (Standard PID, On/Off Valve, Indicating AI, etc.), as well as details on simple interlocking. (Trip motor on LSLL-231, Force PID to 0% with no override if TI-214>500F, etc.)
During the configuration we add still MORE columns indicating what modules have been configured (and by whom) and which have been tested. With a bit of simple manipulation, I can automatically generate a % complete by just checking these columns.
During the installation we add columns indicating which points have been checked (and by whom) so we have a means to track our loop check progress.
Eventually the plant starts up and we take the taglist and strip out a lot of the columns leaving only the ones that the plant will need for maintenance. We’ll also normally add rows for each spare DCS point as this makes future I/O assignments much easier. At that point the much reduced taglist is used to assign new points and new tag numbers and is an easy way to find instrument ranges and loop sheet documentation.
Ways to document control details
There are several ways to document more advanced logic but some are decidedly more easy to use than others. Some people love ISA-5.1 standard diagrams and they are very common in the power industry but the fact is that very few instrument engineers can read them and most production and operations folks have no idea what they mean. We have tried many different options but have settled on the following:
While the PFD offers more process control information than the more cluttered P&IDs, which show many more piping/equipment details most plants are lucky to keep ONE document up to date and I have seen very few (if any) plants that were able to keep a set of PFDs and a set of P&IDs accurate and up to date. (Invariably you end up with two sets of documents each of which has things the other does not have and neither has everything.) That said most plants usually opt for the P&ID (because OSHA says they have to have it).
Since you are most likely stuck with a P&ID then make the most of it. Do NOT try to put every single bubble on the drawing. (IE: An automated on/off valve does NOT need to show the solenoid, the ZSO, the ZSC, and the valve itself. Most people show a single valve (XV-2001), a fail position (FC), and if you want to indicate limit switches, they might show 2DI, 1DO in small print beside it to indicate this. Most add symbology to indicate which devices are associated with the DCS versus field controlled. What IS important is that you show interlocks – both hard wired and major software interlocks – in a format that is easy to read and understand. I have seen plants show a box with an interlock number (like “I-1”) beside the valve and then on the side of the drawing explain what “I-1” does. (“I-1: (SIS) On hihi level LSHH-234, trip XV-2001 closed”). Notes like this are invaluable for Hazops, etc.
Flow charts are an excellent way to show how some of the more complicated sequences, batch phases, and recipes work. For batch installations we create recipe level flow charts that show each major phase as a block and showing the phase parameters that are passed down to the phase. Then we create a flow chart for each phase showing the running, holding, stopping/aborting logic details. We also create flow charts for the major non-batch sequences that might run on the system (start up sequences, etc.) Obviously these documents are key to design, configuration, and FAT testing but most plants keep them up and use them for Hazops during the life of the system.
Some engineering firms will try to convince clients that loop sheets are unnecessary and that the entire installation can be accomplished using interconnection diagrams and junction box drawings. This is true…the INSTALLATION can be accomplished using those diagrams but loop sheets are critical to the maintenance of the plant. They are particularly useful if the loop sheet name is easily derived from the tag itself. If this is done the maintenance tech can easily find the correct drawing by only knowing the loop tag number he is working on. Resist the urge to put TOO much information on the loop sheet – especially if that same information is located elsewhere. Normally the tech needs to know the routing of the wire, the location of any fuses and power sources, and possibly the calibrated range. Adding much more than that makes them very difficult to maintain.
Field wiring diagrams
These diagrams may include the wiring of field junction boxes, fieldbus networks, and possibly the wiring of marshalling panel terminations and card edge wiring. All of these are critical for construction and can be useful for maintenance as a means of locating and assigning spare cable pairs. Fieldbus network diagrams are particularly critical for plant operation and maintenance troubleshooting.
As you can see there are a lot of options but I’ve tried to provide the ones I feel are most critical to a project’s success and long-term viability.
Answers from Greg McMillan
There are ISA standards and resources for documentation listed on the ISA Standards web site. The ISA book Control System Documentation: Applying Symbols and Identification provides a comprehensive view. Just ignore the pneumatic signals and valves without positioners.
Opening up our minds to the future
What if the operator graphics were automatically updated from the P&ID or vice versa? What if there was a PFD graphic that was automatically updated when the operator graphics was updated? What if this PFD had details useful for understanding and improving the automation system such as sensor location and split range and override connections? What if the engineer can click on a measurement or valve and bring up the smart diagnostics and health and calibration results? What if the PFD had updated stream info based on existing measurements to become Live Process Flow Diagrams? (See Flexible Manufacturing and Exceptional Opportunities in Process Control – Live Process Flow Diagrams)
What if the next generation of user graphics has smart trajectory trends with optimized process variable and time scaling and XY plots (e.g., batch endpoint worm, compressor surge curve, and titration curve plots)?
If you could demonstrate this ahead of the next generation of graphics, you would be famous.