Predictive Maintenance « Reliability Bytes™

Archive for the ‘Predictive Maintenance’ Category

Change Culture Club (1), or Consultancy and Consensus

Monday, February 15th, 2010

WARNING: the reader is forewarned that while revealing to some degree, this article may confront endemic attitudes and be difficult to accept. This being said, like many other issues, not talking about them doesn’t make them miraculously go away. So we hope you can enjoy this minor brainstorm in spite of the disturbances it may bring. Triggering the right questions or a little introspection may sometimes be helpful.

I was once told that the percentage of success of personal therapies lies close to 18%, although I’ll admit I have never sought the truth of the matter (I do recall conversations with a former “significant other” specialized in this area of endeavor, and the gist of these conversations seemed to concur with the appallingly low success rate). Apparently, tribal witch doctors embarked on a similar mission to help an individual seem to achieve a success rate of… 18%… Certain prescription drug assisted therapies are far more successful for specific conditions, but as a whole, the above seems to hold water.

It would be easy to conclude that there may be a repetitive pattern in this accomplishment: therapy seeks to trigger or support change, and in this respect, the therapist’s work parallels the approach of the business or engineering consultant.

How many psychiatrists does it take to change a light bulb? Only one, BUT… the light bulb REALLY, REALLY has to WANT to CHANGE!!! And with that relatively stale joke, we uncover one of the great secrets of reliability consultancy: your consultant(s) will not change anything, YOU will! Well, actually, you might! But ONLY if doggedly determined to achieve a continuous improvement loop and/or specific targeted goals.

It would be tempting to jump to the conclusion that the consulting firm therefore serves little or no purpose. Here, then, is another rule of consultancy: if you could, you would! The stern review of current activities, the guidelines to establish a road map for change, the assessment of best and quickest results to be obtained (also called low lying fruit), the benchmark for exemplary or best practices, the traps and pitfalls to avoid, the identification of the areas where MORE money should be spent (and conversely, areas where money can be saved because it is an ineffective or inefficient use of resources), all of those items pertain to the expertise of said consultant.

Many firms choose to sugar-coat everything. Here is another rule: if you HAVE to SUGAR COAT it, the organization likely has not attained the maturity that will allow it to break its previous bad habits!Some years back, one consulting firm’s VP put it succinctly when the author raised concerns in one project: “Doesn’t matter! We get out fat fee anyway, and may get to do it again at the same location in the future…” Perplexed? Dubious? I agree, because so was this wincing writer! We all need the money (the rent, the mortgage, the business expenses), but must we be so crass and uncaring about it? This being said, the blunt reality must be addressed, but doing so with good humor and a view to how best to promote change remains inherent to our mission.

A recent challenge to our consulting wisdom was issued abroad where management customarily relies on a consensus culture. The rule applies: if you could, you would! Therefore, if they had been able to promote needed changes, or had they been capable under the current hierarchy, organization, system and culture to deliver (product, improvement, KPI, other) on target, we would not have been involved.

And Consensus?
Too many cooks… Imagine if the purchase of a car were open to negotiation or discussion for each and every component of that car. The process would be laborious and tedious, and the end result would quite likely be a monstrosity.

Somewhere along the line, the “car” would surely become a “vehicle” and every possible function of that car within a family, business or industrial context would be considered by participants. The size and footprint of small cars is interesting and so is their energy efficiency, but that shovel on the payloader is “oh so very useful”… What do you mean by “the shovel is heavier than the car”. Never mind the hydraulics, we’ll just leave the shovel at ground level all the time. Or install hydraulic stabilizer legs on the car to stabilize it when we lift the shovel. This is the underlying cause to the “camel” joke: a horse designed by a committee. And perhaps this writer can raise a few smiles by latching on to one of the Hispanic definitions of camel: difficult, laborious, improbable to bring to term. Clearly not our target!

Consensus implies input from various parties, and discussion. Some people will lend tremendous ideas to the process and will definitely have an impact on the end result. Some participants around the table, or involved at arm’s length (teleconferencing, minutes of the meeting, email distribution) will lend a cursory opinion, and no more. And someone will have to choose a course of action and take a decision. Managing is not a democracy!

A brief parenthesis about democracies, since I mentioned cars earlier: one individual had several daughters and to cut short “consensus” issues on car color, each daughter in turn chose the color of the family car. That is how the poor man ended up in a lemon yellow car for a few years.

Back to our main topic:

Seeking consensus about change ignores some basic principles of human psychology. We tend to resist change. We tend to reject it if we can. There is strong criticism whenever change is proposed, and such may be brushed aside as an agent of resistance to change. Yet, change for the sake of change serves no purpose.

What do you seek to accomplish? As consultants, we have waltzed in so many places where metrics (KPI or otherwise) were weak, distorted or inexistent at the outset. Can we rely on bad data? Can we nail our targets down when the underpinning of information paints an inaccurate picture of what we want to change?

In fact, we can, but it also becomes part of the mission to get the numbers to truly reflect the reality of the situation. Often times, a client would like the current numbers to become the basis for payment. This is feasible, but rife with problems when the numbers have been manipulated.

To be continued…

Posted in Articles & Papers, Asset Management, Condition Monitoring, Maintenance, Program Management, Reliability, Reliability: Implementation, Reliability: Methods | No Comments »

Resistance to Change (2)

Friday, October 2nd, 2009

Legitimate Concerns
Either some adjustments are needed to make the proposed changes function properly, or there are hurdles or barriers that have not been considered. Perhaps the product / change / project / system does not meet the objecter’s expectations of quality (or other, such as technical level), or there are known issues that the salesperson would not reveal.

Feedback from other parties (different location or facility within the corporation, friends, colleagues, or other) may point out severe problems.

Very often, some person voicing a legitimate concern may not be capable of fully expressing the reasons behind their reticence (oddly enough). The objecting party “feels” the proposed solution to be wrong for their environment.

If consensus must be achieved, develop a checklist and discuss the proposed goals with the vendor / service provider, and never forget to get the agreement in writing, detailing the issues, what the solution will address, and how it will achieve this.

Posted in Asset Management, Consulting, Program Management, Reliability: Implementation, Reliability: Methods | No Comments »

Resistance to Change (1)

Thursday, September 10th, 2009

The infamous “resistance” to any proposed change takes many forms.

There are legitimate concerns, there’s contrariness, there’s fear of change, there’s protectionism, there’s a confrontation with a history of failed or abandoned initiatives, and finally, refusal to execute the work involved in the implementation of change, which unfortunately amounts to plain laziness.

Arriving at a consensus within a group of people may well face every previously stated type of objection, making compliance and adoption of almost any novelty / improvement / project difficult or even impossible at the best of times, no matter the value of the proposed initiative or change.

Over the course of the next few days (we hope), the author will endeavor to write out a few thoughts on each of the above.

Contrariness
The contrarian takes two forms: he can be a naysayer to anything he does not himself initiate, and thus, becomes a negative influence and rarely a helping hand in any of the activities of the group, corporate or otherwise, or he can be a conscientious critic of unlikely, unpalatable, unreasonable, inefficient or ineffective practices, methods or proposed “advances”, seeking to ensure quality and thoughtful of achieving specific goals. Of course, whether or not the contrarian can deliver his message in palatable form remains a challenge, and the (often different or opposed) views tendered by said contrarian can clash with the majority or the view adopted by leadership. Both require considerable maturity to accept the opposing current and trigger intelligent discussions based on analyzing what that impopular person is saying to obtain the value or pointed correctives that his views may contain.

In the above, “unlikely, unpalatable, unreasonable, inefficient or ineffective practices, methods or proposed “advances”…” could merely signify that there may be room for better adjustments or they may be downright necessary: the person deemed a contrarian may merely seek a slightly better approach, or more bang for the (same) buck…

As examples…
One anecdote I often use (and may even be found in another posting on this site) is the advent of the first Windows-based or Windows-compatible (the Microsoft registered brand used without permission, not the household-type) vibration condition-monitoring software. Given the current preponderance of that operational system or platform, the reader will understand a few years have gone by since the anecdotal incident.

That software’s main qualities were:
1) it was going to be first to market under the increasingly dominant Windows (see previous disclaimer),
2) it actually worked without crashing,
3) it simplified report printing and layouts, but only for what was now extremely basic (or entry-level) reporting.

The same software principal defects were:
1) It offered little except basic functions, made readily accessible not through any ingenious design, but merely through the Graphic-User Interface’s benefits,
2) the software did away with many of the useful application functions that were readily available under DOS (but of course, that was going to be rectified in the future, meaning probably never),
3) it cost a frightening amount of money

My attempts at making suggestions to achieve expansion from the foundation we previously had, as opposed to devolution in terms of application, were met with allusions to “resistance to change”, when in fact, the nature of my objections was “Nice eye-candy, where’s the meat?” or where was the substance to assist analysts in better doing their jobs.

Another valid example, when faced with various problems during a reliability audit done under another company’s auditing process (or lack thereof), was to ask whether the process had been the subject of an FMEA (Failure Modes & Effects Analysis). After all, if you sell the science, the execution and the mindset, you should be interested in applying all of the previous to your own product, whether physical or service oriented.

In the previous statement, my “or lack thereof” was unfair, and of the naysayer contrariness type: in all fairness, they did have a process, but the process should have been accompanied by clear directives and guidelines as to “do’s and dont’s”. The process should have benefitted from strong warnings against allowing corporate tag-alongs during execution. My suggestion that an FMEA would clearly have established problems with such a practice came from obvious hurdles such as the reluctance of audit interview participants to formulate their answers in the presence of a corporate representative.

Opposing views leads to (minor) confrontation, and people are increasingly uncomfortable with disagreement or argumentation. Yet, out of the clashes of ideas are born the better or even best solutions. HBR (Harvard Business Review) and other management article sources state that the increasing disappearance of differing opinion hurts business.

For the well-meaning contrarian, perhaps the road to Hell is paved with good intentions.

Posted in Asset Management, Consulting, Program Management, Reliability: Methods, War Stories | No Comments »

Reliability Challenges & Fundamentals

Sunday, March 16th, 2008

Numerous experts report the undeniable absolute necessity of management conviction and dedication for reliability efforts to result in a proper and sustained “field” (that would be the plant floor) implementation. No argument could possibly otherwise convince us or our readers. We agree on something.

Why then do we see a generalized backtracking to antiquated methods or unwitting feeble returns from reliability approaches? Where is this management commitment when reports from the field indicate reliable methods get implemented and then seem to vanish into thin air or quickly get set aside? Why is apparent regression almost inevitable?

What some may fail to mention is the capital importance of fundamentals. And these essentials may escape most of the “business model improvement” proponents due to a simple and quite ugly fact: the “business” people rarely speak with the technical personnel who get the maintenance train on track and keep it there. And when they do, as they are often used to speaking very different languages, these parties may have limited exchanges or communications due to the different focus or interests they manifest.

The communication gap may be further aggravated by a largely false perception in head offices that the technical people remain uneducated. Nowadays, their credentials and pertinent experience may even at times exceed those of decision makers. This is not to criticize anyone: the preceding merely attempts to state occasionally occurring (and previously encountered) circumstances.

The predictive maintenance and condition-based approach to maintenance and reliability are vital to success. Yet, these facets of maintenance and engineering have been in place for some time, with often poor to moderate results (the author is being kind; so many PdM or CBM programs are hobbled structurally and technically that their returns can only be qualified as hobbled). The promise of fabulous returns can not be met when the program is not “fed” properly: investment, education (training at ALL levels) and sensible recognition of efforts, to name but a few factors too often missing from the final recipe…

What makes you think that doing the same thing in the same way will now yield a better result? What will now be done to properly adjust the targeting? The liabilities (or problems) and personnel are the same. Or personnel keeps changing in turnstile-mode.

Of course, critics might glumly reply “Have you not been part of the system that created the ineffectiveness we must now endure?”, a pertinent albeit biased question. We propose a viable working platform or product to our clients. We might express it as “we sell a car”. The client then plays pick and choose, dismantling the platform to purchase (allegorically) the two left-side wheels, one rear bumper, and parts of the engine, instead of buying the whole functional vehicle. The reasons are many and they feel justified in this purchasing approach: they already have two right-side wheels (of a different size), one bumper and engine parts (likely mixing centimeters and inches), so they feel they can reassemble a working whole. The truth seems to point to “wishful thinking”.

An example? Some years back as I instructed a Vibration Analysis 1 course for one of the main vendors in our field of endeavor, two technicians showed up from an automotive parts manufacturing plant. They expressed their concerns relative to the course, having discussed with their supervisor what they felt was their need for training (they would have been more comfortable with an introductory course instead of the one they were now to attend). I assured them of my availability over lunch and after regular hours should they face serious hurdles, and also told them I ran a very open classroom where questions were welcome at any time. This can be helpful, but if fear of ridicule and timidity become the governing concern of the puzzled, our best efforts to remain available yield little in the way of improved comprehension. At any rate, they never availed themselves of the repeatedly tendered “extra” support or semi-private sessions.

Most Level 1 courses clearly state a need for 6 months prior experience and/or having attended an introductory class. These two participants were lacking in both respects. Net result: come evaluation time, these two felt that the vendor offering this training was only interested in revenue and they never should have been “allowed” to attend that course.

Everybody is entitled to an opinion. Ours would differ slightly: in the hopes of saving some training dollars, their supervisor sent these participants to a course that was above their current reach. In so doing, he wasted more training dollars than he saved. He also exposed his technicians to a little discouragement, and lower motivation due to perceived difficulties.

Could the problem have been resolved right then and there by using a different approach? Course contents did not lend itself to a quick readjustment: other participants quite liked that course and got what they came for, but then, they had the necessary bases to absorb the curriculum.

To the previous example, we should also add the unpopularity of introductory courses in certain areas of the world. The “client” (purchasing or management) feel them to be a reach for more $$$, when in fact, the participant get swamped with too much material when attending the “chosen” (not by them) higher-level course.

Worse yet, in those same areas, when a certification exam is faced at the end of a week’s training, some participants have at times been warned that failure would equate dismissal. Sitting (or writing) an exam that is meant to cull the untrained may dauntingly challenge the neophyte.

Another sad hurdle to reliability excellence remains the discrepancy in pay rate and benefits afforded those who practice it adequately. Sooner or later, if competent technical personnel find they may be given better opportunities elsewhere, they will jump ship and seek out better climes. There are management or HR theories about pay scales and bonuses (this writer will purposely stay away from them as readers might be offended by psychological aspects of remuneration), but an occasional carrot, such as two checks waiting in the wings (gold and silver medals, if you wish) might yield surprising competitive benefits. Or setting PdM program goals and tying a bonus to meeting those targets.

Proactive engineering steps used hand in hand with precision maintenance yield better reliability. The latter is undeniable. Yet, without a strong predictive program, above and beyond any scheduled preventive replacements (likely arising from an RCM study) and inspections, production and asset reliability will remain out of reach.

PdM / CBM or Condition-Monitoring ARE the technical foundation that can be encouraged, but not managed at any level other than that of maintenance and engineering. In other words, if reliability is a fortification against trouble and decay and a guarantee of productivity, the walls or battlements depend on solid groundwork called predictive maintenance.

Simply put, Asset Reliability (and maintenance) can not be driven by failure-detection if predictive efforts remain incapable of perceiving faults.

Posted in Condition Monitoring, Maintenance, Predictive Maintenance, Program Management, Reliability, Reliability: Methods, Training, War Stories | No Comments »

Les conseils d’expert (1)

Wednesday, February 6th, 2008

Lorsqu’en présence d’un moteur assez puissant, prenez gare à l’interaction entre l’aimant du capteur et le champ magnétique environnant ; elle peut mener à l’altération des mesures et dans les pires cas, peut conduire à un faux diagnostic. La présence ou l’importance de l’interaction peut s’évaluer en rapprochant le capteur de sa « cible » (sans avoir de contact) et en regardant en temps réel la forme d’onde temporelle ou le spectre FFT.

L’expert saura travailler aussi bien en échelle linéaire qu’en échelle logarithmique. Le linéaire présente un portrait analytique plus compréhensible (particulièrement pour le débutant), mais l’échelle log prendra toute son importance dans le diagnostic avancé ou pour les cas d’éloignement entre la sonde et la source.

Gardez toujours en tête que le spectre FFT est une réduction de l’information contenue dans la forme d’onde temporelle, et que la forme d’onde elle-même ne contient PAS obligatoirement toute l’information pertinente ou désirable, selon ses paramètres (sélectionnés par l’usager) relativement au phénomène mesuré.

Nettoyez régulièrement les aimants et assurez vous de la propreté de la cible (endroit du montage). Ne laissez pas non plus le câble ballotter au vent. N’imposez pas au câble de tension, et si vous devez absolument le faire, assurez vous que cette tension soit uniforme / constante.

L’aimant ne sert pas toujours : des matériaux non-magnétiques peuvent demander l’utilisation d’un contact direct entre capteur et point de mesure. Il est important de se rappeler qu’il est préférable d’éviter de d’exposer ses mains à de fortes amplitudes de vibration qui peuvent à la longue susciter des problèmes. Le port d’un gant ou d’un gant de caoutchouc réduira cette incidence dans la plupart des cas. C’est le HAV ou Hand-Arm Vibration.

Certains systèmes offrent l’interpolation et d’autres pas. Dans le cas d’une fenêtre Hanning (le choix habituel), l’erreur d’amplitude sur une crête dans le spectre peut atteindre 16%. Selon la position de la crête par rapport aux « lignes » du spectre FFT, l’erreur se situera donc entre 0% (une crête parfaitement centrée par rapport à la ligne) et 16% (une crête à cheval sur le seuil de deux lignes avoisinantes). Le spectre FFT interpolé élimine cette erreur. (Voir le conseil suivant)

Un moteur asynchrone (le plus commun) n’est presque JAMAIS véritablement à RPM fixe puisque le glissement dépend de la charge et la charge n’est que rarement parfaitement fixe. Donc, les crêtes se promènent sur une « toile de fond » fixe (les paramètres du spectre FFT). En balayant ainsi une petite plage de fréquence (selon les variations), la crête se déplace par rapport aux lignes et une amplitude CONSTANTE se PERCEVRA comme altérée : la crête change de place, et selon sa position en fréquence, l’erreur sera plus ou moins importante. Donc, d’une collecte à l’autre, les amplitudes montent et/ou descendent au selon la charge. L’interpolation (si elle est présente et qu’elle est utilisée) règle la question.

Dans le cas d’un test d’acceptation, hormis la calibration qui prend alors une importance particulière, les considérations énoncées dans les deux conseils précédents revêtent une importance toute particulière. L’interpolation pourra nous débarrasser de l’erreur de la fenêtre Hanning. Sinon, il faudra utiliser une fenêtre Flat Top pour s’assurer que les amplitudes (qui autrement seraient souvent altérées à la baisse) ne dépassent pas les seuils tolérés.

Posted in Condition Monitoring, Diagnostics, French / Français, Machine Types, Predictive Maintenance, Program Management, Surveillance de machines, Vibration | No Comments »

This is NOT a Guessing Game…

Friday, December 28th, 2007

…or at least it shouldn’t be! Vibration analysis corresponds to a science. Of course, the art and science of getting the proper measurement from the pertinent location(s) with adequate instruments before performing knowledgeable signal processing (if needed) also come into play, but the analytical part mostly relies on relatively simple notions or assumptions while reviewing fairly simple data.

We regularly hear about what we would deem failed predictive approaches where a lack of training or a lack of expertise seek dismantling and inspection of machinery components instead of proper analysis leading to an accurate diagnosis of the problem at hand. This approach amounts to bad (and costly) predictive maintenance management. It also favors extraneous manipulation of machine components best left alone when considering the potential human-error factor linked to intrusion (equivalent to resetting the bathtub or other curve to the infant mortality phase). Precision maintenance mitigates the previous factor, but then, it is a rare case indeed to see precision practices in a context where condition-monitoring fails to go hand-in-hand with proper diagnostics.

Posted in Condition Monitoring, Diagnostics, Maintenance, Predictive Maintenance, Program Management, Vibration | No Comments »

Vibration “Problems”

Friday, December 28th, 2007

Confusion reigns with respect to machinery vibration issues. Most people still hang on to vibration as a problem, instead of the diagnostic science of vibration as an indication of a developing problem.

Where does the difference lie? Vibration as a problem per say falls more in the AMPLITUDE analysis category, and remains blatantly obvious in most cases. Excessive vibration levels can be directly linked to unbalance, severe misalignment, resonance (or rotor critical speed problems) and other perceptibly notable behaviors, such as what might be exhibited by a machine or component having failed or well-advanced in its failure mode. Vibration as an indication of a problem tends to be a FREQUENCY (or time waveform contents) analysis issue. Of course, the appearance or growth of a small peak may bring us back into an amplitude context, and small amplitudes often show severe problems. Our vibration measurement will reveal anomalies or abnormalities that could yield catastrophes. The apparent insignificance of some amplitudes may well be linked to the location of the problem relative to measurement point, slow speeds, difficultly transmitted phenomena (ex: an incipient inner race problem must send the vibration wave through two thicknesses of lubricating fluid, above and below the rotating element which must also be traversed to then transmit to the outer race and subsequently, the pillow block: a long trajectory for a tiny peak lost amidst other events and noise) and other barriers to our perception. We’ll remind the reader that we advocate learning to look at data both in linear and logarithmic scales to familiarize and sharpen the analytical sense when interpreting more difficult or “veiled” problems.

The seasoned analysis veteran likely knew all of the above. But the newcomer or the merely distant onlooker (receiving reports as opposed to performing predictive tasks) may now realize that vibration is not just about crankshaft-like motion.

Posted in Condition Monitoring, Diagnostics, Machine Components, Maintenance, Predictive Maintenance, Vibration | No Comments »

Change? Or Upheaval?

Thursday, December 13th, 2007

We often hear the words “change management” as an adjunct to reliability efforts. Yet, if one is to trust reports of reliability effort failures and abandonment, or reversal / devolution to earlier methods (or lack thereof), something must surely be going awry in the way we attempt to do things.

Change can be good, and it is inevitable, but too much change at the same time overwhelms personnel. A new approach to data input into the CMMS or EAM requires training and a little time for old (and usually inadequate) habits to get reformed. If management simultaneously modifies a whole list of other things, the chance of success in implementation suffers a considerable negative impact.

We are all too aware of the existence of resistance to change. “Better” must be demonstrated and proven before wholehearted adoption can take place. And criticism along the way will likely occur. The arguments of “bad faith” and “you’re resisting the change” usually point to bad implementation (key word would be usually: some people will just reject anything new out of hand).

As an example, I am reminded some 15 years back of the arrival of a software package for vibration-based condition monitoring. One of the (or perhaps just “the”) first operating on a Windows platform. It was pretty. It was easy to use. But its failings lay entirely in technical contents (or lack thereof): you could not do (at release) what had been common fare with the DOS version. As a matter of fact, I’m not entirely sure the final version could either, but that’s another story. Comments with respect the technical deficiencies or missing functions brought annoyed replies implying “resistance to change”. Was that the case? The passage to Windows and its GUI were good, no doubt. An SQL database was also a much needed improvement. The price to pay was high: the loss of technical contents needed to properly assist the analyst proved contentious for a long time.

The problems encountered while managing change often arise from a lack of understanding (or even caring) of the needs of all parties involved in the execution of the mission (production, maintenance, other). Things work out better when all parties are consulted BEFORE an initiative launches, and that means all parties at all locations of an organization (the needs, or the level of change, may differ considerably). When scepticism arises or when questions are asked, one needs to confront them head on, with pertinent answers.

Bottom line: enthusiasm and the embrace of movelty may be formidable drivers, but if the homework has not been done to convince others, support their needs and address their concerns, reliability (and other) initiatives may fail, with regressions, dismal results (in ROI terms), or simple failure to launch properly.

Posted in Maintenance, Program Management, Reliability | No Comments »

The Relevance of Older Data

Saturday, October 20th, 2007

Much has been said as to the “key importance” of data from past data collections and how much this data should be kept for future reference. Is this really the case? What, in fact, is of primordial importance, and what might simply be done away with, given a little reflection on the matter?

Most vibration data becomes quickly irrelevant, UNLESS it contains pertinent traces or indications of a developing problem. A ceaseless repetition of waveforms and spectra showing minute and harmless change simply clutters a database, but most PdM software fails to adopt a design enabling quick and accurate management of such issues.

We want baselines. We want them to be accurate not only in terms of resolution, but also in terms of machine operation (load, temp, product, etc.) documentation. Multiple baselines helps us considerably, inasmuch as we may then assign different operating-conditions or perhaps post-maintenance (repair, replacement, etc.) “slots” to these reference measurements. We probably want these to be accessible in multiple parameters. Baselines are, so to speak, a “keeper” in the context of this article.

Regular, run-of-the-mill, “no defect found” data should be considered as having a limited shelf life. Identical spectra within a waterfall (or cascade) take up space for no good reason. They do, however, provide continuance of a pattern, which could easily be managed as a “replicator” function once time proves that no review is forthcoming (reviewing or self-auditing of data should occur when a failure occurs in spite of no defect having been detected by the predictive measurements, their programming and/or the analyst’s assessment of such data). Any changes to the measurement set-up should be documented as well, particularly if a change arises from the conclusions brought about by an investigation in an undetected developing failure or “crash”.

A predictive maintenance program accumulates a knowledge-base that seemingly, and quite sadly, evaporates over time. The principal cause for the volatility of this knowledge rests in the inability to “grab” a data set from a specfic date (or successive dates when trends are relevant) and form a diagnostic subset. In fact, it has long been my recommendation to our clients to keep a book of problems detected (and a hardcopy of the pertinent data) on monitored assets, simply because it becomes a critical reference for the future and a BRIDGE to pass the program over to somebody else if and when the analyst is ever called away from this condition-monitoring posting.

The answer to any question implicating old data relevance becomes obvious. Measurement set-ups, baselines, measurement reviews, problem identification documentation form the basis for a reference book that will over the years become a fabulous treasury, a fountain of wisdom for both the technicians and analysts involved in PdM work and management. Except for the previous and recent, still believed to be time-relevant to potential review, data, all the other accumulating data creates unnecessary and unwanted clutter.

Posted in Condition Monitoring, Predictive Maintenance, Program Management, Vibration | No Comments »

Machinery Condition Monitoring: the Beauty of Simplicity

Sunday, May 6th, 2007

More often than not, the levels of complexity achieved when defining monitoring parameters for any machine type have been excessive to achieve the minimum level of “sensitivity” we seek within a detection context. The previous should also bring to mind the historical aspects of machine asset CM management: this complexity extends to the collection sequence (whether it is visible or not), the programming of the sequence, the handheld instrument processing, and it also spreads to data review.

A simple trend of one parameter or another typically fails to adequately paint a picture of machine health. Neither velocity nor acceleration will succeed in that respect. Changing units from peak to RMS or the reverse will also fail in providing an efficient detection net. What kind of SIMPLE safety net will mostly be up to the task? Do note the caveat: “mostly”, as some problems would still likely escape our notice…

Imagine a system delivering the following simultaneous trends:

Velocity pk (time waveform derived or true peak)

Acceleration pk (time waveform derived or true peak)

Crest Factor for either of the previous

High-Frequency / Ultrasonic “Estimator” (meaning Spike Energy, PeakVue or similar; these last are trademarks of their respective owners).

Such a system would not function for ALL machines and configurations, but on most common configurations, it would adequately cover the detection function for most problems occurring within the machine park. It still would not be perfect. We can find a number of cases for electric motors where the previous system would leave gaps. Certain machines would also benefit from a trend of displacement and/or a correlate to measurements off proximity probes.

For many years now, single parameter pen-like mini-instruments have been a popular item. While the intent was likely to quick check a machine just worked on, some pre CM “entry level” shops or plants may partly or wholly rely on such overly simplistic single-parameter trends. Vendors might provide a better “view” through the inclusion within their ”simplest” tool of multi-parameter trending as suggested above. It would come closer to adequate monitoring. This being said, the detection safety net based on correlated trends of multiple parameters provides helpful coverage in a “wide” net: this applies to a large number of machine assets such as what is found in a paper mill, and not so much to a power generation station where the assets are few, usually complex, and allow for wider man-hour resources in terms of analytical exploration.

Posted in Articles & Papers, Condition Monitoring, Predictive Maintenance | No Comments »

Reliability Bytes™