Crack the Code on Lube Faults, Failures
Ken Bannister | September 21, 2017
Detecting and trending these occurrences can help boost asset reliability.
One of the most powerful yet misunderstood and underused tools in many asset-management-software programs seems to be the fault- or failure-diagnosis section. That’s surprising, given the fact this feature is specifically designed to help users identify and classify asset or system faults or failures.
Fault and failure occurrences are identified by a set of user-defined codes noted on a work order upon completion of the task and linked to the work order on closing. These codes are then used to collectively group fault/failure occurrences to analyze and understand the specifics of these events and the rates of failure for individual or groups of assets. Knowledge gleaned through data analytics and reporting on the type and number of occurrences allows a planner or reliability technician/engineer to assess the validity of a site’s reliability and preventive-maintenance programs and machine setups.
For example, evidence of lubricant leeching past a bearing seal would be indicative of “excess lubrication” (a popular lubrication fault/failure code). In such a case, if the bearing(s) were manually lubricated, a first assumption might be that the grease-gun operator had pumped too much lubricant through the bearing. Assuming operator training wasn’t the issue, investigating the objectivity of the work-order’s job-plan instruction and/or checking to ensure the displacement per shot of the grease gun(s) in use matched the calculated bearing requirement would be necessary. Another check would be required to ascertain if the lubrication-PM frequency was too short and needed to be lengthened. If the bearing(s) were lubricated through a centralized automated system and showed signs of over-greasing, as depicted in the photo on p. 38, we could immediately assume a lubrication-system setup adjustment was in order.
Code setup: symptom or cause
Depending on your site’s asset-management-software, you could already have a pre-built fault/failure section ready to populate, or you might have to set up your own with available spare search fields. Pre-packaged systems may label this section as “Fault Codes” or “Failure Codes” and will usually offer from one to four pre-titled search-field filters. You may recognize these search-field titles as Fault, Failure, Cause, Effect, Remedy, or Corrective Action. Forward-thinking software packages may also offer a Symptom search field (sometimes referred to as a Problem code).
Regardless of their titles, the search fields all fulfill the same data-filter capability. They all will contain drop-down menu boxes that have been pre-populated with codes (any of which can be deleted or changed if unsuitable) and/or allow site personnel to populate them with customized user codes. Most software packages also allow users to rename search fields if they haven’t previously been used or linked to other sections of the database. Once familiar with the fault/failure section, users must decide on the number of search filters required, their title name, and intent.
Whenever maintainers troubleshoot problematic or failed assets, they are rarely able to immediately determine the root cause until they’ve reviewed all of the presenting symptoms and effects. For example, an “oil leak” could be a symptom of various issues, including a faulty or failed gasket or seal caused by improper installation, under/over-torquing of bolted faces, lubricant/seal-material incompatibility, wear particles in the oil, or wear resulting from age and other factors. Thus, the effect of leaking gearbox oil could be described initially as “loss of lubricant” and, if left unattended, might require the effect code “mechanical failure.” In this case, the oil leak would be the resulting symptom of the true fault/failure cause, and just filling up the gearbox would only assure that maintenance returns to the equipment in question very soon—with the same work order in hand.
Root-cause failure analysis (RCFA) must be carried out through careful examination of the user practices and the damaged parts once they have been replaced. This is difficult to code on an initial repair, making it preferable to only code the Symptom and Effect on work-order completion. If it has been analyzed for, the Cause code can be added prior to closing the work order in the system.
Lubrication, when performed correctly, results in the successful separation of moving or bearing surfaces to reduce friction, heat, and wear. When lubrication is lacking, bearing surfaces will deteriorate rapidly and show distinctive symptoms that can be coded as “excessive heat,” “excessive vibration,” “excessive noise.” Interestingly, these symptoms also present themselves when a properly lubricated driver/driven system has been misaligned on setup. This illustrates the need for more than one code set, preferably three (Symptom, Cause, and Effect) to understand and trend the fault/failure and all different root causes. When the symptoms, causes, and effects are trended and analyzed with regard to such things as equipment and system types, OEMs, failed parts, suppliers, and contractors, specific and systemic problem causes can be quickly pinpointed and corrected.
Words of warning
There are literally thousands of codes that can be used across the three recommended-code sets. Consequently, it can be very tempting, when setting up the code database, to populate the search filter with as many codes as possible. This approach can lead to duplicated code sets across numerous search filters.
As discussed, for codes to be meaningful, they must reflect the types of symptoms, causes, and effects specific to a plant. Too many codes are onerous to manage, and personnel will quickly lose interest in ensuring the most appropriate ones are used. That situation, in turn, will lead to low-quality or untrustworthy data. A good way to prevent it is to conduct a trial run.
Prior to entering and using code data in your asset-management software, set up test-code sets in spreadsheet software. Then take a representative set of old work-order copies and practice-code them to see if the results are valid, useable, and reflective of your operations.
Keep in mind that once a code is in use, it’s very difficult to retire, as it is linked to work records that can’t be erased. During set-up, the choice of codes should be a judicious one, recognizing, at first, only the known typical symptoms and failures found within your plant. Never squander valuable data space using “other” or “N/A” catch-all codes.
Remember, too, that code complexity is dependant on the culture and training of personnel expected to recognize and input codes on work orders or in asset-management software. In my experience, organizations that have the greatest success in leveraging fault/failure codes to help manage their reliability programs typically use between 10 and 20 codes for each search filter. (Some of them have also worked as long as two years to fully develop their coding systems.)
Since ineffective lubrication practices are responsible for as much as 70% of all mechanical failures, lubrication codes are used primarily (and most effectively) in relation to mechanical-related failures. This means sites using these codes must take into account other failure types, including, for example, electrical. Those failure will also need to be coded—and require code space. EP
Contributing editor Ken Bannister is co-author, with Heinz Bloch, of the book Practical Lubrication for Industrial Facilities, 3rd Edition (The Fairmont Press, Lilburn, GA). As managing partner and principal consultant for Engtech Industries Inc., Innerkip, Ontario, he specializes in the implementation of lubrication-effectiveness reviews to ISO 55001standards, asset-management systems, and training. Contact him at email@example.com, or telephone 519-469-9173.