Condition-based maintenance means acting when a measured condition, usually vibration or temperature at a bearing housing, crosses a limit set for that machine. Predictive maintenance goes one step further and forecasts when that limit will be reached. Both rest on the same foundation: a threshold you can justify, a data path that keeps the early signal, alerts that can tell a dead sensor from a failing bearing, and records that still hold when an auditor asks how you know. For rotating machines, ISO 20816-3 provides the zone limits and an alarm rule built on each machine’s own steady baseline. That is the right place to start.
The rest is engineering. High-rate data has to be reduced at the edge without throwing away the fault signature, silence has to be monitored as a signal in its own right, and the log has to be stored so its integrity can be shown years later. This pipeline sits underneath maintenance work in AI engineering for manufacturing and automotive: models, dashboards and maintenance plans built on it inherit whatever it gets wrong.
Condition-based maintenance vs predictive maintenance on a production line
The practical difference is what triggers the work order. Under condition-based maintenance, an indicator crossing an alarm limit triggers inspection or repair. Under predictive maintenance, a model estimates remaining useful life and the work is scheduled against that estimate. Predictive maintenance therefore needs everything condition-based maintenance needs, plus enough failure history to forecast from. A plant without trustworthy condition thresholds is rarely ready for remaining-useful-life models.
Which assets justify condition-based maintenance over fixed schedules?
Condition monitoring pays off where a failure mode gives measurable warning and an unplanned stop costs more than the monitoring does. Bearing damage is the classic case: vibration analysis can pick it up while the defect on the raceway is still microscopic, well before the machine breaks down. ISO 20816-3, the vibration severity standard for industrial machines, covers machines above 15 kW running between 120 and 30,000 rpm.
| Asset situation | Sensible strategy | Reason |
|---|---|---|
| Critical rotating machine (spindle, gearbox, compressor) with a known vibration signature | Condition-based, with thresholds set for that machine | Early warning exists and an unplanned stop is expensive |
| Low-criticality, redundant or cheap to replace | Time-based or run-to-failure, plus the vendor dashboard if one is already installed | Monitoring costs more than it saves |
| Failure mode with no measurable precursor | Time-based | There is nothing to set a threshold on |
| Fleet of similar assets with years of failure records | Predictive (remaining useful life) on top of condition thresholds | Forecasting needs failure history |
Can a vendor’s vibration condition monitoring dashboard catch early bearing wear?
If an asset is low-criticality and the vendor’s limits have been checked against that machine’s own baseline, the dashboard alone may be enough. For more critical spindles and gearboxes, machine-specific thresholds and envelope features belong on top.
LynxBenchAI benchmarks AI throughput, latency, memory and energy on candidate hardware, from laptop CPUs to data-centre GPUs.
TechnoLynx treats this as an engineering job. It starts by defining, for each CNC machine or gearbox, the failure modes that matter (bearing wear, misalignment) and how much warning each one needs. It then chooses sensor types, placement and sampling, decides between simple thresholds and envelope or FFT features, and builds the acquisition and feature-extraction pipeline for the edge hardware. Finally it checks the thresholds against data from known-good and known-faulty running before the alerts go into the maintenance workflow.
Early bearing defects hide among other frequencies and need signal processing to stand out from the noise. Acceleration enveloping does this in two stages. A band-pass filter isolates the frequencies where the defect signal sits, then an enveloper demodulates the result to extract how often the impacts repeat, so the defect stands out from the noise.
Reading the signal takes skill and experience as well as detecting it. A bearing’s vibration amplitude can drop as its condition gets worse, because the defect wears slightly smoother. A novice reads that as wear stopping, when in fact the bearing is still deteriorating. A generic alarm that only watches for rising levels cannot know this.
A spreadsheet has no alerting, so detection depends on someone opening it at the right moment. Accelerometers also need to be chosen for the frequency range of the particular machine. Sensor choice and mounting are covered in more depth in specifying sensor instrumentation and data infrastructure for predictive maintenance.
Alarm and trip limits for a specific machine under ISO 20816-3
ISO 20816 is the current standard for judging machine vibration from measurements on non-rotating parts. Part 3 replaced ISO 10816-3 for industrial machines. It uses broadband RMS velocity in mm/s, measured on the bearing housing over 10 to 1,000 Hz (2 to 1,000 Hz for machines below 600 r/min) in two perpendicular radial directions. The highest radial value sets the zone. There are four zones: A for newly commissioned machines, B for unrestricted long-term running, C for limited running until a repair can be scheduled, and D for vibration likely to cause damage.
Limits depend on the machine group and on how stiff the support is. Groups are set by power and shaft height (Group 1 above 300 kW, Group 2 from 15 to 300 kW), and rigid foundations carry lower limits than flexible ones. Getting the group or support type wrong is the most common source of misapplied vibration alarms.
| Machine group, rigid support | Zone A/B boundary | Zone B/C boundary | Zone C/D boundary |
|---|---|---|---|
| Group 1 (above 300 kW) | 2.3 mm/s | 4.5 mm/s | 7.1 mm/s |
| Group 2 (15 to 300 kW) | 1.4 mm/s | 2.8 mm/s | 4.5 mm/s |
The alarm rule is where the standard meets the individual machine:
- Set ALARM at the machine’s own steady baseline plus 25% of the upper limit of Zone B, and normally no higher than 1.25 times that Zone B limit.
- Worked case from the standard’s summary: a Group 2 motor on a rigid base has a Zone B limit of 2.8 mm/s, so the step is 0.7 mm/s. A baseline of 1.2 mm/s gives an alarm at 1.9 mm/s, and no alarm should sit above 3.5 mm/s.
- TRIP limits protect mechanical integrity and do not follow the baseline. Keep them no higher than 1.25 times the upper limit of Zone C: 5.6 mm/s for Group 2 rigid and 8.9 mm/s for Group 1 rigid.
- Any step change, up or down, larger than 25% of the Zone B/C boundary (0.7 mm/s for Group 2 rigid, 1.1 mm/s for Group 1 rigid) calls for a diagnostic check even if the zone has not changed.
- Revise the alarm whenever the baseline changes, for example after an overhaul.
Two cautions apply. First, the baseline has to be collected on the specific machine before alarms are configured, and one monitoring guide allows 30 days for it. Second, an over-tight alarm floods the team while a loose one misses early wear. Separately, any large step change calls for a diagnostic check before the zone changes.
Should alarm thresholds come from OEM degradation curves or the machine’s own baseline?
Use the machine’s own history as the reference, and treat OEM degradation curves as a starting assumption to calibrate against, not as a replacement. ISO 20816-3 already works this way: its alarm rule starts from the machine’s steady baseline and uses the zone limit as a cap. An OEM curve is not drawn from your particular unit. It may not reflect a particular site’s conditions and maintenance history.
TechnoLynx builds per-asset baseline and threshold monitoring of this kind through its Production AI Monitoring Harness.
The harder case is a single unit with no peers. Fleet methods remove farm-wide and seasonal effects by subtracting the median of the same signal across similar machines. A 2023 review in Wind Energy Science describes the technique and notes that it only models normal behaviour while more than half the fleet is behaving normally. A single machine has no fleet median to subtract.
What takes its place is a normal behaviour model. You train it on healthy history so it predicts what the signal should be, and treat a large gap between prediction and observation as evidence of a problem. The alarm threshold then comes from how the prediction error is distributed under healthy conditions. Different speeds and loads produce different vibration, so comparing against a baseline only works when the measurements share the same speed and load. A PHME 2018 gearbox study mapped each condition indicator across operating regimes and threw out unsteady data (changes of more than 2 rpm or 2% valve position across a four-point window). New readings were then normalised against the limit for their own regime.
Wind turbine monitoring studies group their inputs into environmental signals such as outside temperature, operational signals such as active power, and component temperatures. A normal behaviour model can use the environmental and operational signals as predictors of the component signal. Where the physics of a failure mode is understood, measuring the residual against a physics-based expectation gives a sturdier threshold than a purely statistical baseline fitted to a short history.
Avoiding false alarms without missing real degradation
History length comes first. The review’s own experiments trained on the first six months of healthy data per turbine. Cutting that to two months reduced performance, especially for rare states such as long cool-downs. A threshold fitted to a short window also risks treating a slow degradation trend as normal baseline.
Every detector trades false alarms against missed failures. In the same review, the IOD-MAD method caught three of four generator bearing replacements but raised more flags that could not be tied to a failure, while CUSUM caught two of four and looked too insensitive. With so few failure examples, tuning the trade-off is hard. Set the first limit from the ISO rule or the healthy-error distribution, then adjust it based on how real alerts turned out.
Where a plant has no historian and knows about failures only from after-the-fact logs, the picture changes. Building a baseline and precursor labels from that is a separate problem, and checking whether existing records are fit to train on is the subject of auditing and harmonising sensor histories for predictive-maintenance models.
Should raw vibration data stay on the edge device, with only features transmitted?
Where bandwidth is the constraint, yes. Compute features and alarms on an edge unit near the machine, send only those, and keep the raw waveform in local storage for retrieval when a deeper look is needed. A University of Glasgow study of vibration edge computing in maritime IoT sent just 0.097% of the raw data volume over the network, a 1,553:1 reduction, without losing specificity or sensitivity in its maintenance decisions.
TechnoLynx delivers this through the AI Porting & Deployment Pack. The work starts by characterising sensor sampling rates, the link budget and the diagnostic requirements. It then chooses feature extraction that preserves the known fault signatures, builds the edge pipeline with local raw logging, and compares results from the compressed features against retrieved raw data on known fault cases.
Worked example: the Glasgow edge reduction recipe
- Read a 10-minute window of incoming data from each stream.
- Run an FFT, sort the frequencies by amplitude and keep only the top 1% for transmission.
- Extract peak-to-peak amplitude, mean, standard deviation, RMS and variance from the time series.
- Store the raw time series in local memory, overwritten as a circular buffer when full.
In the study’s bearing-dataset experiments, one bearing’s warning came 19 days in advance and its failure was predicted 8.6 days early. Across the experiments every failure was predicted and no false predictions were recorded.
Keeping only the top 1% of frequencies by amplitude is the recipe’s weak point. Early bearing defects produce low-level impacts, which is why enveloping exists to pull them out of the noise, and an amplitude filter can throw them away. Do not trust a reduced feature set until it has been tested against the failure modes you care about. Until then, a fault developing in a dropped band stays invisible until someone retrieves the raw archive.
Getting raw data back needs a procedure, not an assumption. With a circular buffer, raw data survives only until local memory is overwritten, and one offshore design uploads high-resolution data only when a preset threshold is exceeded. Where retrieval is infrequent, threshold-triggered snapshots plus a buffer sized well beyond the expected retrieval interval make sense.
The edge computer is sized to the feature workload, not the other way round. Time-domain indicators such as RMS, crest factor, kurtosis and peak-to-peak are simple statistics computed over each window. One study ran signal-processing pipelines, including enhanced enveloping, on an NVIDIA Jetson TX2, with processing on the ARM CPU and TensorFlow anomaly detection on the GPU. Even so, the calculations were far from real time, so measurements were intermittent and the heavier Kurtogram analysis stayed in the cloud.
A portable diagnostic tool used on a shop visit should follow the same split. It pre-aggregates a small set of features on the device, such as vibration spectral summaries and temperature statistics, and leaves remaining-useful-life inference to the cloud unless the model genuinely fits within the tool’s compute and bandwidth budget. Aggressive aggregation on the device throws away signal that a later model might need, so keep a raw-capture option for a subset of visits.
How do you tell a sensor dropout from a real change in machine condition?
Monitor silence as a signal of its own, separate from the condition data. Track when each sensor last reported, alert when it goes quiet while its gateway is still up, require the silence to last a set time before anyone is paged, and keep a quality flag with every value so a stale or substituted reading never looks like a real change.
TechnoLynx builds this sensor-health and alerting layer as part of the Production AI Monitoring Harness. Telling transmission faults apart from real excursions is reliability work, separate from model accuracy: what you get is alerts a maintenance team can trust, not another dashboard.
RabbitMQ’s documentation says heartbeat timeouts of 5 to 20 seconds suit most environments, that values below 5 seconds are fairly likely to cause false positives, and that a peer counts as unreachable after two missed heartbeats. Without application-level heartbeats, a disrupted TCP connection takes about 11 minutes to detect on a default Linux configuration. In Prometheus, a common pattern alerts when a target is up but a specific metric has vanished, with the up check stopping it from duplicating existing down alerts. The for clause makes the alert wait until the condition has held for a set time before it fires. The Prometheus alerting guidance also advises leaving slack for small blips and alerting on the monitoring system itself.
Leave retries to the transport layer and its heartbeat window. An investigation starts only when silence outlasts the persistence window set for that asset. Starting with a fixed window and refining it from the false and missed alerts of a pilot gets further than trying to calculate the perfect number up front.
Quality has to travel with the value. OPC UA attaches a StatusCode to every value, classed as Good, Uncertain or Bad, and Bad means the value is not usable. Keep quality, value and timestamp together, and do not delete non-Good rows at ingestion, because deletion removes the evidence that the source or communication path had a problem. Interpolated values should be marked as substituted.
What they do not know is what your sensors mean, for example a battery running down versus a network outage, and that is where the adaptation work goes. If telemetry is not yet collected centrally, that has to come first.
Checks before trusting a condition alert
- Did the sensor’s heartbeat continue through the window that triggered the alert?
- Was the gateway reporting while the sensor was silent? If not, the fault is upstream of the sensor.
- Are the values in the window flagged Good, or Uncertain or Bad?
- Are any points interpolated or carried forward rather than observed?
- Does the change show on more than one axis or indicator, or on only one channel?
- Did the operating regime (speed, load) change at the same moment?
Can we show an inspector that a log gap was a transmission issue, not an excursion?
Only with evidence independent of the gap itself. The root-cause record has to link each gap to a specific cause (transmission dropout, sensor fault or a genuine process excursion) using system and network logs, timestamps and the readings either side of the gap. A CAPA (corrective and preventive action) record then documents the root cause, the immediate correction and the preventive action.
TechnoLynx’s AI Governance and Trust work builds approval evidence packs and traceability for production decisions. It is not legal advice, certification or a promise of audit-readiness.
CAPA guidance written for medical device notified bodies sets out a root-cause structure. First identify the causes surrounding the problem, then trace back to the root cause: the fundamental reason that, if corrected, prevents recurrence. Focus on systems rather than individuals, and link each corrective action clearly to the root causes found. The same guidance warns that simply changing a procedure and retraining staff may not be enough to fix a systemic issue.
The decision follows from the evidence. If the gap lines up with a documented network outage and the readings on either side show the process in control, classify it as a transmission issue and close it with corrective action on transmission reliability. If there is no such match, or the surrounding data is ambiguous, treat it as a possible excursion that needs a deviation investigation. Records that kept their quality codes make this possible. Records that dropped bad rows at ingestion make it guesswork. If the telemetry logs are themselves part of the gap, the argument becomes circular and much weaker. A 2026 evidentiary framework in Frontiers in Blockchain puts the principle well: continuity does not assume there are no gaps, but it requires gaps to be visible and explainable. The preventive action has to answer why the dropout was not alarmed in real time. The credible preventive action is the silence alerting described above.
Making a sensor log hold up against a tampering challenge
Store the log in append-only form whose integrity can be checked cryptographically, record who wrote and read it, and be clear about the limit: a hash-chained or Merkle-tree log proves the record has not changed since it was registered, not that the reading was true when it was captured. Legal writing on blockchain evidence makes the same point: a ledger can only show that a given hash existed at a given time, and that depends on how reliable the original capture and the system’s governance were. No ledger protects against tampering at the sensor or ingestion point, before the data reaches the store.
Tamper-evident log designs compared
| Design | What it proves | Reported cost |
|---|---|---|
| History tree (Crosby and Wallach, USENIX Security 2009) | Logged events are still present, and the current log is consistent with earlier views of it | 1,750 events per second on one CPU core with signatures; 10,500 with signing offloaded |
| Transparent log (research!rsc) | Proofs of length O(log N) that a record is in the log and that an earlier log is a prefix of the current one, so the log operator need not be trusted | Verification in 3 RPCs of about 8 kB each, even for a large log |
| Timestamp-ordered hash tree with a trusted third party (Accountability of Things, arXiv) | Tampering located to sub-second resolution | Constant overhead of about 8 KB per hour per device; 718,703 logs per second on the notary server |
Whatever the design, the log stays tamper-evident only if it is actually audited. Crosby and Wallach show that if a logger knows a commitment will never be audited, it is free to tamper with the events that commitment covers. An integrity scheme without routine auditing and sound key management will not persuade anyone in a dispute.
For US courts, Federal Rules of Evidence 902(13) and 902(14) let records produced by an electronic process, and data copied from a device, authenticate themselves through a qualified person’s certification instead of a foundation witness. The 2017 committee note explains that copies are ordinarily authenticated by hash value: matching hashes for original and copy reliably show they are exact duplicates. Authentication is all this settles. The other side can still object on hearsay or relevance grounds, and can still argue the output is unreliable, because authentication shows only that the output came from the computer. The Frontiers framework argues that a narrow presumption is defensible only for non-alteration after registration, and only where governance is transparent and the defence has real access to verification tools.
Immutability creates its own legal problems. A University of Oregon analysis notes that destruction orders and inadvertent disclosure conflict with permanent records, and concludes that only metadata should go on the ledger while the content is stored off it. In regulated plants, the MHRA’s 2018 data integrity guidance asks for archived records that cannot be altered or deleted without detection. US 21 CFR 11.10 requires secure, computer-generated, time-stamped audit trails whose changes do not obscure earlier entries, kept at least as long as the records themselves.
Not every log faces a court. If the record serves only as an internal audit trail with no legal exposure, write-once storage with access logging may be enough. Azure’s immutable blob storage keeps data in a WORM state that no user can modify or delete, account administrators included, and adds legal holds and a policy audit log. Amazon S3 Object Lock offers retention periods and legal holds on the same write-once-read-many model. Where the log may have to stand up to a tampering challenge, add a verifiable log structure with exportable proofs on top.
A facilities or operations dashboard is generally not enough for multi-year evidence retention, because it is built for convenient monitoring rather than for defensibility. Archon’s compliance-archiving guide lists what a defensible archive needs: immutability that can be demonstrated in an audit, metadata such as timestamps and source identifiers kept with the content, search that works without restoring the original system, and role-based access with logged activity. If the dashboard lacks these, it falls short of that guide’s defensible archive. The retention period itself is a question for legal counsel in your jurisdiction.
Who can build a condition monitoring pipeline that holds up in operation and at audit?
TechnoLynx builds the engineering between the sensor and the alert: machine-specific thresholds, edge feature extraction with recoverable raw data and sensor-health alerting. Whether to build in-house depends on whether your team already has signal-processing and edge-deployment skills. A team with reliability engineers but without those skills gets there faster with a specialist. The useful test of any partner is whether they can show how thresholds will be validated against your machines’ known-good and known-faulty data, and how the raw archive will be retrieved. Edge pipelines are covered by the AI Porting & Deployment Pack, and baselines, thresholds and alert quality by the Production AI Monitoring Harness.
The engagement is not needed for a single low-criticality machine where validated vendor limits already work. It also does not replace legal review of retention obligations or regulatory sign-off.
The weakest link sits before the first hash
Every later stage inherits what happens at the moment a measurement becomes a record. A ledger cannot repair a wrong timestamp, a missing quality flag or a reading that was substituted before it was hashed. The MHRA guidance asks for controlled, synchronised clocks at the point of use so that timed events can be reconstructed and traced. On a condition monitoring system, put engineering effort there first: clock sync on the edge unit, quality codes kept from the collector onwards, and hashing as close to capture as the hardware allows.
FAQ
What are the ISO standards for vibration condition monitoring?
ISO 20816 is the current standard for evaluating machine vibration measured on non-rotating parts. It replaces the older ISO 10816 series part by part as each section is revised.
Where should the accelerometer be placed for vibration measurements?
Under ISO 20816, readings are taken on the bearing housing or another accessible non-rotating structure, usually in two perpendicular radial directions at each bearing.
How long should you keep audit logs?
Under US 21 CFR 11.10, audit trail documentation must be kept at least as long as the electronic records it covers. Outside that regime, the period depends on your industry and jurisdiction.
