Systems Integration

How to succeed in career and system migration

The motivations and rewards often seem to have a lot in common.

By Greg McMillan & Stan Weiner

Greg: Here we take advantage of the chance to talk to Bill Thomas, who provides a great lesson of how to succeed in advancing capabilities and opportunities in his career and the control systems for which he was responsible. His career and the systems he improved are analogous examples of the power of migration and the results gained from extra effort and dedication to improvement. Bill is one of the early members of the ISA Mentor Program. He is a very upbeat and positive guy who I have had pleasure of getting to know at ISA and User Group Meetings.

Stan: Bill, what has been your career path?

Bill: I started out as an electronics technician in the Navy. When my enlistment was up, I worked at a shipyard doing electronic repair and retrofits on Coast Guard Cutters. I started taking classes at night working towards a Bachelor of Science degree in electrical engineering. After a while, I decided I wanted my degree a little quicker even though I would be poorer during the process. I enrolled at Auburn University in EE and focused on Power and Controls. The first year was pretty tough because in addition to the full course load, I was also working third shift at a local saw mill, hoping to make ends meet. This became my motivational factor in finishing the degree even though I was struggling financially—I felt that this type of job might be in my future if I didn’t get a degree. Fortunately, after a year or so, I got a position as a co-op at a paper mill. The co-op experience was great for me as I got to work in maintenance, in capital projects and with the automation group. With that experience, I knew that I wanted to go into automation. Upon graduation, I went to work for a large consumer products company as a controls engineer. I worked at their headquarters for eight years and at one of their plants in Texas for another two years. In 2005, I went to work for 3M as a corporate engineer in the Process Information and Control Solutions (PI&CS) group. I am presently residing in Alabama at the Decatur Plant.

Greg: What type of equipment?

Bill: I worked on automating web lines most of my career, first doing narrow web lines for the consumer products company and then a variety of wider lines for 3M. Some of these lines travel at incredibly fast speeds. They were making around 1,000 products per minute. In the past six years, I have focused on chemical reactors and the process industry. When I first came to the chemical side of the site, there was only me, a maintenance controls engineer and the project manager responsible for upgrading controls and automation on all the chemical production units. I was lucky to have worked with those guys. I don’t think there is a control system that the controls guy hasn’t worked on or a problem that he hasn’t seen. We learned early that we were limited somewhat on the instrumentation side, so we convinced a retired 3M technician to give us a hand. He has been with us ever since and been instrumental in the success of our projects. We are now fortunate to have another PI&CS resident engineer, an additional maintenance controls engineer and some technicians working on these systems.

We are responsible for the migration of about 20 reactors and the tank farm. We decided on one controller per reactor to maximize independent maintainability, since these reactors are going up and down. We have completed over a dozen of the reactors and have about a half dozen to go. Each system can have 300 to 1,200 inputs and outputs.

Stan: What are some things you learned?

Bill: I was a programmable logic controller (PLC) guy, so I had to quickly become proficient in the configuration and implementation of a distributed control system (DCS). I have learned to standardize on a preferred class-based library of modules. I have developed the ability to communicate better with manufacturing engineers to make sure we get the right functionality. I have also developed a more structured methodology and better documentation in the front end definition for each reactor system.

White Paper: Wireless Connectivity for the Internet of Things

Greg: How did you use dynamic models?

Bill: We started out using simplistic tiebacks with VMware on a laptop, but graduated to a workstation with Mimic. This enabled us to get operators involved in the functional testing of the control system. Four to six weeks before the configuration needed to be finalized, we would do this testing to make improvements based on operator input.

Stan: How did you contract out the work?

Bill: We split up the work between the local business partner of our DCS supplier and some contract engineering firms, keeping the most proprietary functionality in-house. If we develop the ability to use source protection on the more sensitive details, we can send more outside.

Greg: How did you deal with skids? I have personally experienced the downside throughout my career of skid manufacturers finding innovative ways of using cheaper instrumentation and valves, much to the frustration of the user and the supplier who wants to do the right thing. The most obvious problems have been the use of pressure gages, pressure switches and on-off valves posing as throttling valves instead of sensors with the greatest sensitivity and rangeability, smart transmitters and real control valves, with the monitoring and control done inside the control room. The result is a skid on the skids.

Bill: We learned that we had to give model numbers and performance specifications as well as manufacturer names of the instruments we wanted. Otherwise, we would end up with less reliable types and poor performance.

{pb}

Stan: What is your general approach?

Bill: We never have time or money to do everything. We do the best with what we have to get it to the customer on time. New projects are more of a challenge in terms of a missing starting point. We help the customer understand automation is their friend and we can keep doing more in this friendship. We make this an on-going conversation.

Greg: What are some examples of communication needed?

Bill: In a vacuum system, we were asked to ramp down from point A to B as fast as you can go. We did this, but the manufacturing engineer wasn’t satisfied because the process variable could not keep up with setpoint, so we worked out a compromise between speed and tightness of control. In another system, the speed of a heat-up cycle was specified, but it was later determined that the cool-down cycle was also critical. We needed to get creative.

Greg: I have had process engineers ask to keep the process variable close to setpoint but not move the manipulated variable. This occurred on a condenser control system that was manipulating reflux back to a reactor. I also have had process engineers refuse to let a control loop manipulate a reagent, substrate or air flow for pH, substrate and dissolved oxygen control. They end up trying to schedule these flows based on batch time. They are reluctant to give up manipulation of process input flows to a control system. Lacking is the realization is that you have a choice as to the degree of variability in the process controlled variable or the manipulated variable, and that you cannot predetermine flows as a function of time. You cannot eliminate all variability in both controlled and manipulated variables, and unknowns and disturbances are the nature of the game. The flows and compositions on a process flow diagram (PFD) are a guide and are not to be taken literally. Feedback control is designed to automatically correct for the unknowns and disturbances, and can be tuned to provide the desired degree of transfer of variability from the controlled to the manipulated variable. Feedforward control can be added to preemptively correct for measured changes in process inputs.

Stan: What has been achieved besides elimination of obsolescence?

Bill: Modernizing the control systems has led to better performance, principally by using signal selection and split range to increase versatility, particularly in jacket loops. We also have much more functionality and support available for the new DCS. I really appreciate being able to focus on learning how to get the most out of a new DCS rather than investing my time getting by with an old DCS with no future.

Greg: What about your overall experience as an automation engineer?

Bill: I feel lucky to having gotten into automation. It’s like I’m building multimillion-dollar erector sets. I get to see stuff working in action. The control system is the window into the process and means of affecting the process. The dynamic and visual impact is impressive. I look forward to seeing in 15 to 20 years how much will change. I have gone from ladder logic, analog devices and 4-20 mA to functional blocks, digital devices and fieldbus in my career so far. At the end of the day, what we do in automation is solve problems, and we get to see the effect on the plant efficiency and capacity. Automation is a challenging and rewarding profession.

Top 10 reasons to migrate your career 

  • (10) Limited functionality
  • (9) No technical support
  • (8) Too many manual actions
  • (7) Worn out
  • (6) Convoluted logic
  • (5) Replaceable by robots or the cloud
  • (4) Isolation
  • (3) Dumb stuff
  • (2) Graphic disadvantages
  • (1) Outsourced