Configuring control systems through wireless devices, remote I/O: With great power comes great responsibility

In the new world of wireless devices and remote I/O we have the power to create control configurations that use I/O and that are not physically connected to the controller running the control loops.

By Bruce Brandt January 14, 2014

In the new world of wireless devices and remote I/O we have the power to create control configurations that use I/O and that are not physically connected to the controller running the control loops. In the case of at least one distributed control system (DCS), the I/O attached to its gateway can be assigned to different controllers on a per I/O point basis. Within the confines of the configuration application there are pointers to where these live, but in the context of project documentation the world becomes a bit blurry.

Wireless I/O is another story all together. Even if the technician trying to troubleshoot the loop knows which wireless gateway the device is talking to, that isn’t an indication of where the device is located within the plant.

When I started in this business, control systems were panelboard-mounted and could be either electronic or pneumatic. Regardless of the motive force executing the control, the controllers themselves often consisted of several different modules to do the required preprocessing of the measurement before feeding it to a proportional integral derivative (PID) controller.

In fact, the controller may have only been a PI controller, or a PD controller, or even just a P controller. There was an add-on module for finding the square root of a differential pressure to create a flow signal, as well as one for adding two signals. Yes, there were even pneumatic versions of these analog computing modules. As a result, we drew loop sheets that showed how all these devices were connected together, and there was usually some indication on the loop sheet about the locations of the various parts of the loop. We referred to these kinds of systems as having a split architecture because the interface for the operator, the panel-mounted station for entering setpoints, and making mode changes were separate from the parts doing the actual control.

As control systems progressed through the 1970s and components became smaller we eventually got away from this split architecture format and could put everything in the boards that were behind the operator’s panel-mounted station. They were still analog, so you had to order different flavors to get the different forms of the control “algorithm.” You also had to be careful to make sure everything matched because there was a battle between the vendors who backed the 4 to 20 mAdc standard and those who used the 10 to 50 mAdc standard. There were also several other vendor specific signal ranges that could trip you up. Connect the wrong transmitter to your controller and you might only have 10 mA to work with. Even once we got to these integrated controllers there was still the need to document if any signal splitters might be in the loop to either share one transmitter between two controllers, or a controller and a chart recorder, or one output between two valves.

In the current world of remote I/O and wireless networks we haven’t yet settled on something to replace the loop sheet. Some companies have taken it so far as to not only stop doing loop sheets but to also stop doing wire lists. When a company uses the technology I mentioned earlier, where any single I/O point can be addressed to any controller, they just order cabinets that will mount in the field and have the support infrastructure inside to let any I/O point in its vicinity be wired to it. These wires are labeled with the tag number of the device and the appropriate signal conditioning module gets plugged into the chassis to support it. A list of the tags is then used to tell the control module where its I/O signals are coming from and going to. The control system will sense the conditioning modules to tell you what is located in which I/O rack in terms of signal types, but you still need to tag the signals for later use. The good news is if you have that in a spreadsheet you can bulk import it into the database. The bad news is you still have to create the spreadsheet.

So how do we document these new systems? I’ll float out one possible solution and invite you to add your ideas.

In addition to the usual identification on the wire tags, add a bar code that carries not just the tag number but the information about the device, like model number, range, manufacturer, service, and anything else you need for the long term maintenance of that device. Put a similar bar code on the device and on the signal conditioning module including its location in the I/O rack, the cabinet, and the cabinet location. Link all of these to a database application that can create exports for importing into the DCS and to other applications, like CAD, for creating an I/O layout drawing for each cabinet or a maintenance package for tracking failures and managing spares. This could then become a significant extension to the Instrument Index that has other information, like the PO the devices were bought on for reorder. We have the power to manage this like never before so we have a responsibility to do so.

Now, how are you going to ensure that you make use of what we have been given to make your next DCS project the last one where finding out what’s installed doesn’t require days of research?

This post was written by Bruce Brandt. Bruce is a technology leader at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.