Hi there, welcome back. This is the second part of an interview I did with Atomic Revenue about the difference between Legacy Controls Migration and Controls Modernization. Read the first part, which included references to video games, the growth mindset, and data analytics, here.

Quick summary: Legacy Controls Migration is getting an old system up to the latest and greatest hardware and software, to avoid downtime in case of failure. Controls Modernization is a separate project to take advantage of new functionality for higher efficiency, greater reliability, and better analytics, among other aspects.]

AR: How does that set you up for the future? If you complete a major modernization project now, when might you need another? Is it two years? Five? Or could you say that if you did it right, you won’t need to have that same kind of transformative modernization project for a significant amount of time?

QSI: I would say after modernization they are good for a significant amount of time. A lot of these systems that they’re upgrading are 20, 30, years old. And they’ve worked fine to that point in time. But now as things get more competitive, if they want to stay ahead of the curve, you know, they may not want to wait another 30 years. You may continue to upgrade along the way, which is easier with more scalable control systems. You see that a lot, in these old systems they’ve added devices over time to better control the process. They say “We want to rewrite this whole thing, because along the way we’ve added this, and this, and this conveyor offshoot, and this burner, and it’s made our process better, but it was pieced together.”

Things kind of get disorganized. We call it “spaghetti code”, and it becomes very hard to manage. But the structure of programs now is so much better and so much easier to manage, which is another benefit that you wouldn’t think of as obvious. It’s having more structure to your programs, better organization and your controls are laid out in a much more logical fashion. Documentation is much better, too, so you’re not losing descriptions in your programming, and all that consistency makes your maintenance more effective. Because what was written before, by, say, potentially 10 different operators as they added to the code, now is rewritten with by an experienced engineer with structure and organization in mind. We’ve reimagined the whole system and there is no need to be diving into the programming all the time, because it works.

You know, I’ve described that process where you have something that works, but you need a new function, so you just stick something else on to the side, I’ve called that the Frankenstein method. “We’re just going to add this little thing here, we’re just going to work-around that there, we’re going to add one other feature here,” and in the end it’s almost unrecognizable compared to what you started with. But it does kind of the things that you need it to do, yet you’re fighting with it all the time and it doesn’t really behave. It sort of takes on a mind of its own at times. So you occasionally need to hit the reset.

People who think like that are growth-minded people. We like working with those kind of people. Those are your facilities that are more likely to modernize. The ones that have been driving constant change as new technology advancements come out, and have been saying, “Hey we can improve this?” Or, “This is a process that’s broken.”

Often they’ve done an adequate job as they’ve grown, they’ve improved along the way, and the last piece is for them to take the next step and modernize. They need to rethink it all integrated together in the way that it works now, which is so different than the way that it did 30 years before. Those are the customers that are fun to work with.

The ones that put in a system 30 years ago and it was very limited and they didn’t really look to change it, as new technologies came out, they didn’t add on new functionality, those are the ones that are more likely to be about just mitigating risk. They are more likely to say, “Hey, give me the same thing in a new system, I don’t care to modernize.” So that’s your two different types of mentalities, and typically one of the factors that decides between migration and modernization.

That first mindset is the growth mindset, the second mindset is “I’m just going to do my job, and I don’t want anything to break along the way.”

Yeah, and that’s why I say it’s not completely a cost thing. It’s not just cost, it’s cost plus that growth mindset versus risk mitigation. Those are the two factors, and which is the right approach is going to be different for everyone. Because, if you were satisfied with the system you had, and you just didn’t want it to go down, you really wouldn’t want to spend the money on rewriting, adding bells and whistles that you don’t care to use. It’s the difference between a growth mindset and a “Hey, this works, don’t fix what isn’t broken.”

In terms of helping with planning, obviously small, medium, and large projects are going to have different time frames for each one. What might be some minimum and maximum estimates for those, how long it would take from start to finish?

If you’re doing a simple migration, you have a small system and you just want to get to the latest and greatest hardware or software platform, usually you’re looking at about four to six weeks of engineering time, which might not always be linear. That’s usually we’re handing over the keys of exactly what you had before. There’s no differences, there’s just an upgraded hardware platform on the back end. That’s a small timeline, and we would just do the design, work on the migration, update the code, and then go out and do the testing and training. There’s not usually a whole lot of training on that, so about four to six weeks of work for an engineer and now they don’t have the risk of failure and downtime.

If you’re going into the modernization, usually, you would look at that differently, like I’ve said many times, as if it was a new project. So a small system, for example, we’ve done a project for a sucrose tank system. There’s a three-tank sucrose skid that basically receives sucrose from trucks, supplies its own header, keeps its temperature, maintains pressure, and that’s about it. It lets other systems pull and open a valve to deliver the sucrose to another process. This is a small, enclosed system with a few racks of I/O [Input/output].

You would do a sequence of operations on how it’s supposed to work, you would do a design to incorporate the I/O into the control system, you would write the program, you go onsite and test out the I/O, and then test the functionality. Usually a couple of days of support and training with the operators and you’re out. Smaller system like that, maybe an additional six weeks of engineering time to get that done, once you’ve completed the migration.

For more mid-sized systems, like sand filters, of which we have a case study, that’s a bigger and more complex system. Four tanks, with detailed multi-step sequences, like the backwashing skid, and a lot more equipment, but the control is mostly repeated. The control, the functionality, the visibility is all shown pretty much the same on each tank, which makes it a little simpler. We could modernize a more complicated system like that, in a few months worth of time. About double the time, but potentially completed in the same time for the calendar with two to three engineers.

Then you could get into big, multi-line systems, like the cookers, and the flour mills, those are more in the four to six month range. When it came to the cookers, that was a 7-line production floor with tote dumping, cooking, cooling, oil coating and tank storage. The flour mills project had hundreds of devices integrating into multiple processes, with many different control loops. All these different processes all put together in one line, those more complicated systems you’re looking at more like a four to six month modernization with several engineers on the job.

This has been a very enlightening discussion. What else do you think people should know, to take away from this conversation?

I just want to point out that, in addition to all that we’ve discussed, there’s often a pretty clear case for a positive ROI on modernization projects. You can justify the spend by integrating different data history and visualization packages that prove out better consistency, increased productivity, and reduced maintenance troubleshooting. Sometimes it’s easier to see ROI justification for a migration, you know, improving to the latest and greatest hardware and software, and minimizing the risk of some dollar amount of lost production time. The improvements, though, in the modernization phase, are all about the upside. There’s a lot of potential that may not be quantifiable at the outset, but will be clearly evident after the project is in place and better decisions are being made, better efficiency is demonstrated, and reduced costs are dropping to the bottom line.

Thank you!
Very welcome.