Automating OEE data collection can help solve problems on the line

Larry West is a sales engineer for Perceptive Controls who has been in the engineering and electrical field for industrial use for roughly 25 years, and before that he served in the U.S. Navy as a gunner’s mate and missile tech. In January, Larry touched base with Plant Services Editor in Chief Thomas Wilk for a podcast on how control systems and SCADA can support energy savings and sustainability. Recently, Wilk spoke with West on why automating OEE data collection can help solve problems on the line.

PS: Larry, last time we spoke, we talked about sustainability and the way that control systems can help all kinds of plant teams, but especially the maintenance and operations function, achieve their green goals or sustainability goals. But then you came back to me and said, you know, there's a term that is being pushed down from on top in a lot of cases, and there are people in the plant, particularly on the operator side, that might not know what about this term. It's “OEE”.

And so for those listening today, this is going to be a podcast on what OEE is and what operators and their maintenance colleagues can do about it when asked to calculate it, measure it, improve it, that sort of thing. Does that sound about right, Larry?

LW: That's it.

PS: Well, then let's start with the first question. For those who might be unfamiliar with the term “OEE” can you talk a little bit about what it is and give some examples on how you calculate it?

LW: Sure. Simply put, OEE or Overall Equipment Efficiency is a way to measure the efficiency of your equipment or process. It takes some very specific information in, and it produces an outcome in the form of a percentage.

The simplest way to look at OEE or the simplest system is basically you're going to track the number of widgets you made, the number of widgets that were bad, and the maximum number of widgets that a machine can produce over a given period of time, and we're going to base those things in percentages.

Take a machine where the maximum output is 60 widgets per hour, or 60 pieces per hour, and this is the absolute highest achievable rate. Now let's say the last hour you made 37 widgets and of those 37, seven were rejected, so you have 30 widgets or about 50% OEE in this case. That's what OEE would be. OEE would be basically the percentage of the end result compared to the maximum.

I know what everybody's thinking: 50% is underperforming. Maybe. It just depends on the circumstances of how you're operating the machine, what widgets you're trying to make with that machine, and what your process allows. OEE looks at the machine's maximum capacity and gives a percentage based on that.

The company determines the percentages that are acceptable: 50% given certain circumstances may be perfectly acceptable, but what we try to do in OEE is we look at 100% as the machine's 100% capability, not 100% as in a term that this is what you have to have on maximum productivity to be acceptable in the plant. So that's a very basic look at OEE.

PS: One of the things about OEE as a metric, Larry, that always interested me is that you've got this really interesting chance to bridge the operations team and the maintenance team because this metric incorporates both asset health and throughput. Let's say you have measured the OEE on some of your critical assets, the ones that you know would cause the most unplanned downtime if they failed. What now? You've got this number, you've got this percentage. Is this just a KPI to hit that the big managers are asking people to hit, or are there deeper insights that operations and maintenance can draw from OEE?

LW: When you look at the basic tenet of what I described above that's just basically a KPI, you're right there, but let's drill down just a little further in what OEE is and what it can do for us. As we said, it gives us that base information of producible widgets, what we produce and what the maximum of the machine is.

But look at what we can do from there. With just a little bit more information, we can start to analyze the downtime to understand exactly what happens. For instance, by recording the reason why the machine went down – or starved, if we had a feeder system that starved the machine – then we know that the machine itself doesn't have a problem, it's the feeder.

But if we look at downtime as being a maintenance-related item – let's say, improper work on the equipment, or the motor isn't running at optimum speed, or we have a sensor issue or there's something bent or broken – by recording that fact during the process, then we understand why the downtime occurred and how much the downtime costs. Now we take each instance and we measure them individually, but we also accumulate those measurements.

As we accumulate those measurements, we start to build a profile of what the real problem is. So if I had a bent piece in the machine at one time, that piece is fixed, that problem is solved, right? It's a one-time, one problem issue. If I have a motor that's underperforming, that's a longer-term issue that needs to be addressed. It’s an easy thing to address, but that's what our OEE system will provide the details to. What are those complex issues and simple issues that are causing downtime and which one to hit first?

PS: It strikes me too though, that a lot of these teams that we're talking about, especially operations, they're tasked to keep the machine going, to maintain throughput, to maintain quality, and OEE may be another request for management to hit. But what you're talking about here is that OEE is actually a window into how to take an actionable insight, it's not just a number. Based on what the percentage is and the way the machines are linked together, this is a number that's more than just the number of widgets produced that day. It's actually actionable to improve the system.

LW: That's right. You know, whether it be a maintenance task that needs to have a routine schedule put to it, parts that need to be replaced, or the machine has reached its serviceable limit. You know, if I'm only producing 30 widgets out of a machine that was originally designed to produce 60, the machine may have lived its normal life cycle, and I'll either have to accept the 30 widgets out of that machine or I know I need to replace that machine because it's just worn out. In some cases, a machine can be rebuilt or refurbished to get it back to its original state, but in some cases, it's just better to replace that machine. And again, this is what OEE's going to tell you.

Listen to the entire interview

To expand on that a little further and talk about how this helps the customer, as your machine progresses and you're measuring your OEE effectively, you know how many pieces and widgets you're creating each day, how many pieces you can create and what's a fair and acceptable number that you can provide for your customer. Nobody wants to oversell their product, and nobody wants to be put in a position where they can't meet the demands that they promised. These tools and measurements give you the ability to really understand how your machine is operating, what you can reasonably produce, and what you should be charging for those parts and components when you do produce them.

PS: Well, and this is where you and your teams come in with hands-on experience because at some point, operations and maintenance ought to collect the data to calculate OEE. When you and I have talked, you've mentioned that part of what you and Perceptive Controls does is that you help these teams deploy and link the systems together to get this kind of data. So let me ask you, how do people capture the data required to calculate OEE, and do you find that there are efficient ways to share OEE out with the wider teams?

LW: One of the easiest, most simple systems to put in place is a pen and paper, right? Hand your operator a piece of paper and a pen and say, "Hey. Every time the machine breaks down, I want you to write down the time and I want you to write down what happened."

We come in and replace those systems quite frequently, and the reason why is pretty simple. Number one, you didn't hire the operator to be your data management keeper, right? You hired the operator because you need to get widgets out the door. That's what your operator does. Data recording and data entry is really a secondary task that they need to perform.

The other problem that you have is obviously no operator wants to write down something that may make them look bad, or, you know, nobody wants to write down the fact that they got the recipe wrong, right? The records have an element of corruptibility to them. When the operator's busy, the operator is going to take care of those tasks that are necessary to take care of first, the records keeping can be the secondary issue. They come back to the records keeping later, and then they're kind of guessing at what happened at that point instead of giving you a good detail, and they're missing things. Believe it or not, a lot of companies incorporate that, and that's really what we kind of replace in a lot of cases.

A good, effective OEE system uses automation. With most processes, you have a PLC or some kind of internal brain that runs that system. Typically, a very easy implementation of an OEE system will either utilize the PLC information built in it, or implement another device that will read “good part / bad part”. It can also be total parts and rejected parts and just do a mathematical equation against what the total sum of good parts were, and then it takes in a running signal.

From there, we know that the machine is running. We start recording run time at that point. If the machine goes down for any reason, we automatically register that and say, "Okay, the machine went down." If there's information in the PLC that's readily available, it says the machine went down for X, let's say a no rotation fault. We can automatically record that and say, "Okay, it was a no rotation fault. Once the machine goes back into operation, the machine goes into run." Nobody needs to do anything. It's a completely hands-off situation.

In other situations where the operator or somebody had to come in and hit a stop button or actually physically stop the process where the machine doesn't know quite why, what we'll do is we'll bring up basically one block that says, okay, machine went down. It'll list out the categories and say, why did the machine go down? So I'm going to select breakdown.

So from breakdown, it's going to ask me, okay, motor failure, conveyor feed failure, and let's say motor overload are the three reasons why that machine can break down. I choose one of those, and that's it, then the operator is done at that moment. They make two selections in less than 10 seconds, and they are done.

Once the machine goes up and running, the system automatically registers that run command and says we're back in operation and waits for the next downtime element. From there, we capture all that data. We basically put it into a Pareto chart (a list of things from highest to lowest of what caused your problems), whether it be breakdowns or whether it be work breaks. Let's say the machine runs really well and it's just break time and people are taking 25 minutes on break. These things will be registered, these things will be accounted for.

That's really what an OEE system is, It's really simple if it's implemented right. It doesn't ask the operators to do more than what they can do with their tasks currently, and it really gives the end-user good, useful data to then try to solve the problems that cause them rate issues.

PS: You bring up a whole lot of interesting information in that but especially the people element. OEE is useful from a business and work perspective, and one of the nuances that is that when people do first start collecting it, it sounds like it's good to focus on the work itself and not on the people who are operating the machine or fixing it, because really it's a metric which assesses throughput and asset health, not personal performance. As you said, it could be downtime, it could be a break, but this is just a number that's used to measure how the asset is operating.

LW: One of the things that I always try to tell people that I'm working with on the front lines, the operators, these people who are there to produce products for the company, is that if their hearts are in the job that they're doing, this box, this tool will help them to understand what it means to do the job more efficiently.

It's really a good hands-on tool to be better. It's not designed to try to find fault with a particular person, but to find where there are ways to increase productivity and measure the productivity you have now. That way you know reasonably what you can produce in a months' time, a years' time, whatever the metric is.