Definition
Remote Diagnosis allows for the remote collection of device Log Collection logs and operational status through the platform. Combined with Fault Diagnosis and RCA, it enables fault localization and root cause analysis, reducing on-site troubleshooting. It is an important part of Remote Maintenance.
Diagnostic Process and Tools
Remote diagnosis is usually initiated by an alarm or proactive user action. The platform collects device logs, core dumps, and operational parameters through Log Collection. It can also analyze these in conjunction with real-time telemetry and historical trends from Device Monitoring. Diagnostic results can be linked to the Fault Knowledge Base for pattern matching. For complex faults, RCA root cause analysis can be used to track causal chains. Diagnostic reports can generate work orders, be pushed to maintenance personnel, or be recorded as knowledge base cases.
Integration with DMP
The Device Management Platform provides capabilities such as diagnostic task creation, log retrieval, status query, and diagnostic report generation. It is deeply integrated with Work Order to support initiating diagnostics from work orders and backfilling diagnostic results into work orders; integration with Fault Knowledge Base enables intelligent recommendations and case reuse. Sensitive logs need to be desensitized, and diagnostic operations require Audit Log records to meet security and compliance requirements.
Use Cases
It is suitable for rapid localization after device anomalies, remote troubleshooting of software defects, and root cause analysis of batch faults. Remote diagnosis can significantly reduce on-site trips, shorten MTTR, and improve operational efficiency and customer satisfaction.
A diagnosis task collects evidence, not a conclusion
The output of remote diagnosis should be a set of material that can be reviewed: logs inside a stated time window, the runtime parameters of that moment, the related telemetry slice, and the error codes the device reported itself. The platform may mark the material as similar to a known class of problem. A similarity hint is not a diagnosis. A person writes, on the material, what was ruled out and what is still missing. Writing the closest knowledge-base entry down as the root cause sends the later response down the wrong procedure.
The task must record what was collected and how complete it is. If only half the logs arrived, the report should name the missing files and time ranges. It should not present itself as a full snapshot. If the device overwrote older logs because storage was full, the report should say that nothing earlier remains on the device, rather than leaving a blank that the reader takes as a normal period. Sensitive fields are masked before they leave the device, and the masking itself must be traceable, so a missing identifier during troubleshooting is not ambiguous between policy and fault.
Log-pull window and bandwidth budget
A pull is appropriate only when the device still has enough link to send the material, and when that transfer will not crowd out a control action or an upgrade already in progress. Agree the window first: for example, a few minutes before the fault through a few minutes after it, rather than packing the whole flash by default. Too wide a window fills a cellular link with logs. The device looks less stable, and the diagnosis itself becomes a new disturbance. Too narrow a window can miss the last lines before a restart.
Set the bandwidth budget per product. A low-rate link may send only the error code, the restart reason, and the key parameters first. The full log waits until the device is on a faster network, or until a technician exports it locally. If the task shares a connection with an upgrade, state which one may preempt the other. Diagnosis must not force a log pull while an upgrade is writing, or both sides can time out. If a historical curve is needed for comparison, read points already stored in the time-series database. Do not ask the device to upload the same data again.
Explaining the current fault with an expired log
A common error on the device is to treat the last file in a rotating log as the record of the current fault. That file may be a startup failure from last week, while this incident is a supply drop and the device had no time to write a new log. The report must carry the file's start and end times and the device clock. Material that does not line up with this alarm is background only. If the clock has drifted visibly, correct it or mark it untrustworthy before discussing event order.
When several diagnosis tasks stack on the same device, the later task easily mixes in an old package already downloaded by the earlier one. Isolate directories and identifiers between tasks, and cite only files this task pulled when the report is built. Automatically filling a diagnosis summary in as the work order's "resolved cause" is the wrong move as well. The summary is an index of evidence. Closing the order still needs the outcome of the response. Automatic close treats "logs downloaded" as "fault cleared." If the device restarts during diagnosis, record the restart as an interrupted collection. Do not treat the partial log from before the interruption as the whole of the facts.
After the task ends, keep the raw package for as long as the work order can still be reviewed. If the package is deleted early, the review before close has only a written summary, and the timestamps cannot be checked again. Write the package hash and byte count into the task, so a file truncated in transit is not treated as a complete log. If the device can export only new logs, record the position of the last export, so every pull does not start from the beginning and fill the link. If incremental export is not supported, narrow the time window rather than occupying the device uplink for a long time after the fault has already recovered. When several people start diagnosis on the same device, only one task may hold the export channel. Later tasks wait and say who is using it. Preemption stitches two incomplete logs into one archive, and the timeline can no longer be taken apart.