Should we call it Data Analysis instead of Condition Monitoring?

By Martin Williamson, KEW Engineering Limited

Three Letter Acronyms, they're almost a language on their own! RCM, PdM, OEE, CbM, PAM...

Apart from learning the new language of maintenance, we have to take on board new ideas and concepts. Life has moved on from the simple laboratory approach to oil analysis, away from the pencil and plotting paper that we used to store our data.

Now we're talking about open architecture databases, open systems alliances and Ethernets and intranets and data sharing.

Fortunately, as in any technology, the underlying principles remain, we want to get proactive and predictive information from our analysis and use that to troubleshoot and rectify.

How we actually handle that data is what has changed. Sure, there are new technologies around that simplify our lives, for example, the emergence of new online, indiscreet sensors that feed out real time information.

But are we at risk of information overload? Remember the 90s, when everyone believed they needed a computer, when we were bombarded with the data age. On my desk back then, I had a computer, which had an address book for the email, and a separate address book for the fax software. Then there was the Palm Pilot software with the back-up data for the unit. Alongside that, there was the mobile phone with its own address book. Is this not a clear case of information overload?

Ideally, as we are now seeing, the various units are being designed into one package, my current phone sporting very capable handheld software, a good camera, music and video facilities, along with software that means I can synchronise to a common address book on the PC. And there's no more clutter of cables, it's Bluetooth(c).

But think about your on-site condition monitoring, the data from the vibration, from the thermography, from the oil analysis. And that's before you consider all the other possible data sources that could be added pointing to the same diagnosis you are seeking.

Let's face it, a Condition Monitoring (CM) programme is about one thing; business! Saving the company money and making the company money. How we achieve that goal is by seeking data in a pattern to inform us of impending problems on the machinery. Perhaps, however, we should not be seeking a purely condition-based approach?

The problem is we are seeking a condition through analysis, but just like when we go to the doctor, we are already feeling unwell. So we know that that is the case. We just want the doctor to troubleshoot the cause of our lack of performance. Like wise a machine knows it is feeling unwell, that its performance is down. And we don't need oil analysis or any other monitoring technique to tell us that. We have that information to hand already, on site. If only we could access it easily?

Performance monitoring is quite simple; has the production slowed, has the precision control been affected? Even more simply, does the system have a higher temperature than normal; is it leaking? Is the flow rate or pressure down? What about the filter usage?

Put simply, we have a number of options to determine system condition or performance from differing sets of data. How we use them and access them is what sets the world-class companies apart from the merely average.

Of course, we have to be wary of information overload. When is information overload reached? Presumably when we have identified the point at which the machine is indicating a potential problem, we have identified it, and rectified it. Beyond that, are we are wasting time? Naturally, to increase our confidence in the diagnosis, we may want to hear the same message from more than one source, just as we may seek a second consultation from a specialist.

Obviously, the data chain is crucial at all points; generating the data (or the sensor interface), analysing the data (or the data collectors) and storing the data (or the databases). The problem is that there are many ways to generate data, and, in oil analysis terms, the industry abounds with varying techniques to achieve this. Data analysis is generally straightforward, simply a processing of the signals. Storing the data in a meaningful format for historical purposes is another issue to address in terms of cross platform data format.

In CM terms, we have a much more integrated approach than previously. We have our data generators; the oil samples in the laboratory, the online or portable oil sensors, vibration sensors and IR cameras. Then there are the data analysers; the units that transpose the signals into meaningful information such as vibration spectra, IR images, and the plethora of oil analysis tools that generate meaningful values at varying parameters. CM databases are now better able to handle all the technologies with the ability to import information from outside sources and can offer the CM specialist the ability to look at IR, vibration and oil data at a fixed point.

That's all very well for CM, but what about the day-to-day management and maintenance information. How many maintenance people can honestly say that they have a good handle on the filter usage, the lubricant consumption, or even the pressure, flow and temperature measurements on specific units? The information may exist, but is it even accessible?

SAP and Maximo are two big names that offer packages for Computerised Maintenance Management Systems (CMMS) as part of their software. Essentially, these hold the kind of information that is a further advantage in the CM specialist's pursuit of reliability. What has to happen is that the data must be formatted in a sequence that can be cross-read by varying database platforms. Often, the answers to the filter and lubricant usage are there. But then again, some of the data is not. There are ways to add to this, but it boils down to cost feasibility and data value.

What steps could be taken to generate the data that is necessary? The process of generating and uploading the data must be as simple as possible to avoid errors. Simple ideas include the interfacing of pressure, flow and temperature sensors to the same Ethernet or online circuits that possibly exist already for the vibration or online oil sensors. Other ideas include providing electronic clipboards (i.e. small handheld units) to the maintenance staff so that they can log what volume of oil is placed in the system during top-ups, or to note tank levels, and visible oil state. The use of drop down menus with pre-programmed answers is beneficial to maintain consistency of data. In addition, through the management software, links should be provided for the CM specialist to tap into maintenance history to see how frequently filters are replaced or systems are drained and re-filled. Such watch-keeping systems are rapidly becoming the norm in more critical plants such as in the petro-chemical industries.

With the accumulation of broader data sets then it is necessary to screen the data to avoid viewing unnecessary data. That isn't to say discard the unnecessary data, just file it for historical purposes without wasting time analysing it. Target the most obvious data sets and then set caution and alarm limits. If these are exceeded, then look to the bigger picture. For example, set limits on the pressure, flow and temperature, as well as particle count on a large fluid power unit. Let the software/computer monitor these values real-time, and send a warning if the limits are exceeded. If they are, then start to access any history that may point a finger at the problem, such as a recent oil drain, or filter change. If something as simple as this is not the cause, then look at the lubricant performance, such as the viscosity, or the AN. If not something lubricant related, then look to component wear problems.

Being able to access the holistic view on one terminal with out having to make calls and check up with other members of staff and getting conflicting stories must be a benefit.

What other benefits do the lubricant community get from this approach? Imagine, as the analyst, arriving in the office and logging on. The computer spews out a task list for the day. This might be a list of samples to collect, some routine on critical plant, some raised by the computer based on alerts. In addition, it prints up the label sheet complete with the information relating to the oil type, the number of machine hours, oil hours and volume of oil added since last refill. And what's more, it generates the label ID sequence in such a way as to minimise your walk around time. You collect and despatch the samples, confirm this to the computer and it then logs on and informs the laboratory of the impending arrival with the ID's noted for alert conditions. The laboratory completes the samples and sends the data back electronically and the data is then waiting in the system for you to analyse, perhaps a day or so later, as part of your task list for that day.

Now on a parallel track, a lubrication technician arrives at his/her desk and similarly logs on. The computer provides them with a task list for the day which may be to complete a lube route with instructions on which machines requires a top-up complete with the information on the lubricant type required. Again the computer provides this in the sequence that minimises travel time and effort. Once completed the lubrication technician uploads the information from the handheld in which basic information such as volumes and oil state etc. have been added. Any alerts raised will be immediately reported to your system, and the normalised levels of consumption calculated and trended.

Similarly, a task sheet may be raised for another member of the maintenance team to replace a filter unit. Once again the computer provides the worksheet with information relating to how to do the job, any safety lockout procedures etc. and what filter unit to collect from the store. Once the job is completed, again this can be recorded into the system, and presumably, it will be smart enough to match the machine hours so that a normalised plot of the filter life can be checked to predict when the new unit may need investigating. How did the right unit come to be in the store, in fact, how did the computer know that it needed changing? Well, it may be that the unit has some sort of differential logging device that will trip an alert in the computer which will then generate a purchase order for the replacement element, or, as suggested above, based on historical, normalised data patterns, it then generated the purchase order. Once the element arrives on site and this is logged by the stores personnel, the computer then knows to schedule the job.

Is this a pipe dream? Certainly not, the software and databases are very much capable of handling this kind of information. The problem lies in getting competitive and complementary suppliers to link their data and systems accordingly. Then the problem of sorting the data and screening it is the next step to avoid information overload. Let the computer deal with the data, but make sure that as the analyst you are seeing the important information and making confident prognoses.

Back to Tips

[home] [about you] [about us] [oem club] [link to us] [tell us what you want™]
[industries] [applications] [operating conditions] [approvals] [grease] [oil]
[spray] [paste] [oil safe] [magnom oil filtration system] [heating oil] [grease guns]
[medical white oils] [links] [contact us] [newsletter] [FAQs] [Publishing] [Site Map]