Frequency band alarms (Image courtesy of EASA)
Setting alarm limits and adjusting the alarm structure will help stave off inadequacies.
EASA

Many maintenance teams and service centers rely on vibration-based machine condition monitoring programs to maximize uptime and control maintenance costs. This places some of the responsibility for predicting machine failures on personnel who may be managing vibration data for hundreds of machines, sometimes in multiple facilities. Given the complexity of vibration data (amplitude, frequency and phase), the task can be daunting.

With the sheer volume of raw vibration data, it is impractical to properly analyze every routine collection event on every machine. Even simple, four-bearing machines have three to 12 measurement points, each with spectra and waveform data—sometimes with multiple parameters like velocity, acceleration and special bearing band parameters. There are software tools that can screen routinely collected data and spot machines that likely have developing faults. Valuable analysis time can focus on identifying which need repair to avoid more damage, downtime or safety issues. The problem is how to use those tools effectively.

Image 1. Frequency band alarms Image 1. Frequency band alarms (Image courtesy of EASA)

Screening for high overall vibration levels might seem like a logical first step. But overall vibration alarms will miss many emerging faults, because acceptable vibration levels from imbalance and flow turbulence on pumps and fans and background vibration often will mask low amplitude vibration from bearings and other critical components. By the time the fault becomes evident in overall vibration levels, it is far advanced, or failure has already occurred.

Detailed Screening Techniques

Among several more detailed techniques for screening vibration data, frequency band alarms and enveloping are the most common. There are also rules-based “intelligent” algorithms that can screen for known fault patterns. Maintenance professionals responsible for the success of vibration-based condition monitoring programs should thoroughly understand these data screening techniques.

Each of the following screening techniques employs proprietary computer software integrated with a vibration spectrum analyzer or a data collector instrument. Such systems are available, and data filtering and analysis techniques vary among them.

Band Alarms

Certain vibration frequencies (relative to the machine rotating speed) relate to specific groups of machine faults—for example, rotor mass imbalance will cause 1x rpm vibration in the radial directions. For that reason, it makes sense to allow the software to scan the data collected for a group of machines and trigger an alarm if the 1x rpm vibration exceeds expected levels. Shaft (coupling) misalignment is known to cause vibration at 1x, 2x and 3x rpm.

That band of frequencies should also be evaluated. Other frequency bands associated with various faults typical of some specific machine can also be targeted to trigger alarms.

Since a vibration spectrum is stored in the computer database as a sequence of amplitude values at specific frequencies, it is a trivial task for a computer to add up the amplitudes in any frequency bands (actually it is a root mean square [rms] sum) and compare the total to an alarm value.

Alarms can be set for each frequency band, which means low amplitude vibration from an early rolling element bearing fault could trigger an alarm, even if the vibration at 1x rpm was much higher. The amplitude at which to set alarm levels is a topic for another article, but for machine faults relative to shaft speed, it is important to set up frequency bands based on orders (1x rpm, 2x rpm, etc.), especially when machine speed may vary.

If bands are based on fixed frequencies (cycles per minute [CPM] or hertz [Hz]), changes in machine speed will cause the frequency of the fault to drift out of its proper band. When orders are used, accurate machine speed must be determined at the time the data is collected.

Enveloping or Spectra Alarms

An alternate technique is to allow the software to build an alarm envelope based on a spectrum or some average of a group of spectra. Rather than defining the alarm envelope in terms of discrete frequency bands, this technique essentially forms an arrangement of narrow bands based on a reference spectrum that has been recorded for a measurement. In the simplest implementation, the reference spectrum is the baseline spectrum collected at the initiation of a condition monitoring program. When a machine is repaired, replaced or operational conditions change, a new reference spectrum would be specified.

Most software that implements envelope alarms can calculate the reference spectrum as an average from a group of spectra. The group could simply be all the measurement points on one machine, all the measurement points on a group of machines, all the horizontal measurement points on a group of machines, and so forth. The group could also be the data collected for a single point over some time span, or a combination of measurement points and time span.

The tolerance for how far above the spectrum the alarm is set can be based on absolute value or a percentage. Tolerances are also set for the bandwidths. Envelope alarms are sensitive to speed, so if machine speed variation may occur, the spectra must be set up on an orders basis. And, machine speed must be recorded accurately when orders are used.

Rule Based ‘Intelligent’ Alarms

Machine faults don’t pay attention to what a software program thinks they should do. Neither band alarms nor envelope alarms will be right all the time (70 percent is a good success rate). Experienced analysts also know the common causes of variation in vibration from certain machine faults and use that knowledge when analyzing vibration data. That knowledge can be somewhat reduced to a set of rules for when and how to interpret vibration spectra data.

Some condition monitoring software vendors provide rules-based (a.k.a. knowledge-based) algorithms that assess the vibration spectra data. The accuracy is highly dependent on the breadth and depth of the experience of the person writing the rules. A good vibration analyst will always make sure she or he understands the machine configuration and mounting before attempting to analyze its spectra data. Likewise, a good measure of the accuracy of a rules-based system is the amount of machine configuration and mounting data it requests or requires.

Trending

Vibration amplitude alarms created by any of these techniques can be implemented using the baseline data collected for a monitoring program and reset when a machine is repaired or replaced, or if operating conditions change. However, condition monitoring software will also store historical data, making it possible to design alarms that reflect the time-based trend of vibration amplitude for any alarm. So, a machine with an increasing vibration trend that typically runs smoother than a sister machine with a higher, but steady, vibration amplitude can alarm at a lower level. Trending is a powerful tool for building effective vibration alarms.

Conclusion

The alarm techniques presented here can be configured to be effective on a wide range of machinery. But such an alarm may not be effective on a machine that is configured or mounted differently. Machines subject to variable operating conditions are particularly difficult to accommodate with a simple alarm scheme. For machines that have vibration characteristics that vary with operational conditions, it may be necessary to define a single machine as several different machines, each with its own alarm scheme. Of course, data must then be collected in coordination with the machine operating condition.

Determining machinery condition from vibration data is complex. Software provides tools that help the process, but no alarm structure will catch all failures, and all will trigger some false alarms. Developing and maintaining an alarm structure will result in a condition monitoring program that minimizes repair and maintenance while maximizing uptime.