The race to Machine Learning (ML) and Artificial Intelligence (AI) for electric machines has primarily focused on the spectral features of those units. As more academic papers are published, though, the focus is taking us further into advanced topics. Those topics are typically related to areas that don’t necessarily represent most faults, such as rotor bars, or where robust analysis has already been performed, such as vibration and bearings.
In the mad rush to produce more Ph.D-level research, and the resulting mass number of promised devices, few have focused on the raw data provided by machines and controls. Could we use periodic sampling of voltage, current, watts, temperature, power factor, ambient temperature, and other raw data, to not only identify degradation, but to also determine the Remaining Useful Life (RUL) of an electric motor? The answer is a resounding “yes.”
To achieve sampling rates necessary to perform spectral analysis and related evaluations, a Data Acquisition (DAQ) device must be able to sample at twice the rate of the frequency in which we are interested (Nyquist). For example, if we wish to detect a specific frequency for static eccentricity with vibration, and we have a machine operating at 1800 rpm (30 Hz) with 61 rotor bars, then we need to have (30Hz*60RB*2) = 3600 samples per second. If we want to read 2x, 3x, or 4x that value for early rotor-defect detection, then we would have to be at 14,400 samples per second, plus room for sidebands, putting us at 15,000 samples per second for a spectra out to 7500 Hz (450kCPM). The data-collection time per sample would also have to be extended, if we wish to have a resolution that will identify anything of worth. (Note: If useful information is to be gathered, there also must be a minimum load on the equipment.)
In the end, to produce something that will detect early failures, we would need a rather expensive DAQ device and associated processing software. Inexpensive continuous monitoring devices for electric motors often provide a lower sampling frequency and only trend later-stage failures with a short time of detection to failure, depending on the technology in use. While we are producing actual findings, i.e., bearing fault, rotor fault, etc., the corrective actions are usually similar: remove and replace, repair, or other. On the other hand, if used properly, a good continuous-monitoring system of this type can be used to provide the information necessary to make changes to the system that improve reliability. This normally requires sampling rates of over 10,000 per second, when looking at Electrical Signature Analysis (ESA) systems.
A vast majority of electric motors are of medium to low criticality or relatively inexpensive, thus making the cost of implementing spectral techniques a barrier to implementation. Conversely, some historian systems gather raw data from many non-critical motors and other sensors associated with the driven equipment, but at a rate measured in seconds, minutes or hours. They often feature little more than limits shown by green, yellow, and red indicators that trigger an investigation or other action, after the fact (much like an automobile’s “check engine’” indicator). When something is triggered, experienced experts are brought in to review data and perform testing to identify the cause of the alert, or the motor is simply replaced.
Most ML/AI programs for commercial/industrial machinery are “supervised” learning systems. In such systems, patterns associated with known faults are fed into a variety of algorithms (see links to two previous articles on machine learning below). To verify that features of the data are properly selected, the developers must work with human experts who can identify which data has value and which are not useful, as well as what the peaks mean. In turn, most ML/AI systems are performing the same functions that humans would perform following vehicle “check engine” alerts or if they had collected data and were analyzing it. Once they’re programmed, you have complex, expert, pattern-recognition systems that are looking for similar patterns identified by the human expert(s) involved with the developers.
DEVELOPING RAW-DATA ML SYSTEMS
With raw data, we can: 1) perform a generic fault detection, or classification, and narrow down troubleshooting times; or 2) use set limits and deviations from the expected norm to perform Time to Failure Estimation (TTFE), which is commonly referred to in the ML community as “RUL.” To do this, we have developed a few processes to evaluate anything from standard operating machines to machine tools to variable-frequency-drive-controlled systems.
The resulting programs can be used in servers or computers carrying the language libraries that developed the systems, such as MatLab, Python, R, or any number of others. This has provided the ability to detect degrading electric machines and project RUL times weeks in advance.
The process we follow for the development of raw-data ML systems is as follows:
1. Identify the application and related components.
2. Identify the available data and how frequently they are gathered and stored, as well as how they are gathered. Some systems will process data to reduce memory by assuming test data if it has not changed. That can be acceptable as long as the developer understands how the data is being managed.
3. Identify the limits that are set. There are generic ones, and then there are those where someone has determined what they consider failure, and whether it is related to high vibration, temperature, current unbalance, etc. This is crucial when it comes to knowing which data are valuable and otherwise, e., where the value of some sets of data is yet to be determined.
4. Identify what potential additional information could be available. This would involve a review of the historian information that is gathered and available. Are there any examples and related data sets of failures that have occurred, or is the system a new one in which no historical data has been gathered?
5. Identify whether internal IT systems manage the development language and resulting algorithms or will managing the system require outsourcing to a cloud-based platform. This will involve decisions related to data security, cybersecurity, and data ownership.
6. Use a sample of data that has been identified as being available to look at how it works over time. Many of the development tools will have the ability and built-in applications to assist in performing these studies. This is especially important when deciding which data sets will be useful to the classification and RUL systems that can be developed.
7. Use the previously collected information to develop a logic tree for how decisions will be made and what is expected. This provides a roadmap for the development effort and can be used to determine if other parts of the system can be evaluated as part of the ML/AI allowing the motor to also be used as a sensor for the rest of the system.
8. We like to develop the classification and RUL systems separately (see below) and run them in parallel. This provides the capability for the earliest detection of problems.
a. Develop the classification process and test several types of algorithms using training data
and fault codes.
b. Develop the RUL based upon what is the expected normal and what is related to change
toward the set limits.
9. Test, train, retrain.
10. Implement and perform continuous updates to the fault library as they occur.
COMING UP
In future articles, we will walk through the development of an ML system to evaluate the condition (electrically and mechanically) of a generic 100kW, 1800-rpm, 460V electric motor based on voltage, current, watts, power factor, ambient temperature, RTDs, and overall vibration. The historian tags are identified, and the limits are set as follows: 40 C ambient, 105 C temperature rise, 145 C total temperature limit, 8% current unbalance, 2% voltage unbalance, 115% load limit, 0.85 power factor limit, and 3 mils vibration. During the evaluation, an additional data point, I2t (thermal capacity) is found as being available. A review of the manufacturer’s website identifies the thermal curves for the motor, which are primarily mapped to speed. Overall, this is quite a bit of information. And we can choose what is useful.TRR
Click The Following Links To Read The Author’s Articles On
“Concepts In Machine Learning (ML) With Electrical Signature Analysis (ESA)”
ABOUT THE AUTHOR
Howard Penrose, Ph.D., CMRP, is Founder and President of Motor Doc LLC, Lombard, IL and, among other things, a Past Chair of the Society for Reliability and Maintenance Professionals, Atlanta (smrp.org). Email him at [email protected], or [email protected], and/or visit motordoc.com.
Tags: reliability, availability, maintenance, RAM, electrical systems, electric motors, generators, machine learning, ML, artificial intelligence, AI, Electrical Signature Analysis, ESA, Motor Signature Current Analysis, MCSA, predictive maintenance, PdM, preventive maintenance, PM
