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.
