I have been chasing OEE and throughput improvements my entire career; it is a way of life in manufacturing.
The first step to enable your operations team to improve OEE, is to provide the data of what the machine is producing.
After you know you are making the highest quality product possible, the next thing to tackle is machine downtime.
The uptime of a machine is generally captured by the production team, but more important than how long the machine was down is to know why the machine was down.
To find the why, companies will adopt a diverse methods of downtime tracking.
A few examples are as follows:
- A fully automated system that pulls each fault code from the equipment’s PLC into a data base.
- A manual process where operators mark each fault with tic marks on a sheet of paper
- An export of the HMI’s alarm history into Excel for analysis.
I had the opportunity to use a very creative method of downtime tracking thanks to Covid-19 preventing me from being able to monitor a machine that was being built oversees.
I loaded a laptop with some data collection and remote desktop software and used it to help my organization in deciding on when the machine was ready to ship.
Faults versus Warnings
Faults are generally defined as alarms that stop the machine, whereas warnings are informational only to prompt an operator to act prior to a fault.
With warnings, if there is no action that can be taken by the operator, it does not belong in an alarm banner or report.
An important step when implementing a downtime program is to clean up the data and remove any nuisance faults and unnecessary warnings.
If this is not done, operators are desensitized to alarm messages and will ignore them completely.
Not all Faults are Created Equal
It is very important to capture the first fault that shut down the machine and ignore any secondary faults.
This provides clean data that paints an actual picture of the root cause of the downtime.
For example, a servo motor might not reach its set point position in the allotted time for the cycle and then the station might time out followed by doors being opened from the operator.
I have seen many OEM’s not capture the first fault effectively, leading the facility to chase ghosts or question the data.
Another misconception is that you can automatically capture each downtime event and know exactly what happened.
Operators get good at anticipating common issues and might open a door before a jam occurs, thus the only downtime code captured is a door opened.
It is important to have an avenue for operators to report out root causes of their interventions to catch these issues.
It is all about Action
When adopting a downtime collection system do not bite off more than you can chew in the beginning.
The goal is to start chipping away at the biggest issues, resulting in the biggest uptime and throughput gains.
In the beginning, set criteria to determine the minimum time of a downtime event that you would like to capture, for example, five minutes.
Only report out stops that last five minutes; this time threshold can be configurable from an HMI or SCADA system as the downtime events decrease in length.
There is also merit in capturing items that may not have long durations but occur frequently and add up to a large chunk of throughput loss.
The continuous improvement team can then tackle the issues one by one, starting at the highest downtime and/or highest number of occurrences.
A quick way to start reducing alarm durations is to insure every displayed alarm has enough information to tell the operator where to go to address such as a tag name that corresponds to the device that the stop is associated with.
In part two, there will be tips and tricks on how to accomplish effective downtime tracking in practice via your PLC and SCADA/HMI system.
Written by Alicia Lomas
Project Manager, Automation Engineer, and Freelance Blogger
- Automated Downtime Tracking the Right Way, Part 1 - July 14, 2020
- Control System Architecture for Preventive and Predictive Maintenance - February 12, 2020
- Converting Equipment from PC-Based to PLC-Based Control - December 10, 2019