Predictive Maintenance Technology

01Purpose and scope

• This manual supports the course Predictive Maintenance Technology. It is written for technicians, reliability engineers, maintenance planners and operators who are asked to move a plant or fleet from reactive repairs and fixed-interval servicing toward maintenance decisions based on measured equipment condition.
• The work covered here includes selecting monitored assets, choosing sensors and data sources, establishing baselines, detecting deviations, estimating how much time remains before a functional failure, and turning those estimates into work orders. It does not cover the mechanical repair procedures for specific machines, which belong in the equipment manufacturer documentation and the site work instructions.
• Predictive maintenance sits between condition monitoring, which tells you what the machine is doing now, and prognostics, which estimates what it will do later. In practice the two are used together. A monitoring program that never produces a usable forecast is still valuable, but a forecast that nobody trusts or acts on has no value at all.
• Where the equipment is safety related, regulated or connected to a process with serious consequences, this guidance does not replace qualified professional judgment, approved procedures or required authorization. Lockout, permit to work and any change to safety interlocks must follow the site rules, not the analysis in this manual.

02Core principles

• The first principle is that condition data only matters when it changes a decision. A vibration spectrum that shows a bearing defect is useful if it moves the bearing replacement into the next planned shutdown instead of letting it run to a failure during peak production. Every monitored point should have a named decision attached to it, such as rebuild, inspect, lubricate, shorten the interval or do nothing.
• The second principle is that a deviation is not automatically a fault. Machines vary with load, speed, ambient temperature, product mix and operator practice. A pump that runs warmer on a hot afternoon may be perfectly healthy. Good practice compares like with like, using operating context tags alongside the sensor data so that the baseline reflects the conditions the machine actually sees.
• The third principle is that failure modes come first and technology second. Before choosing an accelerometer, an oil particle counter or a thermal camera, the team should list the failure modes that matter for the asset, how each one develops, how long the warning period usually lasts, and how much the failure costs. The technique follows from that list.
• The fourth principle is that forecasts carry uncertainty. A remaining useful life estimate is a range that depends on the model, the data quality and the assumption that future operation resembles past operation. Report the range, state the basis for it, and revisit it when the duty cycle changes.

03Planning and preparation

• Start with an asset criticality review. Rank equipment by the cost and safety consequences of failure, the availability of spares, the time needed to repair, and the redundancy that already exists. A standby pump with a healthy twin does not need the same instrumentation as the single feed pump that stops a line. Many programs fail because they instrument everything at once, which produces data nobody has time to read.
• Next, map the failure modes for each selected asset. Use past work orders, failure reports and the knowledge of experienced operators. Mark which failure modes can be detected by a measurable signal, which ones can only be found by inspection, and which ones give no warning at all. Predictive maintenance is not the right tool for sudden failures with no precursor, and the plan should say so rather than promising coverage it cannot deliver.
• Then confirm the data path. Identify where each signal will come from: a permanently installed sensor, a portable data collector used on a route, a programmable logic controller tag, a building management system, or a laboratory oil analysis. Check sampling rates, time synchronization and whether the historian stores the raw values or only averages. Averaged data hides the short impacts that often precede bearing and gear failures.
• Establish baselines before expecting alarms to mean anything. A baseline needs enough healthy operation to capture normal variation across the usual operating states, often several weeks of data for a process machine and longer for equipment with seasonal load. The exact period depends on the machine, so set it from the operating history, not from a fixed rule of thumb.
• Finally, decide on tools and standards. Vibration severity guidance such as ISO 10816 series and condition monitoring guidance such as ISO 17359 give a common vocabulary for measurement and reporting, but they set general limits and do not replace asset-specific criteria. Confirm which edition and parts apply to your sites with the standards owner, since editions change and some local rules differ by jurisdiction.

04Recommended workflow

1. 1
   : Define the asset, its operating envelope and the decision each monitored point will support. Record the nominal speed, load range, temperature limits and any known operating modes such as startup, batch change or washdown. Write the decision next to the measurement so that the purpose of every data stream is clear to the person who will later review it.
2. 2
   : Install or connect the sensors and verify the signal before trusting it. For vibration, check mounting method, orientation and resonance; a magnetic mount on a painted surface can add false peaks. For temperature, confirm the sensor is in the intended location. Record the installation details in the asset record, including sensor serial number, mounting date in your own records system and the calibration basis.
3. 3
   : Collect and tag the data with operating context. Speed, load, flow, pressure, ambient temperature and product type are the minimum tags most analyses need. Without them, a rise in bearing temperature cannot be separated from a rise in throughput. Make sure timestamps from the monitoring system and the process control system are aligned.
4. 4
   : Build the baseline and set the initial alarm levels. Use the healthy period to estimate the normal range for each feature, such as overall velocity, selected spectral peaks, envelope values, oil particle counts or motor current harmonics. Set a first alert level at a statistically meaningful deviation and a second level at a point that calls for planned action. Document the method used so the levels can be reproduced.
5. 5
   : Analyze deviations and classify them. When an alert fires, check the data quality first, then the operating context, then the feature trend. Match the pattern to the known failure modes for the asset. Assign a confidence level to the diagnosis, for example low when only one indicator has moved and high when two independent measurements agree.
6. 6
   : Estimate the remaining time and recommend an action. Use the trend slope, historical failure data and the engineering judgment of the analyst to estimate when the condition will reach the level that requires intervention. Express the answer as a window with stated assumptions, not as a single date. Propose the action, the required parts and tools, the safe window for the work and the consequence of waiting.
7. 7
   : Plan the work and close the loop. Send the recommendation to maintenance planning, obtain approval through the usual channel, and schedule the job into an outage or low-consequence period. After the repair, inspect the removed component if possible and record what was found. That finding is the most valuable data point in the program because it confirms or corrects the diagnosis.

05Quality checks, risk controls and compliance

• Data quality checks should run before any analysis. Look for flat lines that indicate a stuck signal, sudden jumps that match a sensor reset, clipping at the input range of a data collector, and gaps caused by network failures. Many false alarms trace back to a loose cable or a sensor that was mounted on the wrong bearing housing, not to the machine itself.
• Use a documented review rule for every alarm. A common approach is to require at least two agreeing indicators, or one strong indicator plus a visual or inspection check, before recommending a major intervention. This is a risk control, because it limits both the cost of unnecessary teardowns and the chance of ignoring a real fault. The rule should be written down and reviewed periodically against outcomes.
• Track the accuracy of the program. For each predicted intervention, record whether the component was actually degraded, how severe the damage was, and whether the forecast window was correct. Keep false positives and missed failures visible. Avoid tuning alarm levels only to reduce the number of alerts, because that trades nuisance warnings for missed faults.
• Watch the cybersecurity and access controls for connected monitoring systems. Remote access to vibration data and control networks should follow the site information technology policy. Changes to alarm thresholds or to control logic should go through management of change, especially where a monitoring alarm can trigger an automatic shutdown.
• Compliance depends on where the equipment operates. Pressure equipment, lifting devices, electrical installations and workplace safety obligations are set by national, regional and local authorities, and the rules change over time. Use the current requirements from the authority having jurisdiction and your site safety function. Where a predictive forecast is used to extend an inspection interval on safety-critical equipment, the change requires the approval process that the regulation or site standard requires.

06Collaboration and documentation

• Predictive maintenance succeeds when the analyst, the planner, the operator and the reliability engineer share the same picture of the asset. Hold a short weekly review of open alerts with the people who can act on them. Operators often know about a process change or a recent adjustment that explains a trend, and that information should be recorded with the data rather than lost in conversation.
• Maintain an asset condition record for each monitored item. It should contain the sensor configuration, baseline period, alarm levels and their basis, the diagnosis history, recommendations made, decisions taken and the inspection results after repair. A new analyst should be able to pick up an asset and understand why the program looks the way it does.
• Write recommendations so that a planner can act on them without a second meeting. A good recommendation names the component, the suspected failure mode, the evidence, the confidence, the proposed window, the parts and the safety precautions. Avoid recommendations that say only that the machine looks worse.
• Define who owns each part of the program. The data team may own the historian and the sensor network, the reliability group may own diagnosis, and the maintenance supervisor may own scheduling. Unclear ownership is one of the most common reasons alerts go unanswered for weeks.

07Measures and continuous improvement

• Choose a small set of indicators and review them regularly. Useful measures include the percentage of monitored assets with a valid signal, the number of alerts that led to a confirmed fault, the number of failures that occurred without prior warning on monitored equipment, the average lead time between a confirmed alert and the repair, and the cost of unplanned downtime avoided. Be cautious with avoided-cost figures, since they depend on assumptions that should be stated.
• Compare predicted and found conditions after each repair. Over time this shows which features are reliable for which failure modes and which thresholds need adjustment. Retire sensors and features that never contribute to a decision, and add new ones only when a specific failure mode is not yet covered.
• Review the program after major changes in operation, such as a new product, a throughput increase or a change in lubricant specification. Baselines built under one duty cycle may not apply to another. Schedule a formal baseline refresh rather than letting alarms drift upward or downward unnoticed.
• Be realistic about the limits. Some machines have too few sensible measurement points, some failure modes develop in seconds, and some faults only show up under specific loads that rarely occur. In those cases a time-based inspection or a design change may be the better answer, and the program should recommend it.

08Common mistakes and how to prevent them

• The most frequent mistake is instrumenting too many assets before the first few have produced reliable decisions. Start with a small group of critical machines, prove the workflow, and expand once the team has closed several recommendations with inspection evidence.
• Another common error is setting alarm levels from manufacturer generic limits without checking the actual operating baseline. Generic limits are a starting point for discussion, not a finished alarm design. Compare them with the healthy data from the asset before publishing them.
• Teams also tend to trust a single feature. A rising overall vibration value can mean imbalance, misalignment, looseness or a bearing defect, and each calls for a different action. Require the analysis to show the feature that supports the diagnosis, not only the headline number.
• Finally, many programs stop at the alert. Without a clear owner, a planned window and a feedback loop, the monitoring system produces a record of warnings and little else. Make the closing step, from recommendation to repair to inspection, a mandatory part of the workflow.

09Practical checklist

• Confirm the asset is critical enough to justify monitoring and that its main failure modes have measurable precursors.
• Record the operating envelope and the decision each measurement will support.
• Verify sensor mounting, orientation, calibration basis and signal quality before accepting data.
• Tag all data with speed, load, flow, pressure, temperature or product context.
• Establish a baseline across the normal operating states and document the method.
• Set two alarm levels with a stated basis and a documented review rule.
• Check data quality before analyzing any alarm and assign a confidence level to each diagnosis.
• Express remaining time as a window with stated assumptions and propose a specific action.
• Route recommendations through the approved planning and safety process, including management of change where needed.
• Record inspection results after repair and compare them with the prediction.
• Review program accuracy, false alarms and missed failures on a fixed schedule.

★Learning sources

• Micro Degree: Predictive Maintenance Technology
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics