Predictive Maintenance based on IoT Sensors
From sensor to decision: identifiable, comparable data help observe condition, verify an anomaly and follow up work. Diagnosis and prognosis need evidence and limits; PMS retains responsibilities, tasks and outcomes.
Operational Explanation
A sensor measures a phenomenon; the IoT network makes data and context available. Maintenance value comes from connecting the component, failure mode, meaningful measurement and planned response. A changing curve is not yet a diagnosis: it may reflect wear, a different load or a sensor problem.
| Stage | Question answered |
|---|---|
| Condition monitoring | What do we measure and how does it change against a relevant baseline? |
| Diagnosis | What condition or cause may explain the anomaly, with what supporting evidence? |
| Prognosis | How might the condition evolve, under which assumptions and with what uncertainty? |
| Maintenance decision | What action is justified and authorised, who performs it and how is its outcome verified? |
A condition-based strategy uses observed condition to guide intervention; predictive maintenance adds a forecast of its evolution. Not every alert includes a remaining-life prediction. A digital twin is one possible asset representation supporting particular analyses, not another name for a sensor or every anomaly model. CIMAC 2025-04, related concepts.
Regulatory Reference
ISM 10.1–10.4: maintenance under applicable and Company requirements, inspections at appropriate intervals, reporting defects with a possible cause if known, action and records. Digital management needs to preserve these functions. ISM Code, §10.
Approved PMS/machinery survey arrangement, class notation, maker recommendations, ISM risk assessment and data governance.
As an example of a class scheme, DNV describes a CBM arrangement combining scheduled and predictive maintenance with an approved service supplier. Check the rules and acceptance applicable to the ship: the service description alone does not authorise extending survey or maintenance intervals. DNV: Condition Based Maintenance.
In the operating plan identify the sensor, units, load and baseline; assign a person to verify alerts and document decisions. Missing data or sensor failure requires the planned alternative method and reporting: absence of alarms does not demonstrate healthy equipment. IMO: ISM safety management.
The DNV page describes an offshore classification service: it is an example of a scheme, not approval of the ship. If a change affects activities or surveys in the accepted arrangement, check the specific acceptance before changing the plan; data do not authorise exceeding a statutory due date or maker limit.
Scope of Application
Apply monitoring to components and failure modes with meaningful measurements and a response process. Define which tasks retain fixed intervals and which fall within the accepted condition-based scheme; an IoT platform does not itself extend the scope of approval.
Procedure / How to Complete It
- Define the question. Identify the component and failure mode to observe, useful measurement and supported decision. Clarify which tasks retain intervals and which condition-based branch, if any, is accepted.
- Make the data identifiable. Link sensor, location, units, timestamp, load conditions, calibration and acquisition status. Identify missing data, delays or changes in the chain; apply the planned alternative method when monitoring is unreliable.
- Compare appropriately. Use a relevant baseline and comparable conditions. Verify an anomaly on the machinery and sensor before attributing it to a fault; distinguish observation, diagnostic hypothesis and prediction.
- Assign the response. The responsible person follows instructions, assesses urgency and initiates planned escalation or technical support. A stated prediction needs assumptions, scope and uncertainty; do not ignore a dangerous indication while waiting for the supplier.
- Connect the decision and work. Record the data/anomaly, assessment, owner, decision and task in PMS. Confirm acceptance and limits before changing a due date; closing an alert in software does not prove the defect resolved.
- Verify follow-up. Compare the work outcome with subsequent data and hand over open defects. After component or measurement changes, review the baseline under the programme. Evaluate documented system performance, including missed anomalies and false alarms, without turning it into a savings promise.
Practical Example
Learning scenario: a pump’s vibration rises against the reference. The team verifies sensor identity and status, load and plant condition, comparing relevant measurements. The change is confirmed, but does not establish bearing damage or estimate its remaining life: the specified technical assessment and evidence are needed. The responsible person records the assessment and follows the applicable work order and operational response; after intervention, the outcome is linked to a subsequent check. The alert does not cancel PMS tasks and silencing it does not close follow-up.
What Typically Goes Wrong
Common Mistakes Mistake Library
| Mistake | Consequence | How to avoid it |
|---|---|---|
| Mistaking missing or stale data for absence of anomalies | A problem may remain unobserved while the system appears normal | Check timestamps, completeness and sensor status; activate the planned alternative method |
| Comparing measurements at different loads without context | An operating change may be interpreted as degradation | Compare relevant conditions and record load |
| Treating an alert or remaining-life estimate as an automatic order | Decision without evidence or postponement outside the accepted scope | Separate diagnosis/prognosis, the responsible person’s decision and PMS/maker limits |
| Closing an alert without recording action and outcome | The defect and its follow-up may remain open | Connect data, work order, intervention and subsequent verification |
What the PSCO Checks
Operational Tips
- Use the same component identifier in data, PMS and supplier communications.
- Record load, sensor or configuration changes affecting comparison with the baseline.
- Make observations, hypotheses and predictions distinguishable at handover.
- Define data access, availability and secure management; for the relevant framework see Cyber Risk of Automation Systems.
Preparation checklist
- Component, failure mode and supported decision identified
- Sensor, units, time, load and baseline identifiable
- Data quality, calibration and alternative method identified
- Monitoring, diagnosis and prognosis distinguishable
- Responsibility, response and escalation defined
- Decision/task/outcome linked to PMS within applicable limits and acceptances
- Open defects and subsequent verification handed over
FAQ
Related Topics
Certified substantive revision: 12 October 2026 · page fingerprint 0cf298b7b5e8