Provide Details Regarding Failure Events to Help Augury Improve
Machines talk, we listen. But sometimes we’re speaking different languages.
Not every type of failure mode a machine experiences will manifest itself in our data sets. These are some of the most common reasons Augury may not see evidence of a failure in the data:
- The failed component doesn’t rotate or impact the rotating components. It doesn’t generate any vibration or impact the vibration signature of the components which do. Pump mechanical seals are an example. In some cases, motor electrical short circuits are as well.
- The component rotates too slowly. At very low frequencies, the signal-to-noise ratio becomes too great for accelerometers to be effective.
- The bearing or component which failed did not have an Endpoint installed on it or the Endpoint was not installed in the optimal location.
- The machine regularly changes operational states during the sample recording time. If the machine changes speeds or reverses direction while the sample is being collected, the sample will likely not be useful for analysis.
- The failure mode passes through the entire P-F curve within minutes or less than an hour. An example might be a shaft or coupling which shears due to a sudden product jam or a pump impeller which is destroyed by a foreign object passing through it.
Let’s double-click on a couple of these for clarity.
When a mechanical seal fails, product and/or seal cooling water may enter the bearings. This will quickly wash away the lubrication and may cause the bearings to fail very fast. If an hourly session is captured before they fail, we will see it in our data, but that is a downstream impact of the seal failing. Though we can alert you to some conditions which may cause a seal to fail, such as misalignment, it’s unlikely we can tell you proactively the seal is going to fail. Similarly, when a motor short circuits, the insulation may break down slowly and result in elevated temperatures or changes to the electrically related vibrations, but often there will be no evidence in the data.
In other failure cases, there are changes in the data and it’s possible we missed them or we saw them but didn’t alert you in time to avoid it. In all cases of a machine failure, we are eager to investigate and understand if there is something we could have done better or something we may be able to do better in the future. To that end, it is super important that failures are reported with as many details as possible:
- Which component failed? (motor, gearbox, fan bearing, pump, coupling, belt, etc).
- Why did it fail? If you have all the “five whys” answered we’d love to hear them, but even if it’s just one, it's helpful. Don't just say the motor failed. Let us know if it was an electrical failure or a bearing failure if you know. Lubrication problems, product jams, seal failures, foreign objects, and failed meg-ohm tests, are all good examples. These first two questions tell us what data set to scour.
- When did it fail? This will tell us the time frame to look at.
- What stopped the machine? We want to establish if the machine actually failed or was about to fail, as opposed to a fault condition that was discovered proactively with another predictive technology. Sometimes knowing how the machine stopped gives us clues as to which datasets we should view. For example, if a motor’s breaker tripped or the fuse blew, an electrical issue is suspected. Whereas if the motor overload protection tripped, the motor bearings may have been the cause.
- What was the impact on your organization and how do you feel about it? Did you expect us to catch this failure mode? We want to be sure expectations are always properly aligned and when we know an event was particularly painful for you, we will prioritize it. Similarly, if you feel like there was nothing any of us could have done to prevent something, we will still look into it, but we won’t waste resources that could be focused on more important issues.
- Any maintenance and repair actions. Sometimes maintenance results in unexpected adverse consequences. Knowing what was performed helps us to understand any changes in the data.
It’s important to keep in mind that Augury never causes machines to fail. Each year at a given facility a number of machines are going to fail and we aim to extend their life by helping you identify and eliminate the root causes of failure as well as warn you when we see a component is beginning to fail. Unfortunately, we can’t predict everything and you can’t prevent everything. But even in those cases where machines fail unexpectedly, we hope that the data in our platform and our Reliability experts can help you understand the root cause and avoid it in the future. Further, we aim to constantly improve our products and services to cover more failure modes, whether it is low rpm components or fast-developing failures. Your partnership and willingness to share information is critical to our ability to improve.