One of the hottest topics on the minds of MRO professionals this past year has been how to add remote asset condition monitoring into their mix of daily maintenance work. Tim White, CMRP, is a Senior Manager at T.A. Cook focused on providing services related to Digital Asset Performance Management. Previously he worked in the industry as a Global Director for Asset Management, responsible for 83 sites across the globe. Plant Services Chief Editor Thomas Wilk had the opportunity to ask White for his thoughts on the renewed industry focus on condition monitoring and digitalization.
PS: What trends are you seeing in industrial digitalization, and would you say are these the same for small to medium facilities as for larger facilities?
TW: This year I've been running into companies that either (a) made the leap a few years ago and heavily invested. And when I say heavily invested, I mean, like, nine-digit type investments. They went full bore. And (b) the other folks were the guys on the fence and they were like, "Well, I'm going to sit back to see how this goes and let everybody else work out the problems." Which arguably was a good and bad decision, bad from the case that they're going to be playing catch-up and trying to get to a level where their competitors are. Their competitors who made the leap, even though they might've had some difficulties that they had to work through, they probably learned a lot more and understand what they're doing a lot better.
I see a lot of push for the condition monitoring space; I'm going to speak specifically to asset management. We have a lot of people wanting to get on board with that, and the driver seems to always be, How can I reduce the personnel that I have now? How can I start automating some of this? They have a lot of manual processes, a lot of things that they're doing that require human labor, and they need to cut back on cost. They see digitalization efforts as a way to reduce staffing requirements. It’s not necessarily that they're going to just cut all their staff, but it gives them a vehicle mostly through the attrition process where they can slowly let positions go away as they mature with their digitalization.
The other thing is, many folks have started messing with data a lot, and maybe they got themselves to a point where they’re collecting a whole bunch of information: "Well, okay. I've got all this data coming in but I have no idea what to do with it." So, they took step one and never continued on and they're trying to figure out, “where's all this value that everybody keeps telling me I'm going to get? I don't know what to do.”
But the other piece is maybe they've made a first step, and from a manual or batch-type process they're calling back data or downloading segments of data into some kind of spreadsheet format, and they're paying people to sit there and try to go through and analyze this and try to find information, which is not that efficient. So, they're looking to say, "How can I automate this more? How can I find information easier?” Those two things are probably what I get asked about the most.
PS: Do you see any patterns with those trends breaking out between the small to medium-sized facilities (where your average maintenance team might wear multiple hats) versus larger facilities that can afford more specialized positions?
TW: I would say that if a small company makes a decision to do something, they tend to go a step further than the larger companies do just because of the fact they don't have staff in the first place.
Larger companies tend to dip their toe into things and then pay people to try to do something with what they have. Sometimes that journey, where they fall into the valley of despair, tends to last a little longer, just because of the fact that they do have resources. Then it's hard to get them to come back out from that. Usually, a good roadmap that gets laid out for them and a successful proof of value where they can really see how things go, helps them get that big “a-ha” moment and then they charge forward again.
PS: Can you talk about some of the benefits that you've seen plants experience when they do undergo either a digital maturity assessment or some other similar kind of benchmarking when they're about to make these kind of moves?
TW: This goes back to the “I had all this data and I don't know what to do with it” issue. T.A. Cook delivers digital maturity assessments as well as an offering, so when I lead those efforts, usually customers are looking to make a step forward from, "Okay, I don't understand where I'm at and what I need to do to progress further or develop further within this maturity."
One of the things that we do is we will rank clients on a 1-6 scale, but it's not against their peers. It's really against what that development path should look like from the first steps of what we call “computerization.” This is where we gather information and have it all together but many times still in isolation. Maybe they have several different applications but they're still very siloed or isolated. This scale goes all the way through our 6th ranking which we call adaptability, where now we're making autonomous decisions and taking actions at some level automatically. We rate them against that development path, and they get to see how far they've come on their journey.
When we do those assessments it also gives us a chance to really dive into the systems that they have. We not only look at their information systems and the data quality, but also what they have for resources; and what I mean by resources is sensor technology, the competencies, the ability to process data, etc. This also includes their organizational structure: how's their culture, and is their culture ready to accept this change or this initiative?
So, it gives them a good snapshot, but then we dive deep into the systems that they have and we can really look at where they're at and be able to assess gaps with what they've put in place already and where we need to go to make that next step.
You see all facets, and get a good snapshot of “where are we at,” which enables you to decide “where it is we're trying to get to.” We build that roadmap for them and lay out the steps that need to be taken care of.
PS: It sounds like those kinds of efforts can make a difference in whether you'd recommend a plant team to pursue either limited data collection based on a single problem or whether more of a data lake approach would be to their best interest and best benefit.
TW: I wish there was a simple answer for all of this. Really what we need to look at is if we talk about limited storage or data consumption. There's pros and cons to all this. If you go with the limited data approach, what you're forced to do is, in the beginning, when you probably don't even know where you want to end up at, you've got to define it. And usually you will later find you defined it incorrectly. You thought you knew where you wanted to go, but as you start down that path, you learn more, then you say, "Oh, wow. If I had this or if I had that..."
A great example is, a lot of times companies that offer data historians will charge by the tag. So, if I have 100,000 tags that I want to collect, I say, "Okay, I'm going to buy a license that allows me to collect 100,000 tags." And then I start learning with it and find out, "Oh, there's more stuff I want to do but now I can’t collect the data because my license is only for 100,000. You know, that's pretty expensive, I don't really want to expand that. So, what can I get rid of so I can add this other new stuff that I'm thinking is going to bring more value?”
You start this juggling game, and the flip side of that would be a license that has an unlimited count of tags, and usually they'll refer to these as enterprise licenses or something similar. This option gives more flexibility, and I'm a big advocate that when you start collecting OT data, you should grab it all. I can know kind of where I want to go, but until the analysts and data scientists get to work and start looking at what can be done from an engineering side, I find there's a lot of that data that if I had to make a decision upfront, I wouldn't have collected it.
Then someone else from the business goes, “hey, by the way, are you collecting this,” or “we just had a mishap and I need to know what the sequence is that the control board operator did.” These are basically on, off, open, close type commands, they're binary, and most people would be like, "oh, we don't need that." But suddenly, someone's knee-deep into an investigation, and I can suddenly produce that data and it brings value to our organization.
Data lakes: now we're talking two or more systems, and the downside to it is there's little to no governance around the data that's being collected. It’s like, "Here it is but use it at your own risk, if you will." The other thing is that when you want to go use it, now you've got to process it, clean it up, and make it to where I can do something. So that's the downside.
The upside is, if I don't know what I want to do, and I've got multiple systems, and I want it in a single storage place, now I've got a really inexpensive way to grab all the data. So, if I decide, for example, Amazon Web Services or AWS is going to charge me two cents a gigabyte, that's pretty cheap. Then when it starts to become really old data, I say, "Well, let's archive that. I only need the last five years." Now they're only going to charge me close to a tenth of a cent per gigabyte. So now I've got cheap storage, I don't need a lot of processing to get that data, and it's available when I figure out what I want to do.
Listen to the entire interview
When we set up monitoring programs, a lot of times we end up using data for more than one system, so this becomes a benefit many times. Let's say a client has an MES for scheduling and controlling all their manufacturing. And then let's say they have certain information within their maintenance system that I want to use. Then we have all the control system data that's coming in, and I'm using all of this to address different things about an asset that I want to monitor. Now suddenly the data is all available and it's very easy to get to.
If I have siloed areas, now I'm building things like APIs in order to go grab data and try to do something with it, potentially taxing the other system and affecting its performance, as opposed to having everything residing in one place, albeit maybe not very cleansed information but I could do something with it. Many times there's plenty of programs out there where I can set the rules to clean and structure the data once, and then I'll never have to do it again. So there are some benefits on that side.
So, what do I think? I think it depends on where the customer's trying to go. If they're trying to grow slowly, maybe there's an approach that fits. A lot of times you find many of these things are already in place because somewhere somebody told them to go do it and so they did, maybe even blindly. But it goes back to the assessment piece you asked me about, we may find that these systems are there and available. Now, what's the next step to make use of that and bring some value back to them?
PS: That makes sense, that it depends on the strategy the company charts out and that sometimes, I'll be frank, a lot of companies don't have the internal resources. Even if they do have, say, a dedicated reliability engineer to work on that, that engineer may want to partner up with someone who's been through this before to figure out what the right steps to take would be.
TW: And quite honestly, it's not just a reliability engineer that's going to be doing it. One of the things that gets really important here, and I hear the biggest complaints about, ironically, is you're going to have to partner with other folks within your organization. You as the reliability engineer or if you have an asset management partner, even if it's just the maintenance department, you're customarily probably used to working in a silo anyway, apart from the rest of the business. Now you're suddenly going to need a lot of help. I could joke about how no one’s IT department is any good. Have you ever noticed that?
PS: Funny how that works, yeah.
TW: But the reality is, and even before I was at TA Cook, when I worked in the industry and I owned these platforms and the asset management department globally, one of the things that I think paid the most benefits for us right at the very beginning started out with my CEO saying, "Tim, I want you to bring me the digital plan." I had no idea what that even meant, and in what context do you want me to do this? We had to figure it out.
Talking with a lot of people, this is where we got the idea, "why don't we go back through the control system data first because we already have it and figure out what we can do with it, and then let's close the gaps as we mature." This is where the IIoT stuff comes in, where you start looking for additional sensors and you look for the business case or the cost/value proposition of adding this, and what it's going to get me.
So, we started with the industrial control system data. Well, I knew I'm going to need help from IT on this, so I go upstairs to our IT floor and sit down with our director of communications and security, a good friend of mine I've gotten to know over the years. I said, "Rob, I've got this crazy idea and I need to know if we can do it and if so, how do we approach it."
I laid out this whole idea, and he says, "Yeah, sure." He got out his whiteboard in his office and we started talking about different things. We gained complete buy-in upfront and had the entire support from the IT department to help us on our initiative because we went to them first and asked, "what are the rules of IT, and what do we need? I'm about to take a whole bunch of isolated systems that control all our assets and I want to hook it up to the business network." Usually, that's what makes everybody cringe.
Then you start finding out you've got satellite IT systems because some manager got tired of waiting and fighting and he just went and bought his own server and stuck it in a closet and didn't tell anybody. There is a whole cybersecurity area that you’ve got to make sure is in place and rigid enough.
It's important, as you progress and you start to put systems in, to bring in a third party. Tell them, “Look at my security. Try to hack it. Can you take over this reactor? Can you do whatever in that process?” And get those things checked upfront. That whole thing with the pipeline was ransomware, and I read an article that said ransomware gets in your organization usually one of two ways. Either somebody clicked on something in an email, or their passwords were not complex enough. When your password is “password”, that's probably not a good thing.
PS: I was in a session one time at a maintenance conference and there was a session on cyber. The speaker said, "raise your hand if you've had experience being attacked" and easily one-third of the hands went up. This was about two years ago now, three years ago and that was the one-third of the folks who thought they could put their hands up and not get any blowback from it. There were some folks in there who said they had to rebuild their server in a couple of cases. Like you said, the common vector is that sort of phishing attack or simple passwords.
TW: Well, this all comes back to where I was beginning. And that's why the IT folks get upset and maybe even seem noncooperative; because this is what they're worried about. Ask them, "What are the rules to the game or what do we need to make sure we do, and will you help me achieve this over here?" I sat on a panel at a fairly large conference and the thing I heard from the audience the most was about the conflicts between IT and OT. And when I got asked a question about whatever it is IT and OT were talking about that specific day, I said “guys, I can't even comment because I don't have this problem.” I didn't realize the effect of all that until I sat on that panel and later thought, "Wow. This is probably what I mitigated by going to them first, because I don't have this frustration I'm hearing from everybody else in this room."
PS: Okay, let me ask this last question, and this may be a simple yes or no. A survey last January from Honeywell found that more than half of U.S. companies were “planning to increase automation investments due to COVID-19.” A survey that we did with our readers on Plant Services found that their greatest perceived need was a strong or a stronger EH&S program. Now, these aren’t mutually exclusive. I'm just curious to know what are you seeing on the ground, and are either of these trends becoming realities.
TW: I think it's yes on both counts and it depends on the client. So, there's things at play here. One is, there are people wanting, I don't know if I would call it “automation” as much as I would “condition monitoring.” Even people that have very mature predictive maintenance programs, they're more on traditional human, route-based, periodic data collection. Everybody's hearing about how you can bring this stuff online, and really the biggest thing is that the cost vector has dropped so much. I can remember in the early 2000s, it was almost unheard of to spend the money for online vibration monitoring. It had better be a critical piece of equipment like a turbine in a powerplant – high critical, high cost, big consequences of failure or of self-destruction. It would be a bad day for them. Now, it's not that big a deal. The cost is so greatly reduced. I've outfitted entire control systems and the assets that go with it for less than what I might have instrumented a turbine for 20 years ago. That's one thing that drives people to do that, and they know their competitors are doing it.
Senior leadership within companies knows the senior leadership at all the other companies, and they talk. I can tell you that from experience. We call it professional courtesy, and you understand what the other guys are doing, and what happens is a lot of times out of fear, they want to catch up. I wouldn't necessarily call those companies the leaders. They're more the followers but, out of necessity, they're trying to move forward.
So, the condition monitoring piece, yes, we see that. It's ironic that you mention EHS, because we've had other companies that when you talk about EHS, it's the “E” they're worried about, the environmental. Not necessarily health and safety in relation to personnel safety, because I think for the most part, most companies have got that figured out. Maybe from a process safety or PSM approach, maybe they want some improvements around those areas.
What I find, it's more the E than anything. I don't know if you've heard of this, I think it's only been growing over the last couple of years, but companies are starting to get assigned ESG scores. It's almost like a KPI that the general public is holding these companies accountable to. The ESG is environmental impact, social impact, and the governance of the company. So, what are their policies? And on the environmental side, obviously, it's all about what's your carbon footprint look like, how much of the product you make is reusable or your packaging is reusable, and so that makes them environmentally friendly. I think a lot of companies are very concerned about their environmental impact now, and are moving down the path of trying to make sure that that's as reduced as possible with where we're at with technology and what we can actually do today. That's where I think the EHS stuff is coming from.
We work with a huge mining conglomerate, and I know that when we were starting to look at operator care or precision maintenance practices within their facilities. We're talking about basic things but just on belt slip alone on some of their larger pieces of equipment, we had determined an enormous savings that we could make across one facility and literally give them a spare piece of equipment just by resolving something as simple as belt slip. But then the thing that was really, really interesting is when we said, "and you would reduce your carbon footprint by doing this." And it amazed me how interested they were in that.
PS: Interesting.
TW: Nothing to do with dollars yet today, it had to do with just the amount of carbon emissions that they would've had from their production. You could argue one day it might cost them, because of the idea of buying off your carbon credits becomes a reality, some companies are going to miserably fail and it's going to cost more money. But the ones that are really, really good are going to be the ones selling. They're going to find another revenue stream. That was one example of where I've seen that and how they laser-focused right in on that.