Definition
PHM (Prognostics and Health Management) is a technology for fault prediction and health management based on equipment condition data. By collecting data through sensors such as vibration, temperature, current, oil, and acoustics, and using methods such as machine learning, physical models, and digital twins, it performs fault diagnosis, fault prediction, and remaining useful life (RUL) prediction, supporting CBM and predictive maintenance decisions, enabling a shift from "repair after failure" to "maintenance before failure."
PHM follows standards such as ISO 13374 and ISO 17359, and adopts the "Detection → Diagnosis → Prediction → Decision" process. Data needs to be real-time, complete, and accurate, with high requirements for communication reliability.
Technical Features
PHM adopts an edge + cloud architecture: the edge side performs real-time collection, feature extraction, and simple alarms; the cloud performs deep analysis, model training, and trend prediction. Integrated with CBM, digital twins, and MES, it can form a complete predictive maintenance system. IoT SIM cards provide stable network connectivity for sensors and edge gateways distributed in factories, wind farms, and along railways.
Use Cases
PHM is widely used in industrial scenarios such as wind power, rail transit, aviation, mining, petrochemicals, power, and ships. Sensors and edge gateways upload status data to the PHM cloud platform through IoT SIM cards. SimtoLink provides stable network connectivity and dedicated APN for PHM data acquisition devices, ensuring real-time status data transmission and remote diagnostics.
What must be agreed before a sample enters prediction
When PHM uses an IoT SIM, the SIM carries condition values already sampled under the agreement for that point. It does not carry the model conclusion itself. Vibration, temperature, current, or oil indicators must leave the site with the point name, the sample rate, and a timestamp before the cloud can diagnose or estimate remaining life. The SIM's job stops at "samples arrive on time and can be tied to the equipment state." Whether a prediction is trustworthy still depends on whether the samples meet the model's input agreement. The sample rate on that point must be stable, the gateway must not convert the unit incorrectly, and the operating regime must be sent along. A temperature drop during shutdown, sent in as a running sample, makes the model think the equipment is improving. The edge may raise a threshold alarm first, but a series sent for prediction must not be thinned to a different sample rate just to save data, unless the model is re-agreed at that new rate.
Gateways in a plant, a wind farm, or along a line often fold several protocols into one message. If that step changes scale or time, later prediction cannot be traced. The protocol point list and the uplink mapping should keep the original point name and the original unit traceable. Cache during an outage must be ordered by sample time, not by backfill time, or a gap is squeezed into a high-frequency spike. If the cache lost a middle stretch, mark it missing. Do not fill it with a straight line and then hand it to the model.
A gap treated as a degradation trend
It is easy to read a long stretch of no data as healthy equipment. No data may be an unpaid SIM, a gateway that lost power, or a sensor that disconnected. It has nothing to do with a bearing trend. Missing samples should be counted on their own. Continuous missing samples past a threshold should raise a collection fault, not leave the prediction curve parked on the last normal value. Another mistake is clock drift. The gateway clock is slow, new samples are inserted into the middle of history, the trend jumps back and forth, and that is misread as an early fault. When time sync fails, that batch of samples should not enter prediction.
A regime that is not aligned also creates false degradation. The same vibration differs a lot between high load and idle. If only vibration is uploaded, and not load or speed, the model treats a load change as damage growing. After a repair replaces a part, if that point's health baseline is not reset, the new part's normal value is appended to the old trend and looks like a sudden failure or a sudden recovery. For acceptance, use a known shutdown and a sensor that is deliberately unplugged. The platform should show shutdown and missing data separately, and the prediction job should skip both stretches, not draw one continuously worsening curve.
Shutdown samples must not enter the health trend
A temperature drop and a loss of vibration while the equipment is shut down should be marked as shutdown. They must not be sent into remaining-life calculation. A blank after a sensor is unplugged is missing data. Continuous missing samples past the threshold raise a collection fault. A curve parked on the last normal value hides the break. When the gateway time is wrong, do not insert new samples into the historical series. If load or speed was not uploaded with the vibration, treat the vibration change as regime unknown first. Do not record it directly as degradation.
After a part is replaced, reset that point's baseline. Otherwise the new part's normal value is appended to the end of the old trend and looks like a sudden failure. Order backfill by sample time. A stretch that was dropped stays a gap. Do not fill it with a straight line. Test with one known shutdown and one unplugged sensor: the prediction job skips both, and the collection fault appears on its own. Condition values the SIM delivers can enter prediction only after that.