Vibration condition monitoring software needs to know what normal looks like in each operating mode to tell a developing fault from an operating-mode change. A static threshold cannot do this. A vibration spike from a load surge and one from a developing bearing fault look identical to a threshold-based alarm, so the system fires on both. We would build software operators keep trusting around four things. It starts from standards-based thresholds tuned to each machine’s baseline, extracts features that isolate fault frequencies, checks across signals before it alerts, and runs a review loop that records how many alerts turn out to be real.
The maintenance practice behind condition monitoring has its own explainer. What follows covers the software layer and the evidence that keeps its thresholds honest.
How does vibration condition monitoring software work, and how does it separate a fault from a mode change?
Machines exhibit a characteristic, acceptable vibration signature. What counts as acceptable depends on the type of equipment, its operating conditions and even environmental variables such as temperature or humidity, and when an anomaly develops the signature changes. The same machine can also vibrate at different levels under different load, speed and environment, and equipment connected upstream or downstream can affect it. The signal that carries the fault also carries the operating mode.
Vibration analysis converts the signal into diagnostic features. In the time domain these are statistical parameters such as root mean square, peak-to-peak, kurtosis and crest factor. In the frequency domain, the amplitude of each fault frequency is trended over time. An FFT shows how vibration energy is spread across frequencies: a dominant 1x running-speed peak usually indicates imbalance, while sidebands around a gear-mesh frequency suggest gear problems. Bearing impacts are isolated with envelope detection. The software band-pass filters the raw signal around a high-frequency band (typically 5 to 40 kHz), rectifies it, and runs an FFT on the envelope to expose the lower bearing-defect frequencies.
A worn outer race excites high-frequency bands spaced at the outer-race defect frequency.
Corroboration across signal types
A single sensor has no way to tell a genuine fault from normal process variation. The architectural answer is to require agreement across several signal types before an alert fires. A vibration anomaly with no matching change in temperature, current or ultrasound is far more likely to be a transient. An anomaly that appears at the same time on two or three channels is far more likely to be real. Tractian’s alert-fatigue glossary claims this cross-domain validation brings false-positive rates down from the 40 to 60 percent range typical of single-signal threshold systems to below 10 percent.
Diagnosticians apply the same logic by hand, cross-checking a suspect reading against load, speed variation and the behaviour of adjacent components. Software can encode it as rate-of-change and multi-parameter confirmation rules that must pass before an automated work order is created.
What sensor data does the software need to catch a developing fault?
Vibration exposes mechanical faults before failure. Temperature, current and ultrasound serve as corroborating evidence. The accelerometer is the standard vibration transducer because its output can be integrated once or twice to give velocity or displacement. Honeywell’s introduction to vibration monitoring gives accelerometers good accuracy between 10 Hz and 10 kHz. It also notes that the mounting method shapes the frequency response, because the contact between sensor and machine acts as a mechanical low-pass filter, and high-frequency content is the first to be lost.
The sensor’s frequency range determines which faults show up. Renkeer’s guide to frequency response puts imbalance, misalignment and looseness at tens to several hundred hertz. Early bearing and gear faults (poor lubrication, pitting, spalling, tooth wear) sit at several kilohertz or higher. The same guide holds that accelerometers generally need an upper frequency limit of no less than 10 kHz. It places bearing lubrication deficiency at roughly 3,000 to 10,000 Hz.
The primary quantity in the ISO vibration standards, RMS overall velocity, stops at 1 kHz. Ludeca points out that RMS overall velocity from 10 Hz to 1 kHz gauges unbalance, misalignment and looseness fairly well, but may not give early enough warning for several failure modes, and in many cases not for bearing defects.
Sampling has to match the highest frequency you want to analyse. Nyquist sets the floor at twice the highest frequency of interest, but anti-aliasing filters have a transition band, so engineering practice samples at 2.56 times that frequency or higher. Analysing up to 10 kHz therefore means sampling at 25.6 kHz or more (10 kHz × 2.56).
Oil particle counting adds another view of wear. Machinery Lubrication calls particle counting, which measures the number and size distribution of particles in an oil sample, the single most important test in used-oil analysis, useful for spotting abrasive bearing wear and abnormal gear wear. Proximity probes measure shaft vibration relative to the bearing seat, where accelerometers and velocity sensors measure housing vibration relative to the ground. The hardware side of this, sensor by sensor, is covered in the guide to condition monitoring equipment.
| Input | What it reveals | What the software needs from it |
|---|---|---|
| Accelerometer, overall velocity (about 10 Hz to 1 kHz) | Unbalance, misalignment, looseness | Trend against a per-machine, per-mode baseline |
| Accelerometer, high-frequency band and envelope | Early bearing and gear defects | Sensor response of at least 10 kHz, sampling at 2.56x or more |
| Proximity probe | Shaft motion relative to the bearing | Mounted at or near the main bearings |
| Temperature, current, ultrasound | Corroboration that a vibration change is a real fault | Time alignment with the vibration channel |
| Oil particle count | Abrasive bearing wear, abnormal gear wear | Samples from the correct location and procedure |
How are sensitivity thresholds set so a normal operating-mode change doesn’t trip an alarm?
Start from a standard, then tune to the machine. A Reliamag guide to vibration analysis treats the ISO 20816 severity zones (A/B/C/D) as useful starting points for alarm thresholds, to be refined against each machine’s baseline and operational criticality. ISO 20816 states its general criteria in terms of both vibration magnitude and change of vibration, and gives guidelines for setting operational limits. A part of ISO 20816 explicitly covers non-steady-state conditions, including run-up, run-down, initial loading and load changes. ISO 10816-3 applies to machine sets with a power above 15 kW.
Standards are a starting value, not the answer. Delprete and Gastaldi (Proc IMechE Part O) tested, on two test cases, whether thresholds from several international standards work as starting values. They found general agreement on order of magnitude, with differences between standards in how conservative they are. They also note that estimating thresholds is hard when the manufacturer provides no data, or when the machine is not new and no measurement history exists yet.
Static thresholds set at commissioning rarely allow for normal process variation, seasonal load shifts or equipment ageing. A vibration limit calibrated for a pump at 80 percent load will raise nuisance alarms when the pump runs at full load during peak production, even though nothing is wrong. Over time, technicians learn to dismiss those alarms by default. A 2019 study in Energies found the same in wind-turbine gearboxes: under variable speed and load, a fixed threshold gives high false alarms and missed detections, and its proposed method improved detection accuracy and reliability over it.
We would make the threshold depend on operating mode explicitly. That means separate baselines for each speed or load band, thresholds drawn from each, and the mode signal (speed, load or process state) fed into the software so it knows which baseline applies at any moment.
For learned detectors, the threshold should be a calibrated decision. A 2026 study in Scientific Reports calibrated anomaly scores into probabilities with Platt scaling, then set thresholds under an explicit false-alarm budget. Its authors argue that calibration turns the threshold into a policy variable rather than an arbitrary tuning knob. They measure nuisance alarms as false alarms per hour of fault-free operation, counting a prolonged excursion as one alert. The study used the simulated Tennessee Eastman chemical process rather than vibration data. Its reported scores do not transfer to rotating equipment. The record of how a threshold was chosen has value of its own, and documenting sensitivity-tuning evidence for reviewer sign-off covers what that record should contain.
Worked example: the baseline-multiple rule
Emerson’s user guide for its AMS Wireless Vibration Monitor gives a rule of thumb that assumes the equipment is in good condition when measured. It sets Advisory at 2x the current value (or at least 0.05 in/s RMS, whichever is greater), Maintenance at 4x and Failed at 8x. With a current overall velocity of 0.1 in/s, the thresholds come out at 0.2, 0.4 and 0.8 in/s. For PeakVue on rolling-element bearings turning between 900 and 4,000 CPM, the guide uses a “rule of 10s”: 10 g Advisory, 20 g Maintenance, 40 g Failed.
We read the rule as assuming the “current value” was measured in one operating mode. Measure the baseline at part load and a normal move to full load raises nuisance alarms. Applying the multiples per mode closes that gap.
Why the false-positive review queue decides whether operators keep trusting alerts
Alert fatigue is the desensitisation of technicians and operators caused by too many alarms, high false-positive rates or poor prioritisation. Once alerts outnumber what a team can meaningfully process, critical alarms are missed, delayed or dismissed along with the nuisance ones. A nuisance alarm is any alarm that activates without requiring operator action, and when nuisance alarms dominate the queue, technicians eventually stop reviewing altogether. For a sense of scale, the EEMUA 191 alarm-management guidance recommends no more than one alarm per ten minutes per operator during steady-state operation.
Operators adjust their responses to how reliable alarms are. A 2025 paper in Reliability Engineering & System Safety reviews experiments where most participants matched their response rate to the expected probability of a true alarm, and some adopted all-or-none strategies. The authors propose the false discovery rate (the share of alarms that are false) as the metric for this “cry-wolf” effect, along with a method for controlling it at each prediction.
The proportion of alerts that survive review is the number operators carry in their heads, so the review queue is where condition monitoring software either earns its place or gets muted. A useful queue does more than clear alerts. We would have each dismissal record its reason (mode change, sensor fault, transient, genuine fault) and feed those labels back into the per-mode thresholds. Two further disciplines help. Alarm rationalisation checks that every configured alarm has a defined cause, consequence and required action. Priority tiers should reflect consequence severity and the time available to respond, not just how large the deviation is. Practical deployment pairs machine-learning outputs with human review and domain rules to build trust in automated diagnostics.
Our pages on anomaly detection reliability artefacts, the false-positive review queue as an evidence artefact and the alert-mute failure mode go further into each.
How often should condition monitoring data be collected for critical equipment?
The interval should follow how fast the failure develops. One condition monitoring guide uses the P-F interval, the time between when a potential failure first becomes detectable and when functional failure occurs, to set sampling intervals. It cites a common rule of thumb: sample at no more than half the estimated P-F interval. Honeywell’s guide frames the same constraint from the planning side: an intermittent monitoring interval must be shorter than the minimum lead time needed for maintenance and production planning.
Critical assets benefit from continuous monitoring. Online continuous and scanning systems detect failures at point P, removing the lag built into periodic sampling. For critical and essential assets where a missed failure is not tolerable, they are often justified. Critical machines often carry permanently mounted sensors so that they can be shut down quickly when a sudden change could precede catastrophic failure. Less critical assets typically get weekly or monthly route-based collection.
The interval should also tighten as condition worsens. NASA’s reliability-centred maintenance guide says a fan at 0.2 in/s overall vibration is closer to functional failure than an identical fan at 0.1 in/s and should be monitored more often. Once the Alert limit is exceeded, the guide reduces the interval to between a third and a quarter of the previous one, so quarterly collection becomes every three to four weeks, and it lengthens the interval again if readings stabilise. We would have route software apply this rule automatically. Software that only displays readings leaves it to someone’s memory.
Online, wireless and remote set-ups feed the software different data
The set-up decides what reaches the anomaly pipeline: continuous measurements, periodic updates, or route snapshots.
Wireless monitors are self-contained and constrained by battery. ABB’s WiMon 100 combines a vibration sensor, a temperature sensor, a long-life battery and a WirelessHART radio. It reports velocity over 10 Hz to 1 kHz and envelope with a 500 Hz to 10 kHz filter, and stores waveforms alongside velocity, envelope and temperature values. Emerson’s AMS Wireless Vibration Monitor uses MEMS accelerometers, with the high-bandwidth Z axis as the primary sensor. Its default update rate is once every 60 minutes, and Emerson advises against faster rates because they significantly reduce battery life. The rate can be set anywhere from one minute to 24 hours.
| Set-up | What the software receives | Where it fits |
|---|---|---|
| Online, permanently wired | Continuous or scanned measurements, detection at point P | Critical assets where a missed failure is not tolerable |
| Wireless sensor network | Summary values (velocity, envelope, temperature) at a configured update rate, with stored waveforms | Hard-to-reach rotating equipment |
| Route-based, intermittent | Snapshots from one sensor and data logger across many machines | Less critical assets on weekly or monthly routes |
The wireless row has a consequence for the anomaly pipeline. We would match each hourly summary value to the operating mode at the moment of measurement. We treat “remote” condition monitoring as where analysis and review happen, and any of the three set-ups can feed a remote centre. What changes is how much context travels with each reading.
Drift telemetry that keeps thresholds valid as the asset ages
Thresholds go out of date as the asset ages, the load shifts and sensors drift. Commissioning thresholds rarely account for seasonal load shifts or equipment ageing. For model-based detection, the Scientific Reports study warns that model-plant mismatch, parameter drift, sensor bias or unmodelled dynamics distort the residual signal, and with it both detection and threshold governance. Its recommended routine is to track early-warning delay and nuisance alarms per hour as health indicators, then update thresholds or recalibrate when drift is detected. Sensors need the same attention: a piezoelectric accelerometer’s output can drift over time, which normally calls for calibration every year or two.
In practice, the drift telemetry we would want logged next to the alerts is short:
- the per-mode baselines, each with a version and the date it was measured;
- false alarms per hour and the share of alerts surviving review, trended by asset and by mode;
- sensor calibration dates and any mounting changes, since the mounting method sets the high-frequency cutoff;
- every threshold change, with the review-queue evidence that prompted it.
We would make every threshold change traceable to the baseline and calibration data behind it. Versioning condition monitoring evidence with W&B Artifacts shows one way to do it. The broader question of what drift telemetry an anomaly system needs beyond a classical model is covered separately.
How does condition monitoring software plug into SCADA or a historian without pulling operators out of their workflow?
The sources say less about integration than about thresholds, so what follows is mostly our judgement. Some vendor devices already expose alerts through existing host systems. Emerson’s monitor sets HART status bits when measured values exceed configured thresholds, and its alerts can be viewed in AMS Device Manager or another graphical host.
We would integrate in both directions. Reading speed, load and process-state tags from SCADA or the historian is how we would make per-mode thresholds possible. Writing alerts back into the existing alarm system, with priority tiers, avoids a second screen that operators learn to ignore. Each alert should also arrive with its evidence attached, because control-room engineers need to see that an alarm is linked to specific sensors and time spans.
Is there free condition monitoring software, and what does it leave the maintenance team to do?
Yes. MDCplus keeps a list of free and open-source tools that can ingest vibration or related telemetry and support condition monitoring or anomaly detection. Each tool on it meets at least one criterion: it ingests vibration or related telemetry, is open source or has a permanently free tier, or runs on standard IT infrastructure rather than a proprietary analyser. Its list includes general platforms such as Python and GNU Octave, which let teams treat vibration as a time series that is streamed, stored and analysed continuously.
Free tools cover streaming, storage, dashboards and analysis code. We count the parts that decide whether alerts are trusted as left to the maintenance team. That includes sensor calibration, where the schedule depends on the application, the environment and the required accuracy; according to Sensoteq’s CTO writing in CBM Connect, MEMS sensors need less frequent recalibration than piezoelectric ones. It includes mounting quality, which sets the high-frequency cutoff of what the sensor picks up. It also includes per-mode baselines, threshold governance, the review queue and drift tracking, which we would set up for each machine. Delprete and Gastaldi note that even larger companies with a condition monitoring system in place often lack a systematic implementation and deployment strategy.
Where condition monitoring software ends and a predictive-maintenance programme begins
Condition-based maintenance is often described in three steps: data acquisition, data processing and decision making. We place condition monitoring software across the first two steps, supplying evidence for the third. A predictive-maintenance programme owns the decisions. Those decisions start earlier than the software: failure mode and effects analysis determines which technologies and measurement points are needed to catch each potential failure early. A CMMS tracks equipment history to reveal failure patterns and life-cycle cost. The prediction itself has error bounds, a probability of detection and a probability of false alarm.
That split shows what to ask a vendor. Ask for the per-mode baseline, the nuisance-alarm rate the thresholds were tuned against, and the trigger for recalibration. The feature list matters less, because those three artefacts decide whether alerts are still being acted on months after go-live. See also a worked example of an industrial anomaly system kept in use for more than six months. For how this engineering applies on production lines and plant equipment, see AI engineering for manufacturing and automotive.
FAQ
What is the difference between CBM and TBM?
Condition-based maintenance (CBM) carries out tasks when the measured condition shows they are needed. Time-based maintenance (TBM) runs tasks on a fixed calendar or runtime schedule, whatever the asset’s condition.
What does a false positive alarm mean?
A false positive is an alarm that fires without a fault behind it. In alarm-management terms it is a nuisance alarm: one that needs no operator action, such as an alarm that clears itself, fires on a transient, or comes from a threshold set too conservatively.
