CG0808OTBbutton

Bus = Remote I/O?

Aug. 7, 2008
Consider “Bussing” a Network of 8- to 12-Point Analog and Discrete I/O and Locating It Strategically Close to the Field Sensors
By John Rezabek, Contributing Editor

I’m installing a new analyzer shelter in a distant part of our facility, and I’m wondering how best to bring in all the miscellaneous I/O. Analyzer shelters have their own not-insignificant subset of I/O—purge alarms, toxic gas detectors, trouble alarms, analog inputs, etc.—which can consume a fair number of spare wires. Does it make sense to integrate these points on a single twisted-pair fieldbus? Fieldbus or remote I/O? With the products and tools available today, I think the answer is “Yes!”
Process plants have always had a need for large numbers of indicate-only (not used in closed-loop control) I/O. Some of us may still have some of the antiquated, lever-switch-operated multiplexors used for thermocouples before the 1980s.

With the advent of DCS-based control, we used proprietary solutions like the Honeywell Low-Energy Process Interface Unit (LEPIU) and, in recent years, Modbus or Modbus-over-Ethernet. With all these solutions, we ended up with a number of remote housings—glorified junction boxes—where scores or even hundreds of these indicate-only points were concentrated. These solutions nearly always needed their own power supplies, and they were subject to all the vagaries of field-originated AC power. Even though they were more “local” than the control house’s marshalling panel, their scarcity could mean some long wire and conduit runs.

Today, manufacturers like Pepperl+Fuchs (P+F) have products that provide up to 40 discrete or 20 analog I/O, all over H1. Products ranging from four to eight or more digital or analog I/O also are available from MTL, StoneL, R. Stahl, Rosemount, Bürkert Werke and several others. These suppliers have devices that are registered and carry the Foundation fieldbus (FF) checkmark, and many have similar/identical products for Profibus PA. This new repertoire of products should have us all rethinking how we bring in “multiplexed” points from our former lifetimes.

Rather than run many feet of expensive conduit and wire, consider “bussing” a network of 8- to 12-point analog and discrete I/O, and locating it strategically close to the field sensors. If your facility is adding a couple new distillation towers, for example, you may be able to serve each with one 848T from Rosemount, MTL’s 9331-T1 or an F2D0-TI from P+F. If you’re only bringing in low-power analogs and discretes—thermocouples, resistance temperature detectors or contact closures—the power already on your H1 or PA twisted-pair bus is enough. In most cases, no field-sourced power is needed.

The other beauty of Foundation fieldbus and Profibus PA is that you can hook onto just about any fieldbus segment wherever it makes sense. I don’t need a separate network running around the plant for Modbus—like I have now.

Profibus advocates will point out that Profibus DP, off which one’s PA segments hang, also supports numerous products for discrete and conventional analog I/O. Users will see a certain kinship between the DP solutions and Modbus/RS-485 products, as DP does not provide loop power, and the density/power requirements will likely preclude the “geographic” distribution that’s possible with the FF and PA devices.

What about wireless? We should also strongly consider the possibilities, especially for greenfield plants. Traditionally, multiplexed I/O is a good place to try wireless, and arguably, wireless infrastructure will become increasingly useful in the longer term. However, if I’m already running a fieldbus infrastructure for critical process control, the incremental cost to hardwire “muxed,” indicate-only I/O may be low, meaning wireless will have to be pretty cheap (including added spare parts). For my one-off analyzer shelter, I can’t justify wireless at the moment, not with a FF segment a few dozen feet away. Meanwhile, the relatively new multi-point I/O for FF and PA has created some opportunities for efficiencies we should explore.