Oil analysis software has one primary function - to convey to the user, with a minimum of confusion and a maximum of efficiency, the state of a machine and its ability to continue to perform its designed function. The ability of a software suite to do this, and its flexibility to adapt to varying user requirements, determines its success as a viable product. The suite is challenged to present and analyze, both automatically and on demand, laboratory data in such a way that meaningful decisions may be made with regard to future machine operation. This article will highlight important functions and requirements of oil analysis software required to achieve reliability goals.
The System
Oil analysis software is a database application. It has a back end (the database) to store the information and a front end (the user interface) to manipulate the data into useful information and present it accordingly. Sound automatic backup, repair and security features go without saying. A permissions feature should be available to assign functions to different users.
Ideally, the oil analysis database should be part of the greater computerized maintenance management system (CMMS) to avoid redundancies in terms of machine and component naming.
If the oil analysis database exists separate from the CMMS software package, then a suggested database structure is:
-
Machine groupings: This is a hierarchical structure which can support multiple nested levels. As an example, "Coal Conveyors" could be a sublevel of "Fuel Handling", which in turn is a sublevel of "Power Station".
-
Machines: This is a single-level structure which has components under it. An example: "Conveyor 1".
-
Components: These are the various components which make up the machine. Examples are: "Fluid Coupling" and "Gearbox".
-
Lube points: These are the individual points in the system being sampled. A lube point has a one-to-one physical relationship with a sample valve, drain port or from wherever the sample is being extracted. A steam turbine might have the following lube points: "Reservoir", "Bearing Drain Line", "Gearbox Drain Line" and "After Purifier".
Whatever the structure that is ultimately chosen, the suite should have the flexibility to design the database either as part of the CMMS system or to be able mimic the structure of the CMMS as closely as possible.
There are two common implementations of an oil analysis software suite: a basic submit-and-report model or a full-function package. The former is used to submit sample information to the laboratory, receive results and report them. The latter has instrument interface and diagnostic capabilities, too. If you are using the submit-and-report format, then some means of importing lab results into the database must exist.
The Users
Oil analysis software has potentially four types of users, and each must be adequately catered for by suitable interface modules.
The first user interface module is sample submission. After the sample is taken, the relevant information needs to be captured in the system. The submission module captures sample identification data such as machine and component associations, and any other information relevant to the sample.
The laboratory module is used, in its most basic form, to input the test results manually. Ideally, the instruments would interface directly with this module. This module may or may not be required in all implementations of the suite. If you are not using an on-site laboratory and rely purely on a commercial oil analysis laboratory for testing purposes, then this module is not needed. At the very least, you will need to ensure there is some provision, either Web- or e-mail-based, that can import the test results into the database.
The diagnostics module is used to present the test data so that it may easily be interpreted. Once again, this module may not be needed in an implementation of the software that is just used to submit and report sample information. As a basic minimum, there should exist a capability for the end-user to modify or expand the diagnoses, or to add comments.
The reporting module generates and distributes reports to the end-users of the information. There should be features to enable the generation of customized reports. There should also be the ability to generate statistical management reports, which might be generated on, for instance, a monthly basis.
Physical Environment
The oil analysis process can potentially take place over a wide geographical area. The point of sample submission might take place in one location, with the analysis and diagnosis in other areas. For simple, on-site implementations, a stand-alone system running on one computer might be acceptable. But for most, a network-implemented, multi-user implementation will be required. Therefore, determine if the proposed suite fits your current needs and foreseeable expansion.
Features
Capture and display of supplementary information: The submission process involves, at a minimum, associating a sample bottle, usually by a lab number, to a particular lube point (and, hence, component and machine). The software should ensure that it is difficult to create "split histories" - i.e. more than one instance of a physical lube point in the database. To a database, "Conveyor 1" and "Conveyor_1" are two different entities. An auto-complete feature, drawing on existing machine names in the database, is a useful feature. The system must, therefore, differentiate between adding a sample to an existing lube point and creating a new lube point, component or machine.
If lab numbers are already pre-written on the sample bottle labels, a bar code on the label and a bar code reading device are useful features to have when associating a sample to a lube point.
The system should capture service meter readings (hours or miles) on the machine, on the oil, and when oil and filter changes have been performed.
Oil analysis is often compared to analyzing a blood sample. Blood contains much information for the doctor; likewise, oil contains much information about a machine. Part of the analogy is that when you go to the doctor, you explain your symptoms. This holds true for oil analysis, too. The system should be able to capture extra comments and make these available to the laboratory and diagnostic modules.
Laboratory error detection: For many various reasons, instruments sometimes give the wrong reading. The laboratory module should have some built-in "intelligence", either a reasonability test or a history-based statistical test, to determine if a reading looks out of place. Ultimately, it is the diagnostician's responsibility to ensure that the test results are credible; but there is only benefit to be had when some of the load is being shared by the system.
Baseline data: Oil samples can make a lot more sense when they are compared to samples of new oil. The software should have the ability to link a lube point to a record of such data. The baseline data should be prominently displayed during the diagnostic and reporting phases of the process.
Display of history: Oil analysis is a trending game. In many cases, the actual numbers you are analyzing are, in themselves, irrelevant; what is of more interest is how the numbers have changed from the previous samples. Thus, during the diagnostic process, it's of the utmost importance that the current sample test results are displayed against the previous three to five samples of history. Look for a system which displays all of the information on one page; switching between tabs and pages becomes tedious quickly, and affects concentration.
Representation of limits: An extremely useful feature of the diagnostic and reporting modules is to be able to set up limits. You should be able to set up limits for different groups of components (for example, gearboxes or hydraulics), but also for individual lube points. When the information is displayed during diagnostics or reporting, out-of-limit readings should be clearly highlighted. The types of limits that may be employed are beyond the scope of this article, but the suite should allow you to choose the correct limit type for different tests and readings.
Graphing features: A picture, it is said, is worth a thousand words. This is very true for oil analysis. The diagnostic and reporting modules should have access to graphing functions. The graphs displayed automatically should be able to be set up for component groups and individual lube points. And, the ability to quickly and easily pull together an ad-hoc graph for a particular sample is very useful.
The ability to choose between linear or semi-log plots is useful, as well. Consider the following readings of iron (Fe) and chromium (Cr) for an engine displaying top-end wear:
Graphically, this may be represented as:
The linear relationship makes the difference between Fe and Cr difficult to see. If the plot is changed to a semi-log one, the relationship becomes more obvious:
Commenting: Many times, the diagnostic function and reporting functions are carried out by different people. End-users should be able to at least attach comments to the report to convey extra information not contained in the diagnosis.
Reports
The system should have the ability to generate three basic types of reports:
• Abridged • Full • Statistical
An abridged report contains just the diagnosis and typically would be attached to a job card for maintenance personnel. The full report should contain the sample submission information, baseline oil data, sample history for at least the previous three samples, current test results, the diagnosis and graphs. The statistical report is a management report, probably generated on a month-by-month basis, and would contain information such as:
-
Number of samples analyzed
-
Number of normal, caution and critical reports
-
Machines which have abnormal samples and the past history of such data
The statistical report is a useful management-by-exception tool for detecting bad actors in the plant.
A report designer should be included in the suite to allow you to design reports according to your needs. The ability to attach a report type to a component group or an individual lube point should be standard.
A useful feature of a software suite is the ability to transmit a text alert to a mobile phone or personal digital assistant (PDA). Such a feature would alert end-users to situations requiring urgent intervention.
The reporting module also should be able to send reports automatically to multiple people based on the association of a person with a machine, or group of machines, in the hierarchy. When reports are sent to a single point of contact in an organization, there is always a risk that they will not get past that point to the end-user.
Purchasing an oil analysis software suite can be a daunting task. Before making the decision, make a list of your current requirements, keeping future expansion in mind. Then, embark on a systematic process of evaluating your choices against your requirements. Talk to potential vendors. You might have a good idea that would improve their product, and they will usually be happy to implement it, at least in a future release.
