Adding more instruments in a crowded conduit

It seems like a simple request. The plant manager calls you into his office and says, “Process Engineering wants to connect six more field instruments to the distributed control system. They’ve already ordered another analog input board for the DCS, so all you have to do is run six twisted pairs from Unit A to the control room.”

“Hold on,” you say. “That unit is 1,000 feet away from the control room, and some of the conduit runs underground. We don’t have six spares in that conduit. Running that many new wires is going to cost us a fortune!”

According to an article by Clifford Lewis (Intech, July 2005), wiring can be expensive. “Many plants allocate the cost of wiring pairs at over $8,000 per pair,” said Lewis. “Other plants estimate the cost of running wires by the foot, which runs $40 to $100 per foot, depending on the electrical classification of the area.” At the maximum cost of $100 per foot, that’s up to $100,000 just to run a cable.

Some engineers may reach for PLC remote I/O as part of the solution, but that too requires some form of wire between the field and the control room. This approach also requires a PLC programmer and, the more players involved in implementing a project, the more complicated the project can become.

In many such cases, a peer-to-peer system is the answer. With a peer-to-peer system, the six field instruments are connected to an input 'brick’ at the remote process unit. The input brick is mounted as close to the field transmitters as practical to minimize field wiring costs. The brick is a small processor with analog and discrete I/O capability to which you connect all six of the 4-20 mA process signals. The input brick is wired to a peer output brick installed in the control room I/O cabinet. Again, with the output brick mounted close to the DCS input cards, wiring costs are minimized. The two bricks communicate via a single twisted pair wire using a peer-to-peer (RS-485) protocol (Fig. 1).

At the control room end, the brick decodes the incoming Modbus signal, and outputs six 4-20 mA signals, which are wired into the new analog input card. As far as the DCS is concerned, it sees six new process signals, and it doesn’t know or care how they got there.

If there are no spare twisted pairs in the conduit, then an easy solution is to disconnect one of the older instruments, wire it into the brick instead and use its wire pair for the RS-485 connection.

If it is simply not possible to create a free twisted pair, there are other options available to still use this simple peer-to-peer solution. If an Ethernet infrastructure is in place, it could be used to connect the bricks. Fiber optic cable can be used if fiber is available. If neither of the above is an option, spread-spectrum radios can be used to move the signals from the field to the control room. The wireless system is transparent to the DCS, which – once again – does not know or care how the signals get to the analog input card.

This peer-to-peer I/O system is bidirectional. Signals originating in the control room can be wired into input bricks and sent out to the field over the same communication medium. Once in the field, those signals are output by the peer output brick to valve actuators or other control and indication devices.

No programming is necessary. The two bricks can be configured with a simple PC program, similar to the way you would configure a transmitter.

This solution is one of simplicity and, in many situations, simple is best. Because you start with analog and discrete signals and end with analog and discrete signals, fewer resources are needed to implement this solution. No knowledge of digital protocols is used in the solution.

Here’s another wrinkle: Process Engineering also wants those new signals to be sent to a PC in the control room, which has been loaded with a special energy analysis software program. The problem is, it is nearly impossible to extract the new data from the DCS database without writing a program in the DCS, and everyone who knew how to do that left the company in the last downsizing.

The peer-to-peer system can solve that problem, too. The control room brick has a second Modbus RTU port and it is a simple matter to connect it to the PC. So the new process data goes to the DCS analog input card as analogs and the PC via Modbus RTU protocol (Fig. 2). In fact, if Process Engineering wanted to add dozens of new instruments at multiple remote locations, and bring all the signals into the DCS and the PC, peer-to-peer can do this, too (Fig. 3). All the remote bricks can be connected to the control room bricks and the PC over a Modbus network.

Gary Prentice is a senior applications engineer at Moore Industries-International, Inc.