Interested in linking to "Loop Drawings for Smart Instruments"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
ISA5.4 is in need of an update to include verbiage and examples of loops using "fieldbus." (I use the quotation marks since there is Foundation fieldbus as well as other generic forms of this mode of communications.) However, the only real difference in showing "smart" instrumentation on loop drawings is the symbol for the communication link between the components of the loop, plus knowledge of the specific instrumentation vendor's terminal designations and interconnection requirements. And while ISA5.4 may be out of date, ANSI/ISA5.1 (2009) is current with the needed symbols to depict fieldbus communications.
Thomas C. McAvinew, PE
A: There are updates to show new transmission methods for wired digital connection and wireless, but a quick scan does not reveal any changes for the "smart-ness" on the symbol. I do not see any construction for CiF (control in the field) that one would use for Foundation fieldbus. There is no designation for the node (instrument) that holds the Foundation fieldbus link active scheduler (LAS) or the backup (bLAS). While there are indications in the symbols for showing on the "panel," there is no designation for indication where (which operator station or stations) the loop display should appear, as one might specify for a DCS to link the loop diagram to the DCS database.
Users are interested in the loop diagrams and symbols, but not enough to participate on the standards committees. Vendors don't care, since they cannot generate competitive advantage from these. Engineering contractors really care, but they have their own standards and probably don't want to share with ISA for fear that they may need to change their standards if ISA selects a different one.
I believe that ISA 5.4 is not ready for distribution of the update – long overdue.
A: Loop sheets evolved for wired 4-20 mA designs. A fieldbus reduces wiring, so something else is needed. The scope of a fieldbus is more appropriate to a single process unit or machine or to a group of equipment pieces linked by a common function. The information would be gathered in a maintenance manual rather than distributed over many loop sheets. The manual can be electronic, if suitable readers are available. A project manager might find it harder to say no to maintenance manuals.
There must be some drawing that shows the location of the component field devices, interface devices, power supplies, terminators and junction blocks, even showing the routing if necessary. There must be some drawing that shows the function of each set of devices, perhaps as analog function blocks or discrete wiring diagrams, with some narrative that explains the use, operation and maintenance issues of the devices, as well as any associated hazards. There could be a common set of data sheets for devices by type.
Because a fieldbus is a communication system, there must be some sort of traffic diagram showing sources and destinations. Such a diagram shows interdependencies, such as who will be affected if a device is removed. This could be a problem for a mesh network, which can reroute messages through other devices.
A: It wasn't that long ago those of us in the process industries—at least in the United States—had to be compelled to update P&I drawings under penalty of law . . . broadly speaking.
If there's no will to update P&IDs, then what's the likelihood loop diagrams or segment diagrams are updated? When the systems engineer decides she's using TI-101 to compensate FI-102, does she religiously make a note on the affected loop sheets, so the plant operator will be aware when he pulls the RTD?
See Also: Maximizing Control-Loop Performance
We evidently didn't have this religion when we were numerous (in relative terms) and now—at least in North America—we are few, perhaps too few. The "lifecycle cost" of useful and reliable loop sheets has already been priced out of the long-term budget (by austere staffing levels) . . . why should projects pay for them? And with the complexity and flexibility of microprocessor-based control systems, is there anyone knowledgeable and insightful enough to certify that every connection and interaction is clearly presented in a manner so that the fellow on the 3 a.m. call-out will notice and comprehend? I wonder how scarce such experts are, whether at clients or contractors, and how much time they have for such an exercise, should we convince our project managers the effort is worth it. My guess is they will be consumed with other complex and high-value-added chores, such as alarm rationalization, HMI optimization, LOPA and SIF analyses, and so on.
Our economies and our technology have perhaps outstripped the ability of paper to ever do the job again, except in the very simplest of process plants. I think the next handheld—maybe the 575?—will have a little wand like Mr. Spock's tricorder, and one will be able to wave it over an instrument, rendering a listing of all its interconnections in the system, as well as a diagnosis of its ailments. Or maybe it will be an app for your iPhone. Would someone invent it, please? And please make sure it's priced below my purchasing card's limit so I don't have to apply for capital funding to buy it . . .
In the real world, I have heard of plants creating "live" loop sheets or segment drawings on the DCS, populated with real-time data, and with the potential for right-click access to cross-references, diagnostics and manuals. If I were going to go to battle for some funding, I think that's what I'd be looking to create, in lieu of CAD drawings or paper . . . Hard disk space is cheap, and selected DCS workstations can be rendered read-only so even the most fat-fingered plant operator can drill down for relevant information.