Why Fast Fourier Transforms are Not the Answer to All Your Problems

Using Fast Fourier Transforms (FFT) of vibration to identify root failure causes. FFTs and ML are both powerful tools and can enable significant insight – in the right context.

When we meet customers in the Industrial Internet of Things (IIoT) space, we encounter a solution concept which is at best wishful thinking and at worst fundamentally flawed for industrial applications. This flawed concept claims to identify all mechanical failure modes from a single sensor source, in real-time.

The idea uses Fast Fourier Transforms (FFT) of vibration to identify root failure causes on rotating machinery.

To be clear, we love FFTs. The FFT, as an algorithm, is fundamentally sound. Lone Star’s people know a great deal about signal processing (not just FFTs) and hold several patents on those topics.

What we don’t trust is the one-algorithm-to-rule-them-all wonder drug that is being sold.

Background on FFTs Applied to Rotating Machinery

FFTs, at a high level, convert a time-based signal into a frequency-domain for more efficient manipulation. As a mathematical concept its roots go back to Gauss and Fourier himself, but the most commonly used implementations were developed by Cooley and Tukey in the 1960s. FFTs have proved invaluable in signal processing and data compression as computation has become cheaper, smaller and faster.

The core concept of FFTs is that any signal can be broken down into a combination of sinewaves which are easier to manipulate for certain applications. This is especially beneficial when a signal can have interesting phenomena in a bounded range of frequencies.

For rotating machinery, different failure mechanisms are usually represented as a multiple of synchronous RPMs – i.e. 1 x RPM for imbalance, 1 x RPM and 2 x RPM for bent shaft. There can be significant overlap in failure frequencies however, which can make distilling a single failure mode difficult.

The Optimists View of Vibration as a Panacea

The application of FFTs to rotating machinery stems from the following thesis (our paraphrase): a vibration signal of rotating machinery can be decomposed using FFT to diagnose oncoming failure by identifying frequency spectrums associated with root cause mechanisms.

Vibration as the signal source has a few defining advantages. It encompasses many failure mechanisms. It is captured with a non-invasive, non-destructive sensor which can be installed in brownfield deployments. In the past, vibration analysis has been relegated to periodic diagnosis over the life of an asset, but sensors with built-in FFT and improving data infrastructure have opened the possibility of real-time diagnosis.

These properties theoretically fit very well with an Artificial Intelligence / Machine Learning (AI/ML) approach – a combination we have seen enormous buzz around.

However, for this to work, the idea relies on the following conditions to all be true:

• If vibration encompasses all failure mechanisms AND
• If the frequency spectrum(s) for failures are known from historical training data AND
• If the model is sufficiently robust to changes in the operating environment AND
• If a trained model can execute in close to real-time

If these conditions align, then we can know everything about the asset from a single data source. Right!?

The Problem(s)

Where to begin.

First, some inherent limitations of FFTs. The signal being monitored must be stationary for FFT to be applicable. If the signal is shifting, you will have problems. If the failure modes (or better yet the root causes of failure) manifest in chaotic or pulsed signals, you are going to have still more problems. FFTs are NOT well suited for dynamic conditions — we hope your problems are nice and stable.

Second, some practical implementation concerns. When processing signal data, the polling frequency should be determined by the Nyquist rate – twice the highest frequency you are trying to process. Under practical applications for rotating machinery, this typically works out to between 1-40 kHz. Not only does this drive sensor requirements, but the data storage and bandwidth implications must be considered. If you are trying to backhaul data to the cloud before processing, these data infrastructure issues are only exacerbated.

This second concern can be mitigated by careful selection of a vibration sensor, and by on-board FFT processing in the sensor. But even this won’t handle transport and cloud processing delays.

And, even if all the Nyquist and temporal problems can be handled, a pesky fact remains; a detectable vibration signature usually indicates a failure in progress. It’s NOT a way to AVOID failures.

A third concern is proper fault identification. In the past, these failure modes have been identified by academic and theoretical research with most driven by “laboratory scale tests and numerical simulations” which “cannot replicate the environmental effects to which real structures are subjected to.^”

Textbook guidelines for faults start to match less and less when multiple failure mechanisms occur at one time. Or, when unexpected shocks to the system are experienced. Or, when an asset is abnormally used in service. But, wait, is a real system ever NOT in one of these states?

Which, at last, leads to the unholy marriage with AI/ML. The concept is simple – feed in all your past failure data and the algorithm will learn what failure looks like. But which failure? On which asset? In what context? Do I need every combination? Do I need multiple samples of each failure type to produce a significant training set? What if I don’t have data?

The overarching answer is AI/ML-bound organizations are the proverbial hammer and industrial applications, rotating machinery included, are being told they are a nail. We see AI/ML organizations publicly touting 50% success rates of failure prediction on IIoT projects – is a coin flip really the bar to measure success against?

A Path Forward — or – What’s Wrong with Physics?

Our pessimism – and hopefulness – can hopefully be explained with an anecdote.

We recently engaged with a potential customer who had been sold on a vibration-centric predictive maintenance program for diesel motors. We asked if any other sensors were available for cross-referencing, they had a spec sheet with 300 other sensors.

Three hundred sensors the other solution was ignoring! Temperatures, pressures, voltages, currents – all cast aside. And we had to ask, “What’s wrong with physics?”

It is increasingly rare for industrial equipment to have zero inherent sensor capability. And, we’re also seeing big pushes to capture data in local or cloud historians. Ignoring this is a huge opportunity lost.

Instead of reinventing the relationships which govern the operation and failure of components, why don’t we use some of the same physics and engineering principles which govern its design? The relationship between current and RPM in an electric motor is a stable, known fact – we don’t need thousands of hours of training data to re-learn an equation well over 100 years old. The cumulative experience of engineers, operators, and maintainers is priceless. Far more valuable than what an AI can learn in the next decade or so.

This is not to say that FFTs (and even machine learning) are irredeemable. Lone Star uses them both to enhance fundamental cause and effect models. They are both powerful tools and can enable significant insight – in the right context.

• Instead of solely relying on FFTs, we would suggest using FFTs to corroborate more granular sensors – if two independent methods are both pointing towards the same failure outcome, the likelihood of a true-positive prediction is greatly increased.
• Instead of relying on AI/ML to encompass all failure modes and all installations in one algorithm, focus your AI/ML around learning what normal and abnormal looks like for a specific component only on the installation in question.

Real-time condition-based maintenance can unlock enormous value – using a more holistic, balanced approach moves the prospect closer to reality and away from an over-hyped sales pitch.