Predictive Maintenance (PdM) has been around for some time, but it is far from universal. It is sometimes referred to as condition-based maintenance, or CBM. Before the concept of PdM started to be developed, the norm was planned maintenance.
Planned maintenance, as the name implies, is maintenance carried out on a system according to a predetermined, fixed schedule. The schedule doesn’t have to be expressed in terms of time, although it often is. It can also be planned in terms of usage (distance, operating hours and such like) although there could only be limited allowance for the type of usage. For example a car manufacturer may call for more frequent air-cleaner filter replacement if the vehicle is routinely used in dusty conditions.
Planned maintenance schedules are dominated by preventive tasks, with corrective tasks being carried out as found to be necessary at service time. Corrective maintenance tasks would of course also be carried out between planned maintenance activities as and when the need arose.
The main snag with planned maintenance is that components were often stripped, overhauled and refitted, or simply replaced, when they actually had enough life in them to safely get through the next maintenance interval. It was natural, particularly on safety-critical systems, to err on the side of safety. The increasing sophistication and complexity of systems meant that through-life costs started to rise dramatically, a problem that was always going to be exacerbated so long as sub-systems and components were being replaced far sooner than was necessary.
PdM was introduced to try to maintain equipment at the right time (the ‘right time’ being determined by the collection and analysis of live health and usage data). This collection and analysis is known as condition monitoring, and involves the application of Health & Usage Monitoring Systems, or HUMS. These systems have themselves grown in their scope and they now involve extensive instrumentation of systems, sub-systems and components to measure and report vibration (frequency and amplitude), temperature (extremes, variations and variation cycles) and so forth.
This instrumentation does of course cost, and the rate of adoption of condition-based maintenance has had to be balanced against the potential savings to be made. These savings accrue not only from reduced numbers of replacements, but also from reduced downtime in fleets of equipment (sometimes measured in terms of TBOs – Time Between Overhauls). Some industries have moved more rapidly than others. For the aviation industry, maintenance costs are a driver of competitiveness which explains why aviation has made probably the greatest use of PdM to date. By contrast, the oil and gas industry for a long while limited its monitoring to the vibration affecting heavy, rotating components as it was not clear that the costs of doing anything more sophisticated could be recouped.
In recent years, as PdM has matured, the costs of its adoption have increasingly been outweighed by the savings to be made. If the parameters affecting a component through its life are able to be accurately measured then it becomes possible to conduct the task of calculating TBOs and life dynamically. Using the aviation industry as an example, we recall that in traditional methods of defining the maintenance policy for an aircraft the starting point was the operating spectrum expected for the aircraft type. This would vary depending on a customer’s intended role for the particular aircraft being purchased (for example an aircraft being used for search and rescue would have a markedly different lifecyle to one that was used for flying VIPs). Additionally,the operating spectrum is developed well before the aircraft goes into service and therefore has many assumptions.
From this operating spectrum the design authority can calculate safe limits for the inspection, overhaul and scrap lifes of components. These calculations are inherently conservative as the operating spectrum is assumed to be an average for the aircraft fleet. Therefore, certain variances needs to be allowed in order to maintain a safe operating limit.
However, utilising the logic for the calculation of the component lifes in a dynamic system, which is fed with the actual usage of the component, theoretically allows lifes to be extended. In effect, the lifing logic of the engineer has been embedded into the HUMS system which will then react according to the way the aircraft is actually used and not the way it is expected to be used.
One major problem to overcome for this type of solution to be certified is: what to do about missing data? It is highly likely that at some point there will be a system or process failure that will leave a hole in the data set used to calculate the current accumulated life of the component. Should the worst case automatically be assumed, or an average usage case or something else entirely?
Perhaps, in the near term, the best use for this type of system is to complement existing certified lifing methods to enable better engineering decision making. Having data from a dynamic lifing system for comparison with traditional, planned maintenance schedule life, may give confidence in the extension of maintenance lifes, while still operating with traditional life measures. This allows systems to mature in a real working environment and for operational experience to be gained to support the cost benefit case.
[This article was written in collaboration with Rob Russell, a Consultant Engineer at Critical Software Technologies Ltd, for submission to Instrumentation magazine.]