Definition
Fault Diagnosis is based on device Telemetry, Event Stream, Log Collection, and other data, combined with the Fault Knowledge Base to perform fault localization and RCA root cause analysis. It supports rule matching and AI-assisted diagnosis and is a core capability of Remote Diagnosis.
Diagnostic Methods and Processes
Fault diagnosis can use methods such as rule matching (based on thresholds, patterns, alarm combinations), Fault Knowledge Base case retrieval, and machine learning anomaly detection. The process usually is: obtaining alarms from Event Stream, obtaining logs from Log Collection, obtaining telemetry history from Time Series DB; performing feature extraction and pattern matching; outputting possible causes and recommended measures. When combined with RCA root cause analysis, the fundamental cause of faults can be traced, supporting corrective and preventive actions.
Integration with DMP
The Device Management Platform embeds fault diagnosis capabilities in Remote Diagnosis and Work Order processing. Alarms can automatically trigger the diagnosis process, output diagnostic reports, and recommend Fault Knowledge Base cases; the diagnosis results can be linked to work orders and drive Remote Maintenance operations. The platform continuously accumulates diagnostic cases, deposits them into the knowledge base, forming a "diagnose—accumulate—reuse" loop, continuously reducing MTTR.
Use Cases
It is suitable for rapid localization after device anomalies, root cause analysis of batch faults, and intelligent recommendations for repetitive faults. Fault diagnosis is a key indicator of operation and maintenance maturity, which can significantly improve operational efficiency and customer satisfaction.
A clue is not the alarm title
Fault diagnosis has to explain the symptom, not restate the alarm title in different words. It puts the shape of the measurements over a period, the order of events, and fragments of the log side by side, compares them with failure modes already known for that model, and then offers a possible cause, the evidence still missing, and which check to make first. An alarm that says the temperature is high only means some value crossed a threshold. Diagnosis has to separate sensor drift, blocked cooling, an abnormal load, and a threshold that was set wrong. The same alarm code can mean different causes under different firmware and different installations, so a conclusion has to carry the model and the version range. The output should keep what is still uncertain and list the explanations already ruled out, rather than offering only one name stated as fact. A drop in the health score can set the queue order. It cannot replace a look at the raw points. The score is a combined result. The judgment still has to return to the curve and the log.
What automatic diagnosis needs before it can run
A diagnostic flow is worth starting automatically only when the device identity is stable, the time range can be aligned, and there is a rule or a past case for that model. Missing points cannot be filled by imagining a curve from the event title. A missing log cannot turn "communication timeout" straight into a failed main board. When a batch of devices alarms together, look first for a shared cause such as the gateway, the power supply, or the uplink, and only then judge the inside of each device. Rules should match on alarm code, firmware version, and the key measurements together, not on a Chinese description alone. Advice that involves cutting power, opening the unit, or a safety action, and any new model with no close case in the knowledge base, should still wait for a person. Diagnosis and action stay separate. Diagnosis can name the next check, but rewriting the device shadow or sending a control command still has to be executed on its own, under the right permission.
Treating nearness in time as a cause
The easy mistake is to write a cause-and-effect link between symptoms that merely happened close together. Temperature readings that disappear after a communication break do not mean the temperature sensor is damaged. An upgrade failure and a storage alarm at the same time may both be the result of weak power. A rule that treats a match as certainty, with no exclusion and no version range, lets a special case from old firmware contaminate a new model. Looking only at the latest event, and not at the recovery event, turns a glitch that already cleared into an ongoing fault. If the log time zone and the measurement time zone differ, a person will attach an unrelated error line to the moment of the fault. Writing a conclusion back into the knowledge base without the firmware it applies to means the next recommendation offers outdated steps to a device whose protocol has already changed. Covering the rest of a batch with the conclusion from the first unit also misses units whose cause is not the same. The conclusion should state the start and end of the data it used, so a later check against a different stretch of the curve can tell whether it is the same window.