As control engineers, we often get tunnel vision. We get very focused on a single task such as creating our control module configuration and lose sight of the bigger picture – creating a control system. While working on my bachelor’s degree, I worked as an instrument designer for big A&E firms that built power generation stations. My job was to specify instrumentation and control elements for these projects, design control panels, create loop sheets for the hookup of the electronic instruments, and installation details for the sensing side – or in the case of pneumatic instruments – the pneumatic tubing. At that point in my career, a loop was from sensor to controller and from controller to control element. I had nothing to do with specifying the controller itself, which at that time was typically a standalone device mounted on the control panel. I also completed all drawings to control the operation of electrical prime movers, which were wired back to the switches on the control panel.
Jump forward in time a few years to the introduction of the DCS. Instead of following my usual practice of calling the Bailey or Foxboro guy and just buying a standalone PID controller, I was now expected to program the control function as well as direct the designer on the instrument and control element design. This really did open up a world of possibilities for the control design strategy that would have been impractical before for creating highly interactive and complex controls. Unfortunately, for many of my contemporaries who hadn’t come up through the path I had, it also focused them on what was happening in the space between the input and output terminals with little or no regard to what was happening outside the box.
During that period, I moved from the design engineering firms to work for a DCS supplier. In working with some of their project teams, I would often inquire into the design of specific control modules, which they referred to as control loops. My inquiries would usually take the form of, “What kind of transmitter are you using or what kind of control element, valve, pump, or fan are you operating?”
To my horror, the usual answer was, “I don’t know.” To make matters worse, that was often followed with, “It doesn’t really matter, this will control anything.”
Now, on the surface, this is a reasonable answer since you can control almost anything in a typical process with a PID function and some appropriate interlocks or permissives. The problems arise when you can’t answer simple loop questions like:
“Is the loop direct or reverse acting?”
“Does the valve fail open or fail closed?”or,
“Is the measurement linear?”
Without understanding the whole loop, you can easily misapply the control functions within the control module. Other more esoteric aspects of the loop that might need understanding could include the need to start a very large fan against a closed damper to prevent overloading the motor. If the loop designer doesn’t know this, then the controls may be designed to force the operator to startup the process incorrectly. In many ways, it is now more important than ever that the person designing the controls understand the whole loop to ensure that he or she doesn’t prevent the operators from doing their job.
This post was written by Bruce Brandt, PE. Bruce is the DeltaV technology leader at MAVERICK Technologies, a leading system integrator providing industrial automation, operational support, and control systems engineering services in the manufacturing and 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, and business process optimization. The company provides a full range of automation and controls services – ranging from PID controller tuning and HMI programming to serving as a main automation contractor. Additionally MAVERICK offers industrial and technical staffing services, placing on-site automation, instrumentation and controls engineers.