When implementing an OEE strategy, the first thing to tackle is the Availability component. Let’s define Availability, then examine how to collect the right data to generate OEE data.

Availability in OEE

Availability is overall uptime vs. your planned production time. If your process ran 100% of the time it was supposed to be running, then your availability would be 100%.

However, downtime events are inevitable in the real world. A machine may have a mechanical problem, be starved for new material, or even get blocked by a jammed up machine downstream. Each of these events will be logged by your process historian, and the OEE Engine used by your SCADA and MES system will sum these up to calculate overall downtime.

Next, you can examine the overall downtime by reason code to learn which downtime events are causing the most issues. Once you know what’s causing the problem, you can prioritize fixing the biggest problems first.

Finding Downtime Reasons

The first step for any OEE implementation is to define when your process or equipment is running. In general this may seem obvious. For example, we know that a mesh belt furnace is running if the belt is moving and the temperature is within a specified range of the setpoint. If the belt stops or the temperature goes outside of the setpoint deadband, we can log this as time that the furnace is not running.

For a first pass at determining Availability, we can use these simple metrics: the furnace is running or it isn’t running. But, while we can calculate the time the furnace was running or how long it wasn’t running, we still won’t know why it wasn’t running.

Real World Availability Example

A bottling line can provide a more complex example. Common in many food and beverage processes, a bottling line takes empty bottles, fills them, then adds caps and labels before sending them off for further processing or packaging. Let’s assume the bottles exit the bottling line, go to a case packer to pack a number of bottles into a box. The boxes are then palletized before they’re sent to customers.

To operate normally, the bottling line has the following requirements:

• Empty bottles are available

• Liquid product is available to fill the bottles

• Caps to seal the bottles are available

• Labels to label the bottles are available

• The case packer is accepting bottles from the bottling line

• The bottling line is processing bottles and filling them

When we consider the bottling line from left to right, we know that we’ll need bottles, caps, labels, and liquid. But even if we have all of those, the line needs to be filling bottles. Likewise, once the bottles are filled they need to go to the case packer (and to get out of the way). These requirements provide a solid foundation for determining several downtime reasons.

Blocked, Starved, Maintenance, Emergency Stop, Planned Downtime, and WTH?

In addition to particular downtime reasons, we can also assign a generalized mode to each machine to give context to the data. In most cases, reasons like Blocked, Starved, Not Running, Emergency Stop, and an overall “catch all” are sufficient. As you gain more insight from your Availability data, you can add more reasons, group them into existing modes, or even add more modes to handle any situation in your process.

To start, if raw material items are missing, we know that the machine is not running because it is lacking a particular raw material item. The machine’s overall mode would be “Starved” because the machine is starved of the material it needs to operate normally.

If the case packer is off (or not running), it will prevent the bottle filler from sending filled bottles (to avoid spilling product onto the floor). In this case, the bottling line will be down because it is Blocked, since it can’t sent its product anywhere. This example gets into the deeper level of granularity we will cover later in this post.

If the machine is not running for any known reasons, we can group these reasons into “Maintenance”. Maintenance reasons include cleaning fill nozzles, removing a jammed bottle, or any other maintenance requirement during a run.

If an operator hits an E-Stop during the run, it is important to track these incidents to understand if there are any safety, procedural, or training issues to address for the people running the machine.

Depending on how you want to track OEE, it can also be important to track planned maintenance. While it isn’t required by standard OEE practices, but is very common to include planned maintenance downtime to gain a full picture of your process.

Finally, if the machine isn’t running and the reason doesn’t fit into any of these buckets we can have a “WTH” mode—generally called “Not Running”—and we can bucket time into it. As you begin to understand root the causes of why equipment is down, you can add reasons and get better analytics about your process.

How to Affect Change With OEE Availability Information

The most common way to use downtime reasons is to group them into a “Top 5 or Top 10 Downtime Reasons” report and use it to prioritize resolutions.

Pareto Analysis is a popular tool for ranking downtime reasons. Though the downtime reasons are most commonly grouped by overall downtime, the analysis can also use occurrence count. Using a Pareto chart like the above example will group the various downtime events into reasons—and rank them in descending order by overall duration. A curved line overlaid on the bar chart shows the overall percentage contribution of each reason code.

Pareto Analysis is used to understand the impact of all of your downtime reasons and generate discussion on how to reduce them.

Downtime reduction ultimately boils down to fixing the raw material supply chain to make sure machines have what they need to run, the preventative maintenance to keep machines running well, and training your staff to work properly and safely. Ultimately, it’s also extremely important to make sure there’s enough demand for your products to run your production lines at full capacity.

OEE Beyond The Equipment Level

As we mentioned in the “Blocked” mode of operation, you will want to consider OEE for individual pieces of equipment, production lines, and even full facilities. While the bottling line example in this post is working in relative isolation, production lines are rarely configured in isolation.

Tracking overall downtime reasons is powerful for equipment, however it won’t give you the full story. If you begin to see the bottling machine is regularly down because the case packer is offline, it will be important to calculate OEE for the entire production line. For the line, you may want to be able to attribute the case packer as the main downtime reason—also known as Key Reason Detection.

For individual pieces of equipment, Key Reason Detection isn’t as relevant, as the machine will generally be down for one reason at a time. But for a full production line, you will want to define how each machine interacts from a downtime perspective. Now, you can prioritize the right reason when the line goes down. Key Reason Detection becomes more useful as you go deeper into your OEE journey, so we will cover it and other factors in more detail in future posts in this series.

If you haven’t already, please be sure to read the first post in our OEE Made Easy series.

The goal of this post was to share how we run through typical OEE implementations. We start with “is it running, or is it not running” then work on the overall culture at your company to encourage thinking through an OEE lens. As you continue to calculate OEE and track downtime, you’ll quickly see how to get more granular data. Corso Systems can help with all of the steps in an OEE journey—along with adding logic to your PLCs and SCADA system to track downtime—and help you achieve a quick ROI on your OEE implementation.

Ready to get started? Schedule a quick intro call with Cody Johnson in sales today, or share the details of your project (and challenges) in via contact form.