Install the package on the asset feed, set a vibration threshold, wait for the alerts to roll in. That is the deployment story most condition monitoring software is sold on, and it is also the story that gets the software muted within the first sprint. A pump changes duty cycle, a turbine ramps for a peak window, a compressor switches operating mode — and the threshold fires. The operator sees three alerts that turned out to be nothing, then a fourth, and by the end of the second week the alerting channel is on mute. The fault the software was supposed to catch arrives a month later, unannounced, because nobody is reading the screen any more. Condition monitoring software is not a dashboard you point at a sensor feed. It is a tuned anomaly pipeline, and the part that decides whether it works is not the model — it is the evidence around the model. Sensitivity calibration that proves the thresholds separate genuine faults from benign mode changes. Drift telemetry that tracks how a machine’s baseline shifts with age, load, and season. A false-positive review queue with a capacity the alert rate has to stay below. Without those artefacts, the software degrades into a noisy screen, and a noisy screen is functionally the same as no monitoring at all. How Does Condition Monitoring Software Work, and What Does It Mean in Practice? At its core the software ingests sensor data from rotating or fluid-handling equipment — vibration, temperature, acoustic emission, current draw, pressure, flow — and compares the live signal against a learned model of what “healthy” looks like for that specific asset under its specific operating conditions. When the live signal departs from the expected envelope by more than the configured sensitivity, it raises an anomaly. That is the mechanism, and stated that plainly it sounds trivial. The difficulty is that “healthy” is not one thing. A centrifugal pump has a different vibration signature at 60% load than at full load, and a different one again during start-up transients. A wind turbine’s drivetrain spectrum changes with wind speed and yaw position. The software’s job is not to flag every deviation from a single baseline — it is to separate a fault-class deviation (a developing bearing defect, a looseness fault, a misalignment) from an operating-mode deviation that is entirely benign. Get that separation wrong and you have built a false-alarm generator. This distinction between a real fault and a normal mode transition is the same separation problem at the heart of operational anomaly detection reliability, and the artefacts that keep an industrial anomaly system trustworthy are the same artefacts that keep condition monitoring software trustworthy. In practice this means the model is conditioned on operating context. Modern deployments tag each window of data with the regime it belongs to — load band, ambient conditions, recent state transitions — and evaluate the anomaly score against the baseline for that regime, not a global one. The naive deployment skips this step entirely, which is why it fires on every mode change. What Signals and Sensor Data Does the Software Use to Detect a Developing Fault? The signal set depends on the failure modes you care about. For rotating equipment, vibration is the workhorse: a developing bearing defect shows up as energy at specific frequencies (the bearing’s defect frequencies, which are computable from its geometry and shaft speed) long before it produces audible noise or heat. Spectral and envelope analysis — extracting those frequency bands rather than tracking a raw RMS level — is how the software detects the defect early rather than at failure. Beyond vibration, the practical signal set typically includes: Temperature — bearing housing, winding, lubricant — a lagging indicator but cheap and reliable for thermal faults. Motor current signature analysis — electrical faults and rotor-bar problems show up in the current spectrum without touching the mechanical side. Acoustic emission — high-frequency stress-wave energy that precedes vibration-detectable damage in some bearing and gear faults. Process variables — pressure, flow, and speed pulled from the control system, used not as fault detectors but as the context that tells the model which operating regime the asset is in. That last category is the one teams under-use. The process variables are what let the pipeline condition its baseline on operating mode. Treat vibration as the only input and you lose the context needed to suppress benign transitions — which puts you straight back into false-alarm territory. How Are Sensitivity Thresholds Set So the Software Distinguishes a Real Fault From a Normal Mode Change? This is where most deployments quietly fail. The vendor default threshold is a starting guess, not a calibration. Setting it correctly means working through a labelled history of the asset’s behaviour: known healthy periods across the full range of operating modes, and — ideally — at least one documented fault event to anchor the sensitivity at the other end. The artefact that proves this work was done is a sensitivity-calibration record. In our experience across reliability engagements, it answers three things: which operating regimes the baseline was trained on, what the false-positive rate was when the threshold was validated against held-out healthy data, and how the threshold trades detection sensitivity against alert volume (observed pattern across our deployments; the exact trade-off curve is asset-specific, not a portable benchmark). Without that record, a reviewer cannot tell a calibrated threshold from a default left untouched — and a threshold left at default is the single most common reason a deployment gets muted. The measurable target is concrete: the false-positive rate has to stay below the review queue’s triage capacity. If your operators can process ten alert reviews a day and the software generates forty, the system is broken regardless of how good the underlying model is. Calibration is the act of fitting the alert rate to the human capacity that has to absorb it. Drift Telemetry: What the Software Needs to Stay Accurate as the Asset Ages A baseline calibrated in March is not the same baseline you need in August. Machines age — bearings wear in, lubricant degrades, clearances open up — and duty cycles shift with seasonal demand. A model that does not track this drift will, over months, either start firing on the asset’s new normal or stop firing because the new normal has crept up to where the old threshold sat. Drift telemetry is the running record of how the asset’s baseline is moving relative to the model’s expectation. It is the same discipline that governs model drift detection in production AI — the question of which signals and thresholds tell you the model’s reference has gone stale — applied to a physical asset whose “ground truth” is itself moving. The artefact distinguishes two drift sources that demand different responses: baseline drift you should adapt to (gradual wear, seasonal load) and baseline drift you should alarm on (the actual developing fault). Conflate them and the model either chases the fault into its own baseline or treats normal ageing as a failure. The operational signal that drift telemetry is doing its job is stable detection performance over time: mean-time-to-detect on genuine faults holding steady at six months rather than degrading as the calibration goes stale. Why the False-Positive Review Queue Decides Whether Operators Keep Trusting the Software Trust in a monitoring system is not earned by catching faults. It is lost by crying wolf. Every false positive an operator investigates and finds to be nothing spends a small amount of their willingness to look at the next alert. Spend that budget faster than the system replenishes it with genuine catches, and the operators stop looking — quietly, without anyone deciding to turn the system off. The false-positive review queue is the artefact that makes this dynamic visible and governable. It is the place every alert lands, gets triaged, and gets labelled — true fault, benign mode change, sensor artefact. That labelling does double duty: it protects operator trust in the short term and feeds the recalibration loop in the long term. The proportion of alerts that survive review — that turn out to be real rather than being dismissed as noise — is the health metric for the whole deployment. Condition monitoring software paired with calibration and drift artefacts keeps operators acting on alerts six months and more past go-live (observed across our reliability engagements; not a published benchmark), where uncalibrated deployments are muted within the first sprint. How Does It Integrate With an Existing SCADA or Historian Stack? Operators do not want a second screen. A condition monitoring layer that lives outside the control room workflow gets checked at first, then forgotten. The integration pattern that survives is one where the anomaly pipeline reads from the same historian or SCADA stack the operators already use — pulling process variables for context, writing anomalies back as tagged events the existing alarm management can route — rather than standing up a parallel monitoring island. Practically, that means the software consumes from a historian (an OSIsoft PI-class system, a time-series store, or the SCADA tag database directly) and emits anomalies into the channel operators already watch. The pipeline itself — the windowing, regime tagging, spectral analysis, and anomaly scoring — runs as a separate service, but its outputs land where the human already is. We pay close attention to this in deployment because the best-calibrated model in the world is worthless if it asks the operator to leave their workflow to read it. Where Is the Line Between Condition Monitoring Software and a Predictive-Maintenance Programme? Condition monitoring software answers is something wrong, and what. A predictive-maintenance programme answers when will it fail, and what should we do about it — adding remaining-useful-life estimation, maintenance scheduling, spares logistics, and a closed loop between detection and work orders. The software is a component of the programme, not a substitute for it. Condition monitoring software Predictive-maintenance programme Primary question Is this asset deviating from healthy? When will it fail and what do we do? Core artefacts Sensitivity calibration, drift telemetry, false-positive queue The above, plus RUL models, maintenance scheduling, work-order integration Output Tagged anomalies, fault-class flags Prioritised maintenance actions with lead time Human in the loop Operator triages alerts Reliability engineer plans interventions Failure if missing Faults go undetected Faults detected but not acted on coherently Buying predictive-maintenance vocabulary while deploying threshold-on-a-feed software is a common procurement mismatch. The reverse mistake — deploying well-calibrated condition monitoring and then having no process to act on the alerts — wastes the detection entirely. Free and Open-Source Tools, Wireless and Online Deployments There are open-source and free condition monitoring tools, and they can be a reasonable starting point for the signal-processing core — spectral analysis, envelope detection, basic anomaly scoring are well-served by open libraries. What a free tool does not give you is the calibration and drift-artefact work. The sensitivity-calibration record, the regime-conditioned baseline, the drift telemetry, the review-queue process — those are engineering work the operator does regardless of whether the underlying code was free. The cost of condition monitoring was never the software licence; it is the calibration evidence that makes the alerts trustworthy. That same cost-versus-trust logic is why AI-driven operational anomaly detection earns its cost only when the artefacts are in place, a point the energy vertical makes concretely on turbines and rotating energy assets. Wireless and online deployments differ mainly in the telemetry envelope they feed the pipeline. Online (permanently wired) sensors deliver continuous high-frequency data — enough for full spectral and envelope analysis, drift tracking, and early detection. Wireless sensors trade sampling rate and continuity for installation cost and reach, typically delivering periodic snapshots rather than a continuous stream. That changes what the anomaly pipeline can see: a wireless deployment may catch a slow-developing bearing fault but miss a transient that a continuous online channel would resolve. Neither is wrong — but the calibration has to be honest about what the data rate can and cannot detect, and the drift telemetry has to account for the sampling gaps. FAQ How does condition monitoring software work, and what does it mean in practice? It ingests sensor data — vibration, temperature, current, acoustic, plus process variables for context — and compares the live signal against a learned model of healthy behaviour for that specific asset under its specific operating regime. In practice the hard part is separating a fault-class deviation from a benign operating-mode change, which is why the model has to be conditioned on operating context rather than compared to a single global baseline. What signals and sensor data does condition monitoring software use to detect a developing fault? Vibration is the workhorse for rotating equipment because bearing and gear defects show up at computable defect frequencies long before they produce heat or noise. Temperature, motor current signature analysis, and acoustic emission add coverage of thermal and electrical faults, while process variables (pressure, flow, speed from the control system) provide the operating-regime context that lets the pipeline suppress benign transitions. How are sensitivity thresholds set so the software distinguishes a real fault from a normal operating-mode change? By calibrating against a labelled history of the asset across its full range of operating modes, ideally anchored by at least one documented fault event. The sensitivity-calibration record proves the threshold was fitted — which regimes the baseline covers, the validated false-positive rate, and the sensitivity-versus-alert-volume trade-off — rather than left at a vendor default. The non-negotiable constraint is that the false-positive rate stays below the review queue’s triage capacity. What drift telemetry does condition monitoring software need to stay accurate as an asset ages or its duty cycle shifts? A running record of how the asset’s baseline moves relative to the model’s expectation, distinguishing drift to adapt to (gradual wear, seasonal load) from drift to alarm on (the developing fault itself). Without it the model either chases a real fault into its own baseline or treats normal ageing as a failure. The signal that drift telemetry is working is stable mean-time-to-detect over six months rather than degrading detection as the calibration goes stale. Why does the false-positive review queue determine whether operators keep trusting the software? Trust is lost by crying wolf: every false alarm an operator investigates spends a little of their willingness to look at the next one. The review queue makes this visible — every alert is triaged and labelled true fault, benign mode change, or sensor artefact — which protects trust now and feeds recalibration later. The proportion of alerts that survive review rather than being dismissed as noise is the health metric for the whole deployment. How does condition monitoring software integrate with an existing SCADA or historian stack without pulling operators out of their workflow? The pipeline reads from the historian or SCADA stack operators already use — pulling process variables for context and writing anomalies back as tagged events the existing alarm management routes — rather than standing up a parallel monitoring island. The anomaly scoring runs as a separate service, but its outputs land in the channel the operator already watches, because a well-calibrated model is worthless if it asks the operator to leave their workflow. Where is the line between condition monitoring software and a full predictive-maintenance programme? Condition monitoring software answers “is something wrong, and what”; a predictive-maintenance programme answers “when will it fail and what should we do,” adding remaining-useful-life models, maintenance scheduling, and work-order integration. The software is a component of the programme, not a substitute for it, and confusing the two is a common procurement mismatch. Is there free or open-source condition monitoring software, and what calibration and drift-artefact work does a free tool still leave the operator to do? Open-source tools serve the signal-processing core — spectral analysis, envelope detection, basic anomaly scoring — perfectly well. What they do not provide is the sensitivity-calibration record, the regime-conditioned baseline, the drift telemetry, and the review-queue process, all of which are engineering work the operator owns regardless of licence cost. The cost of condition monitoring was never the software; it is the calibration evidence that makes the alerts trustworthy. How do wireless and online condition monitoring deployments differ in the sensor and telemetry signals they feed the anomaly pipeline? Online (wired) sensors deliver continuous high-frequency data, enough for full spectral and envelope analysis and reliable drift tracking; wireless sensors trade sampling rate and continuity for installation cost and reach, typically delivering periodic snapshots. That difference changes what the pipeline can detect — a wireless deployment may catch a slow-developing fault but miss a transient an online channel resolves — so the calibration must be honest about what the data rate can and cannot see. Most condition monitoring software deployments do not fail because the model was bad. They fail because the thresholds were left at defaults, the drift went untracked, and the alert rate outran the people who had to read it. Whether you are evaluating a packaged tool or building the pipeline yourself, the question to ask first is not “how good is the anomaly detection” but “where is the evidence that the sensitivity is calibrated and the drift is tracked” — the same documented sign-off discipline that anchors production AI reliability as an engineering practice. That evidence is what an operational-anomaly validation pack exists to capture, and it is the difference between a system operators still trust at six months and a muted screen nobody reads.
