Choose your reading route
eduKateSG · Why Mathematics? · Condition Monitoring: Degradation Signals, Thresholds, False Alarms and Remaining Useful Life
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 8–14
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 15–21
Check assumptions
See where design and calibration matter.Route 4 · Chapters 22–28
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 29–45
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important in condition monitoring? Sensors produce noisy measurements; mathematics helps distinguish normal variation from degradation, set thresholds, count false alarms and express remaining useful life as an uncertain forecast rather than a fixed date.
Did You Know? Even a monitor with 90% sensitivity and 95% specificity can produce more false than true alerts when real degradation is uncommon.
Full chapter index
Chapters 1–7 · Understand the question
Chapters 8–14 · Reproduce the example
Chapters 15–21 · Check assumptions
Chapters 22–28 · Explore applications
Chapters 29–45 · Study and verify
- Applications and careers
- Guidance for students and parents
- Common misconceptions
- Connection to recent mathematics articles
- Practice questions
- Frequently asked questions
- A reporting checklist
- A final audit
- Useful next reading
- Sampling rate and aliasing
- Change-point detection
- Survival models with sensor covariates
- Fleet learning and asset differences
- Decision thresholds and maintenance capacity
- Monitoring the monitor
- Student investigation
- Calibration of predicted risk and remaining life
CHAPTER 1 OF 45 · Understand the question
1. Why condition monitoring needs mathematics
Condition monitoring uses measurements to ask whether equipment or a process is healthy, degrading or approaching a functional limit. Mathematics turns noisy signals into evidence, while keeping detection, diagnosis, prognosis and maintenance action distinct. A trend line can support a decision only when sensors, thresholds, operating context and uncertainty are understood. The goal is timely, justified action rather than a dashboard full of confident-looking numbers.
A sensor records vibration, temperature, current, pressure, wear or another proxy. A feature extracts information, a model estimates state, an alarm applies a rule, and an authorised process decides what to do. These steps are not interchangeable. A high reading can be real degradation, normal load change, sensor drift or data error. Preserve the chain so investigators can identify where a false alarm or missed detection arose.
Detection asks whether behaviour changed. Diagnosis asks which fault or mechanism is likely. Prognosis estimates future condition or remaining useful life. A model can detect change without knowing the cause, or diagnose a fault without predicting when it becomes unacceptable. Reports should name the task. Calling every alert predictive maintenance exaggerates what the mathematics has established.
NIST’s Prognostics, Health Management and Control programme develops measurement science for robust sensing, diagnostics and prognostics. Read the NIST PHMC overview. NASA describes condition monitoring as a basis for maintenance decisions and cautions that unnecessary intervention can add risk. Read NASA hardware and condition-monitoring guidance.
A useful signal changes in a repeatable relationship with the target condition before functional failure. Vibration amplitude may increase with bearing damage, but also with speed and load. Temperature can rise with friction or ambient conditions. Transform or normalise features using known operating covariates. A correlation in historical data is not enough; the signal should have a plausible mechanism and stable measurement process.
Suppose a degradation indicator is 40 units, the functional threshold is 55, and a simplistic linear trend is 0.5 unit per day. The point estimate of remaining time is (55-40)/0.5=30 days. This result assumes constant slope, correct threshold and no measurement error. It is a teaching example, not a maintenance instruction. Real RUL should be a distribution that changes as new observations arrive.
| Actual state | Alert | No alert |
|---|---|---|
| Degraded: 50 | 45 | 5 |
| Not degraded: 950 | 47.5 expected | 902.5 expected |
| Total | 92.5 expected | 907.5 expected |
RUL means time until a defined end-of-useful-life event, conditional on current information and future operating assumptions. Change the load profile, threshold or degradation model and the distribution changes. Report prediction intervals or quantiles, not only a date. A unit can fail through another mode before the monitored indicator reaches its limit. RUL is a model output tied to a definition, not a hidden clock inside the asset.
Lowering an alarm threshold can detect more true problems earlier but creates more false alarms. Raising it reduces alarm burden but can miss degradation or shorten response time. Receiver-operating-characteristic and precision-recall curves describe parts of this trade-off. Choose the threshold from consequence, prevalence, lead time and response capacity. An accuracy maximum may be inappropriate when missed failures and unnecessary shutdowns have very different costs.
Among 1,000 checks, suppose 5% are truly degraded. With 90% sensitivity, 45 of 50 degraded cases alert. With 95% specificity, 5% of 950 healthy cases, or 47.5 in expectation, also alert. Thus fewer than half the alerts are true in this illustration. A good test can still produce many false alarms when the condition is uncommon. Expected counts may be fractional; observed counts are integers.
The illustrative positive predictive value is 45/(45+47.5), about 48.6%. This is the probability that an alert corresponds to the defined degraded state under the assumed prevalence and performance. If prevalence changes across sites or seasons, predictive value changes even when sensitivity and specificity remain constant. Report the operating population and avoid transporting one alert-quality percentage everywhere.
Five degraded cases in the illustration do not alert. Review missed detections by failure mode, operating state and sensor quality. A model can miss sudden failures that have no gradual precursor. Safety-critical controls should not rely on a prognostic signal without authorised hazard analysis and independent protections. Monitoring can support risk reduction, but absence of an alarm is not proof of health.
Sensor bias, drift, noise, mounting and sampling rate affect every downstream result. Calibration checks measure some aspects but may not reproduce field installation. Use reference signals, redundancy and plausibility rules. Store raw data and quality flags. If an algorithm silently imputes missing values, the confidence output should reflect that. A precise forecast from a drifting sensor is precise misinformation.
A vibration signal sampled too slowly can make high-frequency behaviour appear at a false lower frequency. Irregular sampling can distort trends and spectral features. Choose sampling rate from the physics and anti-aliasing requirements. Synchronise clocks across sensors. Downsampling may save storage but remove short transients that matter. Document preprocessing so a result can be reproduced from the original waveform.
| Output | Meaning |
|---|---|
| Detection | A change may be present |
| Diagnosis | A likely fault mode |
| Prognosis | A future state or RUL distribution |
| Alarm | A rule has triggered |
| Maintenance action | A governed operational decision |
Moving averages and filters reduce noise but delay or attenuate changes. A longer window can make a chart calm while postponing an alarm. Quantify step response and phase delay for the feature. Compare raw and filtered signals during known events. Filtering is part of the model, not cosmetic presentation. A threshold validated on one filter cannot be moved to another without revalidation.
Control charts, cumulative sums and Bayesian change-point methods can flag shifts. Their false-alarm properties depend on assumptions about baseline variation and independence. Set a stable baseline by operating regime. A change signal starts investigation; it does not diagnose a component automatically. When many sensors are monitored, multiple-alert burden and correlation matter. Combine statistics with physical context.
Load, speed, product type, ambient temperature and maintenance state can change normal signals. A global threshold may alarm during legitimate high-load operation and miss damage at low load. Stratify, normalise or model regimes explicitly. Ensure every regime has enough validation data. A model trained mainly on steady operation may fail during startup and shutdown, which are often the moments of greatest interest.
Features can include time-domain statistics, frequency peaks, envelopes, rates of change or learned representations. Each compression discards information. Prefer features that remain stable across sensors and connect to failure mechanisms. Avoid selecting hundreds of features on a small data set without proper validation. Feature importance from a predictive model does not establish causality. Record units and transformations.
Randomly splitting individual rows can leak nearly identical measurements from one asset into training and test sets. Hold out entire assets, later time periods or sites according to the intended deployment. Prevent future measurements from entering current features. Compare with simple baselines. Report performance by failure mode and operating regime, not only one average score. Validation should imitate the decision environment.
Most monitoring data may be healthy, while failure examples are rare and selected. Overall accuracy can be high if a model predicts healthy every time. Use precision, recall, false alarms per operating time and lead-time distributions. Synthetic faults may help development but need field confirmation. A model cannot learn every unknown failure mode from labels that do not exist.
A 90% prediction interval should contain the future target about 90% of the time in comparable cases if calibrated. Check coverage across horizon, asset and regime. Narrow intervals are not useful if wrong. Separate aleatory variability from parameter and model uncertainty when helpful. If the asset is outside the training domain, widen uncertainty or abstain. Confidence should guide action, not decorate the dashboard.
An alarm needs priority, owner, response time, evidence and closure criteria. Too many false alarms cause fatigue and delay. Track alerts per asset-month, acknowledgement, action, confirmed findings and repeated alerts. Suppression rules can hide real events if poorly governed. Design the human workflow with the algorithm. A model that scores well offline can fail operationally when the organisation cannot respond.
An alert threshold and a maintenance threshold may differ. An early alert can trigger inspection, while a later condition triggers shutdown or replacement. Define escalation and confirmation. Incorporate access windows, spare availability and consequence. Do not turn an uncertain RUL point estimate into an automatic work order unless the decision process is validated and authorised. Human review can be part of a safe system.
Sensors, assets, software and operating practices change. Monitor feature distributions, missingness and outcome relationships. A stable average error can hide deterioration in one regime. Recalibration or retraining needs version control and independent evaluation. Never train on labels created by the model’s own earlier alerts without checking feedback bias. Preserve a champion baseline and rollback path.
A feature that predicts failure may be a consequence, shared cause or operational response. Changing it may not prevent failure. Maintenance decisions need mechanism evidence and intervention studies where feasible. Correlation can still be useful for prediction, but language must remain precise. Say the signal is associated with risk rather than claiming it causes damage unless the evidence supports causation.
A physics-based or hybrid digital twin can estimate hidden state and simulate future paths. Its usefulness depends on parameter identification, boundary conditions and model discrepancy. Updating a twin with sensor data does not remove structural error. Validate predictions against held-out assets and abnormal regimes. A visually realistic twin can still be mathematically wrong. Report which parts are measured, estimated and assumed.
Use a simulated signal that rises toward a threshold with random noise. Calculate a moving average, trigger alarms and estimate RUL with a line. Change the window and threshold, then count early, late and false alarms. Add a sensor bias. Students learn rates, graphs, probability and model limits. The exercise should not control real equipment or imply professional maintenance advice.
Create columns for time, operating regime, raw signal, quality flag, filtered feature, threshold, alarm and confirmed state. Calculate confusion-matrix counts and predictive value. Fit a simple slope only over a documented window, then compute an illustrative RUL and sensitivity to slope. Plot raw and filtered data together. Keep failure threshold and maintenance action separate. Label all simulated values.
Build time-aware pipelines that prevent leakage. Unit-test sampling, missing-data rules, filter delay and threshold boundaries. Split by asset and time. Return calibrated intervals and abstention flags. Log model, sensor and feature versions with every prediction. Reproduce the base-rate table and linear example independently. Review deployment code for alarm flooding and stale data, not only model accuracy.
Condition monitoring supports manufacturing, transport, energy, buildings, robotics and computing infrastructure. Roles combine mathematics, signal processing, engineering, statistics, machine learning and maintenance knowledge. Mathematics creates options but does not guarantee a job or salary. Students can explore graphs and probability, then consider engineering, data science, computing or technical programmes using current official pathway information.
Students should distinguish a measurement, an alarm and a decision. Reproduce the thirty-day point estimate, then list every assumption that could change it. Parents can use the base-rate example to discuss why a good test can have many false alarms. Practise on synthetic data. The transferable lesson is that prediction is useful when uncertainty, context and action are designed together.
An alert is not a diagnosis. No alert is not proof of health. RUL is not a fixed countdown. Smoothing can add delay. High accuracy can hide rare-failure misses. A threshold that works in one regime may fail in another. More sensors do not automatically create more information. A predictive association does not prove a cause. Condition monitoring does not replace safety controls.
Read Preventive Maintenance Optimisation for policy choices, Measurement System Analysis for sensor quality and Availability Engineering for service impact. The Mathematics Learning Hub links graphs, statistics and computing.
1. Calculate the linear RUL example. 2. Build the 1,000-check confusion matrix. 3. Find positive predictive value. 4. Explain base-rate effects. 5. Give one smoothing delay. 6. Describe sensor drift. 7. Prevent one data-leakage path. 8. Distinguish detection and diagnosis. 9. Propose an abstention rule. 10. Write a cautious maintenance recommendation.
### Is RUL the exact failure date? No. It is a conditional prediction distribution tied to assumptions.
### Why are many alerts false? Low prevalence and imperfect specificity can produce many false positives.
### Does filtering always help? It reduces some noise but can delay or distort changes.
### Can AI replace engineering review? A model can support decisions, but governance, mechanisms and authorised review remain necessary.
Define asset, function, signal, units, sampling, regimes, threshold and end-of-life event. Report sensor quality, preprocessing, validation split, prevalence, sensitivity, specificity, false alarms, misses, lead time and RUL interval calibration. State action and escalation rules. Monitor drift. Link primary sources. Avoid causal or safety claims beyond the evidence and never present a point forecast as certainty.
Recalculate 30 days, 45 true alerts, 47.5 expected false alerts and 48.6% predictive value. Confirm observed counts are integers. Inspect units, clocks, filter delay and threshold direction. Test leakage and asset-level splits. Verify source links. Remove claims that an alarm proves a fault, that RUL is fixed or that condition monitoring alone guarantees safe operation.
Continue with NIST PHMC research, NASA condition-monitoring and reliability-centred maintenance guidance, and work on calibrated prognostics. Compare the topic with measurement system analysis, preventive maintenance and Markov reliability. The Mathematics Learning Hub connects rates, time series, probability, classification and uncertainty.
A sensor sampled too slowly can miss or misrepresent a changing signal. Relate the sampling interval to the physical frequencies of interest, anti-alias filtering and storage constraints. Faster sampling creates more data but may add little information when the sensor bandwidth or failure process is slow. Validate the full measurement chain. A smooth trend produced after aliasing is not faithful evidence, and a high-rate stream does not compensate for poor placement or calibration.
Some degradation begins as a step or shift rather than a steady slope. Change-point methods compare evidence for a stable regime with evidence that model parameters changed. Define the false-alarm rule, minimum detectable change and delay metric. Test the method on labelled events and realistic stable periods. A detected change says the statistical behaviour altered; engineering diagnosis still has to determine whether the cause is wear, maintenance, environment, sensor replacement or data processing.
Time-to-event models can use condition measurements as covariates, but time-varying data require careful alignment. Avoid using measurements collected after the prediction time. Check proportional-hazards or other structural assumptions and compare calibration across assets and operating regimes. A risk score is not automatically a remaining-life estimate. Present predicted survival probabilities at relevant horizons with uncertainty and a clear reference population.
Pooling a fleet can improve precision, yet assets differ by age, duty cycle, installation and maintenance. Hierarchical models allow shared learning while preserving asset-level variation. Hold out whole assets and later time periods when testing generalisation. If only the best-instrumented machines provide data, selection bias may hide difficult cases. Report where the model works, where it is uncertain and whether recalibration is required after operating changes.
CHAPTER 42 OF 45 · Study and verify
42. Decision thresholds and maintenance capacity
An alert threshold should connect to an action, response time and available capacity. Combine false-alarm and missed-detection consequences with inspection cost and lead time. A theoretically optimal threshold may fail operationally if it creates more work orders than technicians can investigate. Simulate alert queues and escalation rules. Governance should allow human review and safe fallback when data are missing or contradictory.
After deployment, track calibration, alert rate, confirmation rate, missed events, latency and data completeness. Compare these measures by site, asset class and season. Detect changes in sensor distribution and model performance before they create unsafe confidence. Version the model and thresholds, preserve an audit trail and define who can approve changes. Condition monitoring is a continuing measurement process, not a one-time model launch.
Collect a harmless time series such as battery voltage or a simulated wear signal. Add noise, drift and a known threshold. Compare raw values, a moving average and a fitted trend. Measure how smoothing changes alarm timing. Use repeated simulations to form an RUL distribution, then report median and prediction interval. Explain why the experiment does not justify a real maintenance decision without validated sensors, failure thresholds and operating evidence.
CHAPTER 45 OF 45 · Study and verify
45. Calibration of predicted risk and remaining life
A model can rank assets correctly and still give poorly calibrated probabilities. Group comparable predictions and compare them with observed outcomes at the stated horizon, while allowing for censoring and time dependence. For remaining useful life, examine interval coverage and error as the prediction horizon shortens. Recalibrate only with data that match the deployment population and preserve a separate evaluation set. Report both discrimination and calibration because a maintenance planner needs absolute risk, not only ordering. Where labels are delayed or uncertain, describe that limitation and use conservative governance. A model that says ten assets each have a 10% chance of failure should, over many comparable cases, be checked against roughly one observed event; individual outcomes never prove calibration. This discipline keeps forecasts honest and makes changes detectable.
Extended practice laboratory
Practice case 1: Linear RUL example
Setup: Signal is 40, failure threshold 55 and trend 0.5 units/day.
Task: Calculate (55-40)/0.5.
Checking target: Obtain 30 days under a simplistic constant-trend model.
Practice case 2: Base-rate table
Setup: Use 1,000 checks, 5% degraded, 90% sensitivity and 95% specificity.
Task: Compute alert counts.
Checking target: Obtain 45 true alerts and 47.5 expected false alerts.
Practice case 3: Positive predictive value
Setup: Use the base-rate table.
Task: Calculate true alerts divided by all alerts.
Checking target: Obtain about 48.6% in the illustration.
Practice case 4: Threshold shift
Setup: Raise and lower an alarm threshold.
Task: Track false positives and false negatives.
Checking target: Recognise the trade-off.
Practice case 5: Smoothing delay
Setup: Apply a moving average.
Task: Compare noise reduction and response delay.
Checking target: Do not treat a smoother signal as free information.
Practice case 6: Sensor drift
Setup: Add a slowly changing bias.
Task: Observe its effect on threshold crossing.
Checking target: Calibration and reference checks matter.
Practice case 7: RUL distribution
Setup: Replace a point forecast with quantiles.
Task: Report median and prediction interval.
Checking target: Plan from uncertainty, not one date.
Practice case 8: Failure threshold
Setup: Define the functional threshold physically.
Task: Check whether it varies by duty cycle.
Checking target: Do not let the model invent the end of life.
Practice case 9: Data leakage
Setup: Build training and test sets by asset and time.
Task: Prevent future measurements entering features.
Checking target: Validate as the model would operate.
Practice case 10: Alarm burden
Setup: Count alerts per asset-month and response time.
Task: Include technician capacity.
Checking target: A high-sensitivity system can overload action.
Practice case 11: Missed detection
Setup: Review failures without prior alarms.
Task: Separate sensor, model and process causes.
Checking target: Use misses to improve validation.
Practice case 12: Write a decision
Setup: State signal, threshold, horizon and action.
Task: Report false alarms, misses and RUL uncertainty.
Checking target: Avoid turning prediction into certainty.