MES 101 Downtime Tracking

Welcome to our MES 101 series. We are going to cover the basics of a variety of MES components. You will get an overview of what is available in an MES implementation, how to leverage each piece in your process, and how you will get an ROI on the investment.

The first piece of most Manufacturing Execution Systems or  MES implementations is Overall Equipment Effectiveness or OEE. OEE is a favorite key performance indicator (KPI) used to distill process availability, production performance, and overall quality into a single number. Before we dive into OEE, each of these areas deserves some attention.

The easiest of the three to quantify is usually process availability. Process availability is the ratio of how long your process was running to how long it was scheduled to run.

Figure 1: Availability

Simplicity is Clarity

We’re going to keep this simple. Before we into tracking downtime against specific operators, or operations vs. maintenance. First, we are curious to understand what are the top 5 reasons our process goes down, so we can start to address those issues first. Once we get the low hanging fruit then we will dive into the details of optimizing and understanding everything there is to know in the facility. Think of our approach like this:

You have no information right now. Let’s get a piece of information in your hands as quickly as possible, so you can use it to start asking questions. Your questions will help determine the next item of information we need to gather. Thus begins the continuous improvement cycle.

The Bare Necessities

Calculating availability requires two things, the amount of time you plan to operate in a given period and how long your equipment ran during that time. For the sake of argument, let’s say you are planning to run for a single 8-hour shift, with 30 minutes for lunch and two 15 minutes breaks for a total of 7 hours of planned runtime. If you want to keep things as simple as possible, use the maximum amount of time you have per shift or per day, and assume 100% planned runtime1.

Once we have a value for the planned runtime, we need to know if our process is running. Want to keep it simple? Decide on the criteria to answer the following question with a yes/no answer: Is the process running?

Understanding if the process is running will rely on a single piece of equipment in your line. If you have a soda bottling line and the bottling line is not running, then we can consider the process to be down. If it is running, it is up. Let’s throw these conditions in the PLC so we can set up a value for our Downtime Tracker to see a one if we are running, or a 0 if we are down, and track how long it is at 1 or 0.

Now we have a piece of information.

Let’s Start Asking Questions

Awesome! Now we know how long we are running during a given period. Let that run for a couple of shifts and see what the number is. Now we can start asking questions.

The first question will likely be “Ok, we are running 65% of the time, and down for 35% of the time. Where is the 35% coming from?”

Now we get into the first iteration of this process. See how we are getting a 1 or a 0 from the PLC? Why don’t we decide 1 is running, 0 means the machine is generically stopped, and anything higher than 1 is a specific reason the equipment is down. Then when we collect data we can start to group it by the value we get from the PLC, correlate that to a list of reasons, and start to understand what is causing our downtime.

We can start simple and come up with a few reasons. In no particular order, let’s say we have a handful of reasons the machine can be off:

  • E-Stop
  • Overheating
  • General Fault
  • Belt Slippage
  • Over Current
  • Downstream blockage
  • Upstream starvation

Let’s assume we can track these in the PLC, or can set up a way to know when each has occurred, and we will give each reason a unique number and will use 0 for stop:

  1. Stopped
  2. Running
  3. E-Stop
  4. Overheating
  5. General Fault
  6. Belt Slippage
  7. Over Current
  8. Downstream blockage
  9. Upstream starvation

Now when we downtime against these reasons, we can sort by overall duration to generate the top 5 reasons our machine goes down.

From this point, we can continue to add more reasons to understand better why the machine is stopping.

Next Steps

How do you use this information to your advantage?

See the list of top 5 Downtime reasons? Those are the things we need to understand and fix first. Want to figure out your ROI on this work? Estimate your cost per minute of downtime, what it takes to make some adjustments to reduce the downtime, and you can calculate precisely how much money you are saving with the additional production you will gain.

Typically the ROI for downtime tracking will be very quickly. Corso has seen it happen within weeks of implementation especially when in an environment that waste products are extremely expensive, such as Food and Beverage, and various manufacturing environments.

Ready to get started? Email Dave@CorsoSystems.com

Notes

1Regardless of how you break it down, if you are comparing different shifts with the same scheduling system in place, it will all work out the same. The calculations per shift might be off, and your overall downtime would be higher if you stop during lunch breaks and assume 100% planned runtime, but if you ignore the lunch break every shift the comparisons will all work out. Want some more information on this? Check out Joel Spolsky’s excellent post Evidence-Based Scheduling especially the section “Obsessive-compulsive disorder not required”.