PdM vs. Troubleshooting

The first and probably most important stumbling block many PdM programs have faced is the simple lack of understanding the difference between using a technology such as vibration analysis in the context of a PdM program versus using it for troubleshooting.  Both are valid uses for the tools and technology, but it is only the PdM approach that results in large and long-term ROI.  In PdM, the goal is to monitor a large population of assets in a repeatable fashion over a long period of time, thus trending the data and monitoring changes in machine health to minimize the cost of maintaining that equipment and reduce the amount of downtime, especially unplanned downtime.  This methodology provides information about the condition of the plant’s assets, allows for reducing planned downtimes and eliminating unplanned outages, while enabling just-in-time parts delivery and more efficient repair cycles.  If performed correctly, PdM will change the way the plant approaches maintenance.

Troubleshooting is simply the process of using technology to confirm a known problem or to gain a deeper understanding of the cause of the problem.  For example, perhaps a motor pump set is making a screeching noise and we want to know if it is coming from a pump bearing or from a motor bearing.  We can use vibration analysis or perhaps Infrared Thermography to make the determination and overhaul the correct part of the machine.  This is a valid use of the technology but it will not transform maintenance practices, nor will it make a big difference in overall profitability.  In this case, we already knew we had a problem.  The technology was simply giving us more specific information about the source of the problem.  PdM, on the other hand, should include a paradigm shift and provide a huge payback on investment, if it is performed correctly.

Doing PdM Right

In order to run a successful PdM program, which means a program based on trending, one needs to spend some time defining how the assets will be tested in a repeatable and consistent fashion.  From a technical standpoint, we are saying that if we hold all variables constant (test speed, test load, test location, sensor mounting, test setup etc.) and notice a change in vibration (or other PdM technology variable) then we can definitively say that the machine has a problem.  Typically we can also tell the severity of the problem and its source, especially as the fault evolves over time.  Once a problem is identified, we can increase the test frequency and monitor changes in the severity of the problem (i.e. changes in the data) until it is time to make a repair recommendation.

If you take a moment to consider this in light of how we are using the technology today, or in light of the skills of the person running our program or in light of the type of training courses we sent our resident expert to, we might notice some inconsistencies that may point right to the root of the reason why our program is not as successful as it should be.  Let’s take a step back.  In order to do PdM right, the particular asset should be tested in exactly the same way, every time, month to month, quarter to quarter, and year to year and then simply look for changes in the data.  In this context, changes in the data will indicate a fault or problem with the asset.  Based on this, where does it seem that most effort needs to lie?  In understanding all of the different aspects and options and test types supported by our data collector, or in defining standard test procedures for each of our assets?  In standing by the machine taking ten different tests and moving the sensor around like a stethoscope, or in making sure a technician knows exactly where to place the sensor on each asset and exactly how to line the asset up for a standard test?  In spending hours pouring over graphs trying to read squiggly lines like tea leaves, or in simply comparing a new set of data to a well-developed baseline and looking for obvious changes?  In taking courses in dynamics and the nuts and bolts of vibration analysis, or in taking courses in PdM program management and working at improving general organizational skills?  In hiring the hotshot analyst troubleshooter guy, or in hiring someone who is well organized, dependable and able to write out procedures and follow them?

It may seem counterintuitive, and perhaps this is why so many PdM programs have failed over the years, but a successful program is the result of following a standard set of procedures and remaining consistent year after year, not in being an expert at looking at graphs.  Yet in the industry, we often see people taking certification courses that teach a lot about looking at graphs and little or nothing about managing a PdM program.  Or we get training from an equipment vendor that focuses on data collector and software features rather than program management.  Then we wonder why we are not getting the results we should be getting. 

Some Tips on Methodology

In order to run a successful PdM program, each asset should be tested in the same way each time.  Assets need to be tracked to make sure it is the same as before (i.e. perhaps someone replaced a pump with a similar one made by a different manufacturer...we need to know this) and a good set of baselines or meaningful alarm limits must be developed.  In order to evolve from PdM to Proactive Maintenance, root cause failure analysis must be performed to understand how some machines deteriorate, wear out and fail in comparison to other similar machines.  This allows the purchase of equipment appropriate for the application.  All of these items require keeping good records over time, in a consistent way, and looking at trends.

Repeatable Test Conditions — Regarding test conditions, each asset must be tested the same way each time.  Any significant (say 10 percent or more) change in speed or load will change the vibration produced by the machine.  In PdM, the idea is that a change in the vibration means there is a change in machine condition.  We can’t make this call if the speed and load are not consistent during a test and from test to test, year in and year out.  Therefore, it is quite important to understand the asset we are testing, how it is used in the plant and how plant processes affect its speed and load.  Only then can we attempt to define a repeatable test condition.  Once this is accomplished, it must be documented and the people testing the machine must be made aware of this documentation and the importance of following it.  It should be noted that many machines may need to be tested off-line or under artificial circumstances; valves may need to be aligned to keep compressors loaded or fan dampers in a steady position.  In some cases, nearby machines must be secured in order to separate their vibration from the machine being tested.

However test conditions are defined, they must be documented in such a way that the assets are tested the same way every time, year after year after year, no matter who is actually testing them.

Repeatable Test Locations — Although it is important to place a sensor on the machine in an appropriate position, it is more important to always place the sensor in the same position, test after test, year after year.  For this reason, the use of sensor mounting pads is highly recommended – for either magnet mount sensors or screw type sensors – to ensure the sensor is always placed in the same spot on the machine.  These test locations must also be documented so that in five years, if the test pad falls off or the machine is overhauled and the test point is removed or a new person comes to the plant to take over data collection duties, there is no question as to where to place the new test pad.

Consistent Test Types — Regarding test setups, test types and data analysis; these should also be kept constant.  It is not up to the analyst to go out each time and test the machine or asset according to his mood that day or according to what particular fault he is looking for.  Special tests may be appropriate, but this is troubleshooting, not PdM, and it does not have the same financial implications as PdM.  It should also be noted that if PdM is done correctly, there should be little need for troubleshooting.  Good, consistent data collection and trending should give you enough information about machine condition that you won’t have to troubleshoot.

Understand the best general way to test each asset, with help from an outside consultant if necessary, and stick to that setup.  Document this in your software or database (and use software that facilitates this and has a database).  When reviewing actual data, do it in a standard manner as well.  Use the same graph scaling each time and overlay the baseline or alarm criteria.  Train yourself to always look at data in the same way, compared to the same criteria, and the actual analysis part of the process will become insignificant in comparison to the other necessary ingredients of running a successful program.

It May Not Be Sexy... But It Works

You don’t need to be a CAT IV certified vibration analyst to draw a stick figure of a machine on a piece of paper indicating where to replace the sensor mounting pad when it falls off and where to affix the sensor when testing.  You don’t need to be a novelist to make a note on the stick figure saying that this pump must be placed on recirc at 60 psi before testing, or the valve on this compressor must be opened to keep it fully loaded throughout the test.  You don’t need a high-tech analyzer with a million features to collect a standard reading.  You don’t need to be a rocket scientist to write down the nameplate information for your assets to make sure one machine wasn’t replaced with a different one without your knowledge.  However, the fact is that these simple and mostly nontechnical steps are the most important features of a successful PdM program.

Although these tasks are not particularly difficult, it can’t hurt to find a good partner to help define the test points, test types, test conditions and set up your database for you.  A good partner will be able to return to your plant on a yearly basis to review the program and verify that new equipment is set up correctly, that test points on the machines match test points defined in the database, that baselines are appropriate and that your fault reports and repair recommendations are correct.

Based on the information presented in this article, it should be clear that a good partner is not the vibration expert guy who is going to come take 100 tests and troubleshoot a single piece of machinery for you.  Rather, it is a company with a long history of managing PdM programs that will focus on helping you set up the proper test and analysis procedures and will help you train your staff on following these procedures.  In many cases, you might find it cost-effective to let these companies continue to manage your program or to remotely analyze data that you collect.  Whatever you decide, just note that consistency is the key to success and methodology is more important than analysis prowess!
 
Azima DLI’s Tom Francisco, PE, CMRP, has more than 20 years of machine condition monitoring experience with expertise in vibration analysis, infrared thermography, motor and battery testing and oil analysis. Azima DLI (www.azimadli.com) is the leader and premier provider of predictive machine condition monitoring and analysis services. Francisco, a licensed professional engineer, has been with Azima DLI since 1995 and conducts all phases of client training in the use of Azima DLI vibration monitoring systems as well as in-house training to other Azima DLI engineers and technical personnel. Previously, he worked as a nuclear-qualified machinist mate on the USS Enterprise, an engineering technician, a mechanical engineer and a senior systems engineer.