Sean Phillips is a senior project manager with Hargrove Controls and Automation. In May, Sean was awarded the prestigious 2023 Rising Star Award at the Control System Integrator Association Executive Conference in New Orleans. The Rising Star Award is given to an individual who is relatively new to the industry yet has shown attributes of a leader. Sean graduated from Auburn University and began his career in control systems engineering in 2014. Sean recently spoke with Plant Services editor in chief Thomas Wilk about his career, how automation and advanced technologies are changing the industry, and how the tight equipment can prevent downtime and impact the bottom line.
PS: Tell us some more about yourself and the career path that led you to this point, to earn the CSIA Rising Star Award. I don't know if you want to start with Auburn or start even earlier than that.
SP: We can start with Auburn. I went to Auburn to be an electrical engineer and my overall goal for going there was to work for Alabama Power. I wanted to do power transmission and things like that. Auburn does this really neat thing where they make you sign up for five different co-op interviews. I knew I wanted to do an internship or co-op or something like that, and they make you sign up for five different interviews on the co-op interview day.
Well, obviously, I picked Alabama Power and then I had to fill the slots with four more. One of those slots was Hargrove Controls and Automation, and interestingly enough our current VP Karen Griffin is one of the ones who interviewed me. We get through the interview and it seemed really interesting. I didn't know any of the 1000 acronyms that they were throwing around, because everything in controls is an acronym, right? I didn't really know anything about it, but it seemed really interesting and had high energy. They were quick with an offer and I started doing the co-op at Hargrove.
After one semester I figured out this was an interesting field to be in. At that point, I just had one semester of co-op experience, which is really nothing, but it was a good way of taking the first footsteps into the field. It seemed very interesting in the fact that it was different every day from a contracting point of view. It didn't seem like I was going to be doing mundane tasks, and with my personality, that's really what I was going for, that's what I was looking for in a career, something that I wasn't going to have to do the same thing over and over again every day, a death by cubicle type thing, right? That's not what I was looking for.
PS: I hear you, there's a certain similarity to that in journalism, believe it or not. Even more importantly for our readers who are in the asset management space, I hear that a lot where they like this field because every day is a new day. Something's going to come up whether you’ve got a proactive job to do planned out, or whether it's something that's an emergency. It's never boring.
SP: To a certain extent you get to make your own destiny. For different folks, if they like a more strict schedule, that's offered there too. But yeah, I realized I liked that, so I immediately went back to Auburn the following semester and changed my major to computer engineering so I could get a little more of the programming side of things. Fast forward a couple more semesters, I did the full year co-op and then went back and did a bonus semester in the summer. Once I graduated, I started full time and from there started doing graphics, and then quickly went into configuration, and then did technical lead, and then project management, and now senior project management. It kind of all snowballed, honestly, and most of my career experiences I've been around Emerson DeltaV, that's what I started doing and I do feel like my experience has been very concentrated.
I think that was a good deciding factor in leading me to where I am. I was able to focus in on one system and get a really good skill set surrounding that. That being said, even though it was one system you still have ancillary systems touching that system over and over again, so you still get a good variety of things.
PS: And Emerson DeltaV is going to be a familiar name to our listeners, too, and our readers. Again on the asset management / asset monitoring side, a lot of projects often will start with that, to collect the data and start moving where it has to go. Are those the kinds of projects that you find yourself working on?
SP: On the data collection side of things, the projects I've done in that arena, are mostly in the steel industry, and those are more PLC based. Again, that's just my personal experience, but that's what we've been working on for the past few projects. We'll go in and a lot of times there will be older equipment and we'll put in newer frameworks on top of that to gather the data out and then host it wherever the end user might want.
PS: In the press release sent out about your award, it mentioned that you had a lot of experience in the specialty chemical and the pulp & paper sectors. Could you tell us about some of the projects you remember, whether with Emerson DeltaV or something similar, working with that sector?
SP: So like I was saying before, it's a lot of DeltaV stuff. But just from doing these migrations, knowing the previous system helps a lot too. That has been a lot of my experience in both pulp & paper and specialty chemicals migrations, and specifically TDC 3000 to DeltaV migrations. We have a lot of batch projects as well. My DeltaV experience has been in a lot of specialty chemical and stretching into pharmaceutical as well. They have a lot of batch, and everything is very, very documented down to the letter. So all that kind of ties back into the migrations with TDC. The way we normally go about those things is we'll go in and do narratives, narratives on an individual point basis, if that's what the client wants or we could even do a larger narrative, something like a functional design specification.
And you said that a lot of your listeners are into data gathering for asset management. One of the ways that we would go about doing that usually is writing what we would call a Functional Design Specification. We would go through the process and define, from a process standpoint, what all is included, and then extract that into a table format, that's the second step. From there we can go through and approve with the client exactly what they want because more often than not, and I'm sure we've all seen it, there's a lot of “Test 1-2-3” points in the in the system or, you know, “Sean’s test point,” that type thing. So we’ll have to go through there and weed a bunch of that out and make sure what's getting into the data collection system at the end is actually what is needed. Because you know, if you put garbage in, you get garbage out.
PS: You're talking about operations controls, right, and I'm curious to know, is there a link between what you were doing that you saw in these plant sites and helping plants get a handle on their unplanned downtime? Did you help them make their processes more reliable, more repeatable, that sort of thing? What kind of requests were you getting that drove your projects?
SP: At the end of the day, I can't think of a single client that wouldn't like less downtime, you know. Specifically, I have a client in mind, a smaller operation where they originally had a “discount firm” that came in and programmed it from the start, and so the entire system was pretty much “spaghetti code,” that's what we would call it. You have lines going everywhere, connecting back to who knows where. Everything just takes a lot of troubleshooting, everything from the simplest of changes, you have to troubleshoot what it could potentially cascade into.
This particular plant, was a utility to a larger plant, so their downtime was tracked by the minute. Every time they went down, it was a large sum of money that they had to pay. So because of that, obviously, they wanted the most robust control options that they could get, but being a small plant, they had to watch costs very closely too. One of the biggest things that we ended up doing for them was removing DeviceNet. If anyone’s familiar with DeviceNet, you don't like it. If you're not familiar with it, maybe you like it because it was a little bit cheaper, but if you are familiar with it, you're not going to want it in your plant anymore.
And again, what these folks wanted was for us to rip that out and replace it with EtherNet/IP, which I would recommend to anybody who has any sort of bus protocol like that could potentially have noise in the system, which was their case. They had the DeviceNet cables running right alongside the high-power lines, so they were getting a lot of interference. What we did to get around that was install EtherNet/IPCat6 cable inside of the control room only, and fiber out in the plant; obviously the fiber wouldn't have that same interference, and that alone saved them a lot of downtime. It was compressors out in the field, and every time those tripped from the DeviceNet noise, they would have to go down.
PS: Oh wow. Who knew that noise problems could cause so much of a problem?
SP: And going back to data collection, I feel like a lot of those PLCs out in the field, antiquated stuff, that are talking DeviceNet and other bus protocols over copper, that is something that you definitely have to keep in mind. Even if it's not as drastic as a case as I just mentioned where the plant is tripping, you're still relying on this data for one thing or another, right? So you just have to keep that in mind whenever you're putting that up into a higher system: garbage in, garbage out.
PS: You're talking to a guy where my previous job was with Panduit working for their content marketing, so I did a lot of work on fiber drops inside the plant floor and shielded Cat6 or 6A back to the either the data center or the cloud gate. When you talk to your clients, is there still a lot of work to be done to educate them on that physical layer element of integration? Or are a lot of plants, especially maybe chem or pharma, pulp & paper, where you’ve got sort of a messier environment inside the plant, are they aware that this issue can crop up when it comes to the projects you work on?
SP: That's a very good point. It's getting better now, but a lot of clients still think, or still look at EtherNet/IP as black magic. At the end of the day, it is the most robust communication protocol that I install, and I think a lot of people would agree with me on that.
That being said, there's still a lot of those old bus protocols out in the plant and a lot of people think “if it's not broke, don't fix it.” Broke sometimes can be on a spectrum, you know? Just how broke is it? At what point is that costing you more money than it would cost to install a more robust, let's say, device level ring with EtherNet/IP. Just speaking generally, that's what I'm seeing, it's a matter of weighing the cost of the new install versus getting rid of the old stuff, which sounds like an obvious conclusion to come to, but intermingled with that is the education of the return that you would get from installing these more robust networks.
PS: That's a really insightful point, about broke being on a spectrum. The people who are listening to this today are plant engineers, so they're not beginners in this field, they have a sense of what might be good on the network side. Sometimes it can take a little education on the plant side, especially as not all plants have a handle on where on the (broke) spectrum they want to be.
SP: Yes, that's also a very good point. Going back to a lot of these migrations where we're installing a new system, no client ever wants to be on the bleeding edge of technology. I think we have had a couple, but most everybody doesn't want to be on the bleeding edge. I can't even say all don't want to be back in the ’80s because some still do. But I get it, their mindset is, “if it's not broke, let’s not fix it,” and their threshold for broke is pretty low.
PS: I still do wonder how many machines are running XP in the background, just because it's on the broke spectrum, right?
SP: Or XP or NT, you know?
PS: Let me move to a closing question looking forward to what you're working on now. I understand you're working with the Gulf Coast Exploreum Science Center. As a kid, I was always fascinated by those museums. In my hometown here in Chicago, we have the Museum of Science and Industry; I took a trip out to the Exploratorium out there in San Francisco. Tell us about the Exploreum Science Center and the work you're doing there.
SP: This is kind of the controls engineer dream project. If you're not familiar with it, the Exploreum is basically a place where a lot of field trips come from elementary school, middle school and a range of all ages. They go in there for the different interactive exhibits where they can learn things about a wide variety of topics, mostly in the STEM field, ranging from health all the way to science and math.
For this particular project, they have one little area that is around the health field and it’s to learn about the human body and its different limitations, things like surgery, well-being, and checkups, I think that's the best way to describe it. It's all around the health field.
These exhibits were donated probably 15 years ago, and they're all using old cheap PLCs and a lot of the hardware around it has been abused by 5 and 6 year olds hitting it, and really just doing anything they can to break it. So if you're a controls engineer, you're used to engineering against anything an operator can do to break a machine, well now think about anything a 5 or 6 year old can do to break a machine.
PS: That's not a bad threshold for evaluation for plants. It's a tough crowd, the kindergarten in in elementary school crowd there, they're hard on things, they want to touch and explore.
SP: And their mind works in a completely different way than yours does, right? So it's really interesting to see how they come in there and think of every possible way to take the wind out of your sails for engineering around them. There's such a variety of things that that we have going on in there. One specific example is, which seems like such an easy thing to work around, but they have these seven segment LEDs that are probably about, say, 3 inches by 2 inches large; not small, and not gigantic either. It's actually very hard to find drivers from a PLC to those seven segments without having a bunch of I/O.
So they don't want to add more I/O to the PLC, because that would make everything easier, just outputting a discrete for each segment, right? What we're doing instead is making custom circuit boards for those things, because what we really wanted is to provide them with a way that they could easily change these out in the future. We want to have this very modular and easy for the maintenance guys at the Exploreum to replace. Right now what they have is a culmination of years and years of Band-Aids and fixes, like I'm sure you might have seen in a lot of older plants.
Making full circle back to the co-op program, we have co-ops working on designing these integrated circuit boards as well as the enclosures that we're going to 3D print to put the circuit boards inside, and mount the seven segment LEDs to, which is to me a perfect co-op project. I’m really excited to get them working on this. It's a very good introduction to controls: you have this problem, and no one is telling you exactly how you're going to fix it, they just want it fixed. That's why I say it's the dream controls project: you have design freedom to do what you need.
PS: That is fascinating. It really is a mix of design – physical hardware printing, 3D printing the circuit board, and project management / project problem-solving. Are your co-ops excited about this?
SP: They're all-in on it for sure, as would I have been when I was a co-op.
PS: Well, I got a couple of 9 year olds and a 12 year old who take advantage of every local library program for 3D printing they can. When I tell them they can actually start printing circuit boards, it's going to blow their mind.
SP: Yeah, the circuit board portion of it, we’ll use laser etching to do that.