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.

01/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.



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
Control Engineering Leaders Under 40 identifies and gives recognition to young engineers who...
Learn more about methods used to ensure that the integration between the safety system and the process control...
Adding industrial toughness and reliability to Ethernet eGuide
Technological advances like multiple-in-multiple-out (MIMO) transmitting and receiving
Big plans for small nuclear reactors: Simpler, safer control designs; Smarter manufacturing; Industrial cloud; Mobile HMI; Controls convergence
Virtualization advice: 4 ways splitting servers can help manufacturing; Efficient motion controls; Fill the brain drain; Learn from the HART Plant of the Year
Two sides to process safety: Combining human and technical factors in your program; Preparing HMI graphics for migrations; Mechatronics and safety; Engineers' Choice Awards
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
News and comments from Control Engineering process industries editor, Peter Welander.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
Anthony Baker is a fictitious aggregation of experts from Callisto Integration, providing manufacturing consulting and systems integration.
Integrator Guide

Integrator Guide

Search the online Automation Integrator Guide
 

Create New Listing

Visit the System Integrators page to view past winners of Control Engineering's System Integrator of the Year Award and learn how to enter the competition. You will also find more information on system integrators and Control System Integrators Association.

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.