Definition
Device Health Score (Device Health) integrates dimensions such as Uptime, Alert Frequency, and Data Quality to output a 0–100 quantitative score. Supports Rolling Window statistics, custom weights, and deep integration with alerts, Work Order, Maintenance Schedule.
Calculation Dimensions and Weights
Health scores are generally based on a rolling window (e.g., the past 7 days, 30 days) statistics. The dimensions can include: uptime rate (proportion of Uptime), alarm frequency (deducted after normalization), data quality (telemetry completeness, proportion of anomalies), RUL remaining useful life (if the predictive model is integrated), etc. Each dimension can have configurable weights and can be customized by product type. The output is a score from 0–100, which can be mapped to health levels (Excellent/Good/Fair/Poor). Devices with low scores can trigger alarms, recommend Maintenance Schedule maintenance plans, or Predictive Maintenance predictive maintenance work orders.
Integration with DMP
The Device Management Platform displays health scores in scenarios such as Device Monitoring device monitoring, device lists, Report Analytics report analysis, etc. It supports filtering devices by health score, creating Dynamic Group dynamic group rules, and driving Work Order work order creation. Combined with RUL remaining useful life and Fault Diagnosis fault diagnosis, a comprehensive assessment of "health score + remaining life + diagnostic recommendations" can be formed to support operation and maintenance decisions.
Use Cases
It is applicable to device priority ranking, maintenance plan optimization, resource allocation, operation and maintenance KPI statistics, etc. Device health scores are the Device Management Platform's quantification capability from "connection" to "health," which can significantly improve operation efficiency and predictability.
When a score window and its weights actually apply
A device health score means folding several observable signs, inside a stated rolling window, into a score that can be ranked, so devices of the same kind can be compared for who needs attention. It is not a diagnosis, and it is not the condition of the asset. Usual inputs include the online share inside the window, alarm counts, whether telemetry arrived as expected, and whether data went outside its range. Each item needs a weight and a way to normalize, and the sum of weights and the cap on deductions have to be stated in advance. Too short a window lets one chatter knock the score to the bottom. Too long a window lets a device just repaired still be dragged by the old record. The window has to be set together with this kind of device’s reporting rhythm and maintenance cycle. The whole platform cannot share one number of days.
Before a score is used, the product needs enough history. A newly activated device whose window is not yet full can only be marked as an insufficient sample. It cannot be shown as zero or as a full score. Alarm definitions differ by product, so scores cannot be compared across products. A score fits ranking, filtering, and triggering a human review. It does not fit as the only condition for automatic disposal. Used with connection status, say whether offline in the formula is “no sample” or “a deduction.” Treating every missing telemetry point as bad data punishes devices that are supposed to report infrequently.
Deducting offline time directly as a fault
A common mistake is to let the score fall the longer the device is offline, until it cannot be told from hardware damage. A planned stop, storage in a warehouse, and power-saving sleep all go offline. They should not receive the same score as a failed sensor. Another mistake is an alarm storm. One root cause raises a hundred alarms, deducting by count drives the score to zero, and the device looks worse than one that is actually damaged. If weights are changed on screen and historical scores do not name the version that was used, comparison over time loses its meaning. Changing a score by hand to a full mark destroys the metric. Later readers cannot tell a calculated value from an overwrite.
If the data-quality item looks only at whether a number exists, and not at range and frozen values, a sensor stuck on the same reading scores high. After a repair, start the window again or say explicitly that the old window still includes the fault period. Otherwise the effect of maintenance is invisible, and the system immediately recommends repair again. When a dynamic group is built from health groups, a low-score device that was just repaired, and whose score has not yet recovered, must not be selected again by the same rule. The score is a ranking tool. Replacing a part on site still depends on diagnosis and history. A single number is not enough to dispatch the work.
Do not show an insufficient sample as a score of zero
A health score is a comparison inside a window. A new device, a device that sleeps for a long time by design, or a device whose statistical definition has just changed, should show an insufficient sample when the window does not have enough of one. It should not show zero or a full score. Zero pushes them into the repair queue. A full score makes it look as if they have already been observed. Whether offline in the formula is a missing sample or a deduction must be written down per product. A device in warehouse stock, a device stopped for the season, and a failed sensor should not receive the same number. Before deducting by alarm count, merge repeated alarms from the same root cause. Otherwise one chatter looks more serious than real hardware damage.
After weights or the window are adjusted, old scores and new scores cannot be drawn on one curve with no label. Changing a score by hand on screen ruins later comparison. If the business really needs a mark of “reviewed,” use a separate state. Do not overwrite the calculated value. After repair, say whether the old window still includes the fault period. Otherwise the score does not recover, and automatic dispatch comes again at once. When a score is used to select devices for a bulk action, remember that the score is a ranking, not a fault conclusion. Replacing a part on site still means looking at the raw data and the history. Comparing scores across products means nothing, because alarm definitions and reporting rhythm were never the same.