A method and system for graded retransmission of defect events in power distribution robots

Abstract

This invention relates to the field of distribution network data processing technology, and proposes a hierarchical retransmission method and system for defect events in distribution network robots. The method includes: receiving original results and evidence indexes from multiple sources for the same abnormal target generated by multiple software modules, and uniformly encapsulating them into defect event objects containing features such as event master identifier, stage identifier, evidence index, and upload sequence number; generating summary, key, full, or incremental event packets based on the abnormality level, evidence completeness, network and platform status; sending the packets when the network is normal, and writing them to a local cache queue when there is an abnormality or failure, and performing retransmission, deduplication, and sequence maintenance according to the upload sequence number and priority; the platform performs event-level deduplication, sequence, and stage recovery based on each identifier and upload sequence number to obtain the recovery results of the defect event at different stages; finally, combining the source identifier and evidence index to organize the process state sequence and providing it to downstream functions. This invention achieves reliable, orderly retransmission and full-process restoration of defect data in weak network environments.

Description

Technical Field

[0001] This invention relates to the field of power distribution network data processing technology, and in particular to a method and system for hierarchical retransmission of defect events by power distribution network robots. Background Technology

[0002] With the development of intelligent distribution network inspection, distribution network robots typically generate inspection-related results through multiple software modules during inspection tasks. These modules include visible light analysis, infrared analysis, alarm output, image capture, action log, and manual review. These results include anomaly identification, alarms, action records, manual review conclusions, and associated image, video, and log index information. Existing distribution network inspection robot systems often employ a decentralized upload approach. Different software modules upload results to the backend platform as logs, interface messages, image indexes, or temporary files. The backend platform then displays alarms, generates inspection reports, or performs manual review based on these scattered records. However, in practical engineering applications, the same anomaly often doesn't just result in a single isolated record. Instead, it undergoes multiple stages: initial discovery, re-capture, result correction, manual review, and final archiving. Data from these different stages is typically output by different software modules using different data formats, upload times, and storage locations. This results in related data for the same defect being scattered and difficult to correlate on the platform. Meanwhile, the existing system's upload method is rather crude. Each module either independently uploads the entire data, creating bandwidth pressure, or only uploads the final result, resulting in missing intermediate processes. Especially in scenarios such as underground power distribution rooms, enclosed passages, and areas with fluctuating signals, the robot end also encounters problems such as weak networks, offline status, high latency, lost confirmations, and duplicate uploads. The existing process lacks differentiated upload strategies, incremental retransmission mechanisms, deduplication control, and sequence recovery methods for the same defect event. This makes it easy for anomaly-related data to be missed, duplicated, or out of order during transmission. The platform end finds it difficult to maintain a continuous event thread around the same anomaly target and cannot reliably recover the complete process of the same defect from discovery to archiving. Summary of the Invention

[0003] To address the aforementioned shortcomings, the present invention aims to propose a hierarchical retransmission method and system for defect events in power distribution robots. This system encapsulates multi-source heterogeneous original results into defect event objects containing a main event identifier, parent event identifier, stage identifier, and upload sequence number. It then performs object encapsulation, event package hierarchical transmission, event-level retransmission, platform recovery, and process state invocation on multi-source results generated at different stages around the same abnormal target. This enables continuous management and reliable traceability of the same defect event from its initial discovery to final archiving.

[0004] To achieve this objective, the present invention adopts the following technical solution: A method for hierarchical retransmission of defect events in power distribution robots includes: Receive multi-source raw results and evidence indexes associated with the same anomalous target generated by multiple software modules; The multi-source original results and evidence index are uniformly encapsulated into a defect event object, which includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number. Based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status, a summary event package, a key event package, a full event package, or an incremental event package is generated for the defect event object. When the network is normal, the event packet is sent to the platform; when the network is unstable, the platform does not confirm, or the sending fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. Based on the event master identifier, parent event identifier, stage identifier and upload sequence number, the event package is deduplicated at the event level, restored in sequence and restored at the stage to obtain the restoration results of the same defect event at different stages. Based on the recovery results, combined with the source identifier and the evidence index, a process state sequence for the same defect event is organized, and the process state sequence is provided to downstream function calls.

[0005] Preferably, the defect event object further includes version information; The platform performs event-level deduplication, sequential recovery, stage recovery, and version environment association on the event package based on the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information, so as to obtain the recovery results of the same defect event in different stages and different version environments.

[0006] Preferably, the step of uniformly encapsulating the multi-source original results and evidence index into a defect event object includes: Extract basic fields from visible light anomaly results, infrared anomaly results, alarm results, action logs, manual review results, and task context; Map the unique anomaly number in the basic fields to the event master identifier, map the associated original master event number to the parent event identifier, map the stage information to the stage identifier, map the upstream source type to the source identifier, map the evidence file path or storage key to the evidence index, and map the sending sequence number to the upload sequence number. Perform unified format normalization processing on heterogeneous data formats from different upstream modules, convert time fields into a unified timestamp format, map anomaly levels to a preset level set, map source types to a preset source code, convert file paths or storage keys into a standardized representation, and fill or set null values, default values, and anomaly values ​​according to preset rules. For raw results that only include partial information, fill in the missing fields based on the task context and event relationships; After completing field extraction, field mapping, format normalization, and association completion, the results are uniformly encapsulated into the defect event object.

[0007] Preferably, generating summary event packages, critical event packages, full event packages, or incremental event packages for the defect event object based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status includes: When the network status is below a preset threshold and the current event has not yet formed a complete evidence set, a summary event package is generated. The summary event package includes the event main identifier, the anomaly level, the timestamp, and the upload sequence number, which is used to enable the platform to complete event logging and lightweight perception. When the anomaly level is higher than a preset threshold and the current evidence is not yet complete, a key event package is generated. The key event package includes the fields of the summary event package, the source identifier, the result score, and the key evidence index, which is used to enable the platform to prioritize the detection of key anomalies. When the network status is normal and the evidence index meets the completeness requirements, a full event package is generated. The full event package includes all fields of the defective event object and a complete evidence index set, which is used by the platform to directly restore the complete main event data. When the same event master identifier enters a new stage identifier, or when the evidence index, result score, or event status is added, an incremental event package is generated. The incremental event package includes the event master identifier, the parent event identifier, the new stage identifier, and the new evidence index, and does not repeatedly send the full data of the confirmed master event.

[0008] Preferably, the generation of summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects is performed according to the following preset conditions: When the network status is below the first threshold and the current event has not yet formed a complete evidence set, the summary event packet is generated, a lightweight result is sent first and the main event identifier and time information are retained, and the data is uploaded after the network is restored. When the anomaly level is higher than the second threshold and the current evidence is not yet complete, the key event package is generated, and the anomaly level, key evidence index and action summary are sent first. When the network status is normal and the evidence index meets the completeness requirements, the full event packet is generated and the complete defect event object and complete evidence index are sent. When the same event master identifier enters a new stage identifier, or when a new evidence index, result score, or event status is added, the incremental event package is generated. Only the newly added stage content is transmitted, and the full data of the confirmed master event is not sent repeatedly. When the same event master identifier and stage identifier already exist, and the currently uploaded content is consistent with the cached content, no new event package is generated, and local deduplication is performed directly on the robot side.

[0009] Preferably, the step of performing retransmission, deduplication, and order maintenance according to the upload sequence number and event priority includes: A retransmission state machine is established around a single defect event object. The retransmission state machine includes an initial state, a state to be sent, a state that has been sent but not acknowledged, a state to be retransmitted, a state in the process of retransmission, a state that has been acknowledged, and a state that has been closed. After the main event is generated for the first time, it enters the pending state; after the event packet is sent, it enters the sent but unacknowledged state. If no confirmation information for the event master identifier and the upload sequence number is received from the platform within the preset time, the process will switch to the pending transmission state and the corresponding event packet will be retained in the pending transmission index table. The event packets to be retransmitted are sorted by their exception level, generation time, and upload sequence number and then enter the retry queue. When the network recovers or the retry conditions are met, they are transferred to the retransmission state. After successful retransmission and receipt of a confirmation message from the platform, the system transitions to the confirmed state. The confirmation message carries the event master identifier, the upload sequence number, the confirmation timestamp, and the confirmation result. The robot updates the confirmation status based on the confirmation message. The event transitions to the closed state after it is closed or archived.

[0010] Preferably, the process state sequence for organizing the same defect event includes: After receiving the main event and incremental events, the platform performs unified recovery processing on the event package according to the state recovery key set, which includes the main event identifier, the parent event identifier, the stage identifier, the upload sequence number, and the version information. Under the constraints of the state recovery key set, event-level deduplication, sequential recovery, and stage recovery are performed on the event package. The main event and each incremental event are repaired and organized into a unified process state sequence. The process state sequence corresponds to the stage chain of the same defect event from initial discovery, reshoot, correction, review to archiving closure. The repaired process status sequence is provided for use in full process playback, alarm invocation, report generation, and manual review functions.

[0011] A graded compensation system for defect events in power distribution network robots includes: The task access module is used to receive multi-source raw results and evidence indexes related to the same abnormal target generated by multiple software modules. The object encapsulation module is used to encapsulate the multi-source original results and evidence index into a defect event object. The defect event object includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number. The hierarchical generation module is used to generate summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status. The cache retransmission module is used to send the event packet to the platform when the network status is normal; when the network is unstable, the platform does not confirm, or the transmission fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. The platform recovery module is used to perform event-level deduplication, sequential recovery, and stage recovery on the event package based on the event master identifier, parent event identifier, stage identifier, and upload sequence number, so as to obtain the recovery results of the same defect event at different stages. The status call module is used to organize a process status sequence for the same defect event based on the recovery result, combined with the source identifier and the evidence index, and provide the process status sequence to downstream function calls.

[0012] One of the above technical solutions has the following advantages or beneficial effects: This invention receives multi-source raw results and evidence indexes associated with the same anomalous target generated by multiple software modules. It then encapsulates these diverse and scattered raw results into a single defect event object containing an event master identifier, parent event identifier, stage identifier, source identifier, evidence index, and upload sequence number. This allows heterogeneous data generated by different modules at different stages of the same anomalous target to be uniformly associated with the same software object, thus solving the problem of scattered storage and lack of unified data units in existing technologies. Furthermore, based on the anomaly level, evidence completeness, current network status, and platform confirmation status, the invention dynamically generates summary event packages, key event packages, full event packages, or incremental event packages for the defect event object. This enables the system to adaptively select the upload granularity based on event maturity and network environment, avoiding bandwidth pressure caused by full uploads or uploading only the final result. This results in missing process information. Subsequently, when the network is unstable, the platform fails to confirm, or the transmission fails, the event packet is written to the local cache queue. Then, according to the upload sequence number and event priority, retransmission, deduplication, and order maintenance are performed to establish a controllable state transition mechanism around a single defect event, ensuring reliable upload and order recovery of abnormal related records in weak network environments. Finally, the platform performs event-level deduplication, order recovery, and stage recovery on the event packet based on the event master identifier, parent event identifier, stage identifier, and upload sequence number to obtain the recovery results of the same defect event at different stages. Combined with the source identifier and evidence index, it is organized into a process state sequence that can be called by downstream functions. This enables the platform to reliably restore the complete lifecycle of the same defect event from its first discovery through re-photographing, correction, review to archiving and closure, providing a continuous and consistent data foundation for full-process playback, alarm invocation, report generation, and manual review. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0014] Figure 1 This is a flowchart of the graded retransmission method for defect events of distribution network robots provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of the distribution network robot defect event graded compensation system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the prior art software processing flow provided in the embodiments of the present invention; Figure 4 This is a schematic diagram illustrating the implementation of the graded retransmission software method for defect events in distribution network robots provided in this embodiment of the invention; Figure 5 This is a schematic diagram illustrating the hierarchical relationship between system data flow and event packets provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the event-level retransmission state machine provided in an embodiment of the present invention; Figure 7 This is a diagram showing the relationship between the state recovery and playback of the same defect event provided in an embodiment of the present invention. Detailed Implementation

[0015] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0016] In this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0017] like Figure 3As shown, the software processing flow of the existing power distribution network inspection robot system operates along the following path: During the execution of the inspection task, different software modules, such as the visible light analysis module, infrared analysis module, alarm output module, capture module, action log module, and manual review module, generate recognition results, alarm results, and log records respectively; The results from the above-mentioned different modules are independently uploaded to the backend platform in the form of log text, interface messages, image indexes, or temporary files; After receiving the above-mentioned scattered data, the backend platform parses the data from different sources and generates alarm displays or inspection reports. However, the existing technical processes described above have the following drawbacks: The same abnormal target often undergoes multiple stages during actual inspections, including initial discovery, re-photographing, correction, verification, and archiving. However, in the existing process, data from each stage is scattered across different records, lacking a unified software object for association, making it difficult for the platform to identify which records belong to the same defect. The upload method is relatively crude; each module either independently uploads the entire data, creating bandwidth pressure, or only uploads the final result, resulting in missing intermediate processes. In weak network scenarios such as underground power distribution rooms and enclosed passages, the existing process lacks differentiated upload strategies, incremental re-upload mechanisms, deduplication control, and sequence recovery methods around the same defect event. Abnormal data is prone to omission, duplication, or out-of-order transmission. Although the platform can display some scattered records, it cannot maintain a continuous event thread around the same abnormal target, making it difficult to reliably recover the complete process of the same defect from discovery to archiving.

[0018] A method for hierarchical retransmission of defect events in power distribution robots, such as Figure 1 As shown, a preferred embodiment of the present invention includes the following steps: S1. Receive multi-source raw results and evidence indexes associated with the same anomalous target generated by multiple software modules; It should be noted that multi-source original results refer to the identification conclusions and status records related to equipment anomalies independently generated by different functional software modules on the distribution network robot during the inspection process. For example, the anomaly category and anomaly location judgment output by the visible light analysis module, the temperature characteristics and hot spot area identification results output by the infrared analysis module, the alarm level and type information generated by the alarm output module, the image index generated by the capture module, the action type and occurrence time recorded by the action log module, and the review conclusions and opinions submitted by the manual review module. The evidence index refers to the storage path, index number or object storage key pointing to the image file, video clip, log record or analysis result file associated with the current anomaly, which is used to locate and retrieve the corresponding original evidence materials on the platform. The same anomaly target refers to the same equipment defect or abnormal state that is identified or continuously monitored by multiple software modules in the inspection task. For example, the infrared overheating anomaly of the transformer terminal clamp in a power distribution room may be simultaneously marked as temperature over-limit by the infrared analysis module, associated as appearance discoloration by the visible light analysis module, and triggered as a temperature rise alarm by the alarm module. The role of multi-source raw results in this step is to provide heterogeneous but semantically related input data for subsequent unified encapsulation. The role of evidence index is to provide traceable original material location information for subsequent review and display on the platform. The role of the same abnormal target is to establish a semantic association basis for related records scattered in the output of different modules.

[0019] Understandably, by continuously receiving raw results from multiple independent software modules such as visible light, infrared, alarms, snapshots, logs, and manual verification from the robot, and associating and aggregating these results with evidence indexes pointing to the same abnormal location of the device, a multi-dimensional data association relationship for the same abnormal target can be established at the data entry point. This avoids the outputs of different modules being isolated from each other in subsequent processing, thus providing a complete and related input foundation for building a unified data object around the same defect event.

[0020] S2. The multi-source original results and evidence index are uniformly encapsulated into a defect event object, which includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number; It should be noted that a defect event object refers to a software data entity formed by standardizing and organizing heterogeneous raw results from different software modules according to a unified data structure. This entity serves as the smallest processing unit for subsequent hierarchical uploading, cache re-uploading, and platform recovery. The event master identifier is a code or number used to uniquely identify a defect event within the system. For example, it may be a string or integer number generated by combining a timestamp and a location number, used as a primary key in subsequent caching, deduplication, and recovery processes. The parent event identifier is a related field used to identify whether the current event is derived from an existing event. When the current record involves re-uploading, correcting, reviewing, or closing an existing defect, this field points to the identifier of the original master event, thus establishing a derivation relationship between events. The stage marker... The "Identifier" refers to a marker indicating the current lifecycle stage of a defect event, such as initial discovery, supplementary verification, review, or archiving. This is used on the platform to distinguish the processing progress of the same defect at different stages. The "Source Identifier" identifies which software module the current data record originated from, such as the visible light module, infrared module, alarm module, log module, or manual review module, facilitating the platform's identification of the data's original source. The "Evidence Index" refers to the location information pointing to images, videos, logs, or result files associated with the current defect event, such as file paths, object storage keys, or database index numbers. The "Upload Sequence Number" is an integer number identifying the sequential position of the event packet in the transmission sequence, used by the platform to restore the correct timing in weak network or out-of-order transmission scenarios. In this step, the main event identifier provides a globally unique identity for the same defect event; the parent event identifier establishes the event derivation chain; the stage identifier marks the event processing progress; the source identifier traces the data generation module; the evidence index associates original evidence materials; and the upload sequence number ensures the transmission order can be recovered.

[0021] Understandably, by extracting key information from multi-source raw results with varying formats and field definitions and mapping it to unified standardized fields, defect event objects containing event master identifier, parent event identifier, stage identifier, source identifier, evidence index, and upload sequence number are formed. This achieves the goal of converting scattered and heterogeneous module outputs into homogeneous data units, enabling data from the same abnormal target generated by different modules at different stages to be uniformly associated and subsequently processed, avoiding the inability to aggregate data from different sources due to format differences.

[0022] S3. Generate summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status. It should be noted that the anomaly level refers to the quantitative or qualitative classification of the severity of the current defect event, such as normal, moderate, severe, and critical levels, used to determine the priority and urgency of event packet generation; the completeness of evidence refers to whether the evidence index collected for the current defect event meets the requirements of the platform for fully recovering the event at this stage, such as whether it includes key evidence such as visible light images, infrared thermal images, log records, and review conclusions; the current network status refers to the quality indicators of the communication link between the robot and the platform, such as signal strength, transmission delay, or bandwidth availability, used to determine whether it is suitable to send large volumes of data; the platform confirmation status refers to the feedback flag of the platform on whether the previously sent event packets have been successfully received and verified, such as confirmed or unconfirmed, used to determine whether further confirmation is needed. To generate either a retransmission packet or an incremental packet, the following steps are required: A summary event packet is a lightweight upload packet containing only the minimum necessary fields such as event identity information and basic anomaly level. It is used to complete event logging on the platform when network restrictions are limited or evidence is insufficient. A critical event packet is a medium-granularity upload packet that adds source identifier, result score, and key evidence index to the summary event packet. It is used to prioritize reporting key information when the anomaly risk is high but the evidence is not yet complete. A full event packet is a complete upload packet containing all fields of the complete defect event object and a complete set of evidence indexes. It is used to allow the platform to directly recover the main event data when the network is normal and the evidence is complete. An incremental event packet is a differential upload packet for defects in existing main events, uploading only the newly added stage identifier, newly added evidence index, and newly added status fields. It is used to avoid repeatedly sending confirmed data. The anomaly level in this step provides risk weights for event packet selection; the evidence completeness determines whether the conditions for sending full data are met; the current network status constrains the upload granularity to avoid transmission failure; and the platform confirmation status distinguishes between the initial report and subsequent appended reports.

[0023] Understandably, by using defect event objects as carriers, and comprehensively assessing the severity of the current anomaly, the completeness of the collected evidence, the availability of the network link, and the platform's confirmation of historical data, the system dynamically selects to generate summary event packets, critical event packets, full event packets, or incremental event packets. This achieves the goal of adaptively matching the upload granularity with the current event maturity and network environment, avoiding transmission failure or congestion caused by forcibly sending full data when bandwidth is limited, and avoiding the inability of the platform to fully recover event data when only summary information is sent when evidence is complete and the network is normal. Thus, the system optimizes the use of communication resources while ensuring priority perception of critical anomalies.

[0024] S4. When the network status is normal, the event packet is sent to the platform. When the network is unstable, the platform does not confirm, or the sending fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. It should be noted that "normal network status" means that the communication link between the robot and the platform has stable transmission capabilities, such as signal strength exceeding the available threshold and transmission latency within an acceptable range, which can support the real-time transmission of event packets. "Unstable network" means that the communication link experiences fluctuations, increased latency, or intermittent interruptions, such as weak network environments in underground power distribution rooms or enclosed passages, resulting in unreliable real-time transmission. "Platform unacknowledged" means that the platform does not return a receipt confirmation feedback for the sent event packet within a preset time, or the returned feedback indicates that reception failed. "Sending failure" means that the robot failed to complete the transmission when attempting to send the event packet due to network abnormalities or connection interruptions. A local cache queue refers to a persistent or semi-persistent storage structure deployed on the robot's edge host. It's used to temporarily store event packets to be sent when sending conditions are not met, such as a cache index table implemented based on a local database or file queue. Retransmission refers to the process of retrying to send the event packet to be retransmitted according to preset rules after the initial transmission fails or the acknowledgment times out. Deduplication refers to identifying and removing duplicate event packets on the robot or platform side to avoid the same data occupying bandwidth or being stored multiple times. Sequence maintenance refers to controlling the sending and recovery order of event packets based on the upload sequence number to ensure that the event sequence received by the platform is consistent with the event sequence generated by the robot. In this step, the local cache queue provides reliable temporary storage space for event packets that cannot be sent successfully. Retransmission ensures that event packets are eventually delivered to the platform after network recovery. Deduplication avoids wasting bandwidth and storage resources on duplicate data. Sequence maintenance ensures the correctness of the event sequence so that the platform can accurately reconstruct the defect evolution process.

[0025] Understandably, by establishing a temporary storage mechanism based on a local cache queue on the robot side, and writing event packets into this queue when the network is unstable, the platform does not confirm, or the transmission fails, and then performing retransmission, deduplication, and order maintenance according to the upload sequence number and event priority, the goal is to ensure that event packets are not lost when network conditions fluctuate and to complete the final delivery in the correct order after communication is restored. This avoids the loss of event records on the platform due to the direct discarding of failed data in weak network environments. At the same time, the deduplication mechanism avoids data redundancy on the platform caused by repeated transmissions due to network jitter.

[0026] S5. Based on the event master identifier, parent event identifier, stage identifier and upload sequence number, perform event-level deduplication, sequence restoration and stage restoration on the event package to obtain the restoration results of the same defect event at different stages; It should be noted that event-level deduplication refers to the platform identifying and removing duplicate event packets after receiving them, based on key fields such as the event master identifier, stage identifier, and upload sequence number, to prevent the same defect record from being entered into the database multiple times. Sequence restoration refers to the platform reordering event packets whose received order was disordered due to weak network or out-of-order transmission, restoring them to the correct sequence consistent with the timing generated by the robot. Stage restoration refers to the platform classifying event packets belonging to the same defect event but in different lifecycle stages into the corresponding stage nodes based on the stage identifier. For example, events in the stages of initial discovery, re-shooting, correction, review, and archiving closure are respectively assigned to their respective positions, forming a stage chain. The restoration result refers to the complete and non-redundant data set of the same defect event under each stage obtained by the platform after completing deduplication, sorting, and stage classification, which can be used for subsequent process state sequence organization. The role of the event master identifier in this step is to provide an aggregated primary key for the full data of the same defect event. The role of the parent event identifier is to establish the derived association between the incremental event and the master event. The role of the stage identifier is to distinguish the processing nodes of the same defect at different times. The role of the upload sequence number is to reconstruct the correct time sequence of the event.

[0027] Understandably, the platform aggregates all received records of the same defect based on the main event identifier, identifies the derivation relationship between incremental events and the main event using the parent event identifier, assigns each record to the corresponding lifecycle node according to the stage identifier, and sorts and reconstructs out-of-order data based on the upload sequence number. This achieves the purpose of eliminating duplicate data, restoring the correct time sequence, and reconstructing the stage evolution process, enabling the platform to reliably reconstruct the complete stage chain of the same defect event from scattered and potentially out-of-order duplicate uploaded data.

[0028] S6. Based on the recovery results, combined with the source identifier and the evidence index, organize the process state sequence of the same defect event, and provide the process state sequence to downstream function calls.

[0029] It should be noted that the process state sequence refers to the continuous state chain formed by linking the records of each stage of the same defect event from its initial discovery through re-shooting, correction, review, and archiving closure in the correct chronological order after the platform has completed event-level deduplication, sequential recovery, and stage recovery. This sequence reflects the complete lifecycle evolution of the defect event from its generation to its elimination. Downstream function call refers to the platform providing the organized process state sequence to upper-level business modules such as alarm systems, reporting systems, manual review systems, or full-process playback functions to support business scenarios such as alarm display, inspection report generation, operation and maintenance review decisions, or historical process backtracking. The role of the source identifier in this step is to mark the original source of the data for each stage node in the process state sequence, so that downstream modules can identify whether the records of each stage come from visible light, infrared, alarm, log, or manual review modules. The role of the evidence index is to provide the location information of the original evidence materials for each stage node in the process state sequence, so that downstream modules can directly retrieve the corresponding images, videos, or log files for display or analysis.

[0030] Understandably, by combining the recovery results with the source identification data generation module of each stage record and the evidence index to associate with the original evidence materials, the recovery records of the same defect event scattered in each stage are organized into a continuous process state sequence. This sequence is then provided to the alarm system, reporting system, manual review system, or full process playback function. This allows the platform to continuously present the complete evolution process of the same defect from discovery to archiving from a unified perspective, preventing downstream modules from only obtaining scattered and isolated result records and being unable to perceive the whole picture of the event.

[0031] like Figure 4As shown, the implementation process of the distribution network robot defect event hierarchical retransmission method of this application consists of two parts: robot-side software and platform-side software. Its workflow follows the main line of "task context access → multi-source original result input → defect event object encapsulation → event package hierarchical generation → event-level local caching and retransmission → platform reception and recovery → process status call". During the task context access phase, the robot loads context information such as task number, location information, equipment information, software version, model version, and rule version, providing a unified foundation for subsequent encapsulation and recovery. During the multi-source raw result input phase, the robot continuously receives raw results and related evidence indexes generated by the visible light analysis module, infrared analysis module, alarm output module, capture module, action log module, and manual review module. During the defect event object encapsulation phase, the robot uniformly encapsulates the aforementioned multi-source heterogeneous raw results into a defect event object containing an event master identifier, parent event identifier, stage identifier, source identifier, evidence index, and upload sequence number, achieving unified association of results formed for the same abnormal target at different stages. During the event package hierarchical generation phase, the system dynamically generates summary event packages, key event packages, and full event packages for the defect event object based on the abnormality level, evidence completeness, current network status, and platform confirmation status. The system uses either packaged or incremental event packets to adapt to the upload requirements of different inspection scenarios. During the event-level local caching and retransmission phase, when the network is normal, the event packet is directly sent to the platform. When the network is unstable, the platform does not confirm, or the transmission fails, the event packet is written to the local cache queue and retransmitted, deduplicated, and maintained in sequence according to the upload sequence number and event priority. During the platform reception and recovery phase, the platform performs field validation, event-level deduplication, sequence recovery, and phase recovery on the event packet based on the basic key set such as the event master identifier, parent event identifier, phase identifier, and upload sequence number, to obtain the recovery results of the same defect event at different stages. During the process status call phase, the platform further organizes the process status sequence of the same defect event based on the recovery results and provides this sequence to the alarm system, reporting system, manual review system, or full-process playback function, thereby realizing continuous management and full-process traceability of the same defect event from its first discovery to its final archiving.

[0032] Preferably, the defect event object further includes version information; The platform performs event-level deduplication, sequential recovery, stage recovery, and version environment association on the event package based on the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information, so as to obtain the recovery results of the same defect event in different stages and different version environments.

[0033] It should be noted that version information refers to a field recording the software environment version in which the defect event object was generated, including the software version number, model version number, and rule version number. This field is extracted from the task context and written into the defect event object to identify the technical environment background in which data was generated at different stages during the platform's recovery process. Version environment association refers to the platform binding the data records of the same defect event at different stages with their corresponding version information when performing event recovery based on the state recovery key set. This allows the platform to identify which software version, model version, and rule version generated the results at each stage, facilitating the differentiation of results and environmental review in cross-version scenarios. Version information is obtained on the robot's end by reading the currently deployed software version configuration file, model version identifier file, and rule version identifier file. It is written as an additional field of the defect event object during the encapsulation stage and transmitted to the platform along with the event package.

[0034] It is understandable that by adding version information to defect event objects, the platform can further associate data of the same defect event at different stages based on version information, in addition to performing event-level deduplication, sequential recovery, and stage recovery based on the event master identifier, parent event identifier, stage identifier, and upload sequence number. This achieves the goal of enabling the platform to clearly distinguish the technical environment that generated the same defect event at different lifecycle stages in cross-software iteration or model update scenarios, avoiding confusion between historical results and the current environment caused by software version changes. This provides an accurate environmental tracing basis for subsequent cross-version result comparison, model effect backtracking, and rule change impact analysis.

[0035] Specifically, during the task context access phase, the robot loads the current software version number, model version number, and rule version number, and writes the above version information into the `version_info` field when encapsulating the defect event object. After receiving the event package, the platform performs recovery processing based on the extended state recovery key set consisting of the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information. In the event-level deduplication phase, the platform uses the combination of the event master identifier, stage identifier, upload sequence number, and version information as a unique constraint to identify and eliminate duplicate event packages in the same version environment. In the sequence recovery phase, the platform sorts the events according to the upload sequence number under the same event master identifier and the same version information to restore the correct time sequence of event generation. In the stage recovery phase, the platform assigns each record to the corresponding lifecycle node according to the stage identifier and adds version information to mark the environment in which the data was generated in that stage. In the version environment association phase, the platform binds the recovery results of different stages under the same defect event to its version information, forming a stage chain with environment tags. When the same defect event spans multiple version cycles, the platform can distinguish the differences in the technical environment of different stages based on the version information.

[0036] Preferably, the step of uniformly encapsulating the multi-source original results and evidence index into a defect event object includes: Extract basic fields from visible light anomaly results, infrared anomaly results, alarm results, action logs, manual review results, and task context; Map the unique anomaly number in the basic fields to the event master identifier, map the associated original master event number to the parent event identifier, map the stage information to the stage identifier, map the upstream source type to the source identifier, map the evidence file path or storage key to the evidence index, and map the sending sequence number to the upload sequence number. Perform unified format normalization processing on heterogeneous data formats from different upstream modules, convert time fields into a unified timestamp format, map anomaly levels to a preset level set, map source types to a preset source code, convert file paths or storage keys into a standardized representation, and fill or set null values, default values, and anomaly values ​​according to preset rules. For raw results that only include partial information, fill in the missing fields based on the task context and event relationships; After completing field extraction, field mapping, format normalization, and association completion, the results are uniformly encapsulated into the defect event object.

[0037] It should be noted that the basic fields refer to the raw data items extracted from the original output of the upstream software module. These include: anomaly category, anomaly location, anomaly score, captured image index, and timestamp extracted from visible light anomaly results; anomaly category, temperature characteristics, hotspot area index, anomaly score, and timestamp extracted from infrared anomaly results; alarm level, alarm type, alarm time, and associated location extracted from alarm results; action type, action occurrence time, and action summary extracted from action logs; review conclusion, review time, and review comments extracted from manual review results; and task number, location number, equipment number, and component number extracted from the task context. These fields serve as the raw input for subsequent mapping and encapsulation. The unique anomaly number is a temporary or persistent identifier assigned by the upstream module to the anomaly result, such as the temporary record number assigned by the visible light module to detected anomalies, used to convert it into the event master identifier during the mapping process. The original master event number is the associated number in the upstream module that identifies the existing defect master event. When the result belongs to reshooting, correction, or review, the number points to the original event and is used to map to the parent event identifier; the sending sequence number is the sequence number of the event packet when it is generated, which is assigned by the robot-side sending manager according to the generation order and is used to map to the upload sequence number; unified format normalization refers to the process of performing standardized conversion on heterogeneous data formats such as JSON, log text, structured forms, or key-value pairs that may be used by different upstream modules; the preset level set is a predefined anomaly level classification system of the system, for example, uniformly mapping different risk descriptions of each module to four levels: normal, general, severe, and critical; the preset source code is a predefined module source identifier coding system of the system, for example, uniformly coding sources such as visible light, infrared, alarms, logs, and manual review as SRC_VIS, SRC_IR, SRC_ALM, SRC_LOG, and SRC_REV; local information refers to the original results of some upstream modules that only output some fields, for example, the capture module only provides image index and timestamp but not task information.

[0038] Understandably, by extracting basic fields from visible light, infrared, alarms, logs, manual review, and task context, and mapping the unique anomaly number, original master event number, stage information, source type, evidence file path, and sending sequence number in the basic fields to event master identifier, parent event identifier, stage identifier, source identifier, evidence index, and upload sequence number, respectively, and then performing unified format normalization processing on the heterogeneous data formats of different upstream modules, and supplementing missing fields for the original results containing only partial information according to the task context and event association, the final results are uniformly encapsulated into defect event objects. This achieves the goal of converting multi-source original results with different formats and field definitions into homogeneous standardized data units, enabling data generated by different modules at different stages to be uniformly associated and subsequently processed, and avoiding the inability to aggregate related records of the same defect on the platform due to differences in data format and missing fields.

[0039] Specifically, after receiving the output from the upstream module, the defect event object encapsulation module on the robot side first performs field extraction operations. This involves extracting the anomaly category, anomaly location, anomaly score, captured image index, and timestamp from the visible light anomaly results; extracting temperature features, hotspot area index, and anomaly score from the infrared anomaly results; extracting the alarm level and alarm type from the alarm results; extracting the action type and action occurrence time from the action log; extracting the review conclusion and review time from the manual review results; and extracting the task number, location number, and device number from the task context. Subsequently, a field mapping operation is performed. This maps the unique anomaly number EVT_TMP_001 output by the visible light module to the event master identifier EVT_20240511_143052. If the current result is a re-capture result, it maps the associated original master event number EVT_20240511_143052 to the parent event identifier. The stage description (first discovery) is mapped to the stage identifier S1, the source type (visible light) is mapped to the source identifier SRC_VIS, and the image file path is mapped to... The path is mapped to the evidence index, and the sending sequence number 1 is mapped to the upload sequence number. Then, a unified format normalization process is performed, converting the time fields in the original JSON or log text of each module into the Unix timestamp format 1715418652. The anomaly score of 0.82 output by the visible light module and the temperature feature of 65℃ output by the infrared module are mapped to anomaly level 2 according to the preset level set. The source names of each module are mapped to the standardized code according to the preset source code. The relative file paths are uniformly converted into a standardized representation. Missing review opinion fields are set to empty according to preset rules. Then, for local information such as image index and timestamp output by the capture module, the task number T2024051101 and the location number P001 are completed according to the task context. After completing the above processing, the encapsulation module writes all the extracted, mapped, normalized and completed fields into the defect event object data structure to form a standardized object containing the event master identifier, parent event identifier, stage identifier, source identifier, evidence index, upload sequence number and version information.

[0040] Preferably, generating summary event packages, critical event packages, full event packages, or incremental event packages for the defect event object based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status includes: When the network status is below a preset threshold and the current event has not yet formed a complete evidence set, a summary event package is generated. The summary event package includes the event main identifier, the anomaly level, the timestamp, and the upload sequence number, which is used to enable the platform to complete event logging and lightweight perception. When the anomaly level is higher than a preset threshold and the current evidence is not yet complete, a key event package is generated. The key event package includes the fields of the summary event package, the source identifier, the result score, and the key evidence index, which is used to enable the platform to prioritize the detection of key anomalies. When the network status is normal and the evidence index meets the completeness requirements, a full event package is generated. The full event package includes all fields of the defective event object and a complete evidence index set, which is used by the platform to directly restore the complete main event data. When the same event master identifier enters a new stage identifier, or when the evidence index, result score, or event status is added, an incremental event package is generated. The incremental event package includes the event master identifier, the parent event identifier, the new stage identifier, and the new evidence index, and does not repeatedly send the full data of the confirmed master event.

[0041] It should be noted that the preset threshold refers to the network quality judgment boundary set in advance by the system, used to distinguish whether the network status meets the real-time transmission conditions. This threshold is set based on the signal strength or transmission delay indicators between the robot end and the platform end. The first threshold is the lower limit value in network status judgment. When the network status indicator is lower than this value, it is judged as a weak network environment, triggering the generation of summary event packets. The second threshold is the upper limit value in anomaly level judgment. When the anomaly level indicator of the current defect is higher than this value, it is judged as a serious anomaly, triggering the generation of critical event packets. The complete evidence set refers to the collection of all evidence materials required by the platform end to recover the main event at a certain stage, including visible light image index, red light image index, etc. The system includes external heat map index, log file index, and analysis result file index. Completeness requirements refer to the preset conditions for determining whether the currently collected evidence index meets the standard for a complete evidence set. The system checks each item according to the current stage type and evidence type list. Action summary refers to a summary description of the actions performed by the robot in response to the anomaly, such as re-capturing, dwelling, or re-capturing. Result score refers to the quantitative value of the anomaly determination intensity given by the upstream module, such as an anomaly score of 0.82 output by the visible light module. Key evidence index refers to the location information of the core evidence file that best represents the anomaly characteristics at the current stage, such as the capture image with the highest anomaly score or the heat map file index with the highest temperature.

[0042] Understandably, by using defective event objects as carriers, a comprehensive assessment is made of the current anomaly level, the completeness of collected evidence, the availability of network links, and the platform's confirmation of historical data. When the network status is below a preset threshold and the evidence is incomplete, a summary event packet containing only the minimum necessary fields is generated. When the anomaly level is above a preset threshold and the evidence is incomplete, a key event packet containing key judgment information is generated. When the network status is normal and the evidence meets the completeness requirements, a full event packet containing all fields and complete evidence is generated. When the same event's main identifier enters a new stage or new evidence is added, an incremental event packet containing only differential information is generated. This achieves the goal of adaptively matching the upload granularity with the current event maturity and network environment, avoiding the transmission failure or congestion caused by forcibly sending full data when bandwidth is limited, and avoiding the inability of the platform to fully recover event data when only summary information is sent when evidence is complete and the network is normal. Thus, while ensuring priority perception of key anomalies, the use of communication resources is optimized, and bandwidth waste is avoided by repeatedly sending full data for the same event at different stages.

[0043] Specifically, such as Figure 5As shown, the event packet classification generation module on the robot side determines the event packet type of defective events according to the relationship between the system data flow and the event packet classification. Upstream of the data flow, the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status are input parameters into the classification function P=f(L,C,N,A), where L represents the anomaly level, C represents the completeness of evidence, N represents the network status, and A represents the platform confirmation status. When the robot side detects that the network status is below the first threshold and the current event has not yet formed a complete evidence set, such as when the signal strength in an underground power distribution room is weak and only the preliminary identification result of the visible light analysis module is received, a summary event packet is generated. This summary event packet contains the event main identifier, task number, location number, anomaly level, timestamp, and upload sequence number, which is used to enable the platform side to complete event logging and lightweight perception first. When the anomaly level is above the second threshold and the current evidence is not yet complete, such as when the infrared analysis module determines that the hotspot temperature has reached the severe level. However, if not all locations have been re-inspected, a critical event package is generated. This critical event package adds a source identifier, result score, and key evidence index to the fields of the summary event package, enabling the platform to prioritize the detection of key anomalies. When the network status is normal and the evidence index meets the completeness requirements, such as when the robot is in a good signal area and has completed all evidence collection including visible light capture, infrared temperature measurement, alarm triggering, action recording, and manual review, a full event package is generated. This full event package contains all fields of the defect event object and a complete set of evidence indexes, allowing the platform to directly recover the complete master event data. When the same event master identifier enters a new stage identifier or when new evidence indexes, result scores, or event statuses are added, such as when a new stage record is generated after performing a re-capture operation on an existing defect, an incremental event package is generated. This incremental event package contains the event master identifier, parent event identifier, new stage identifier, and new evidence index, and does not repeatedly send the confirmed full data of the master event.

[0044] Preferably, the generation of summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects is performed according to the following preset conditions: When the network status is below the first threshold and the current event has not yet formed a complete evidence set, the summary event packet is generated, a lightweight result is sent first and the main event identifier and time information are retained, and the data is uploaded after the network is restored. When the anomaly level is higher than the second threshold and the current evidence is not yet complete, the key event package is generated, and the anomaly level, key evidence index and action summary are sent first. When the network status is normal and the evidence index meets the completeness requirements, the full event packet is generated and the complete defect event object and complete evidence index are sent. When the same event master identifier enters a new stage identifier, or when a new evidence index, result score, or event status is added, the incremental event package is generated. Only the newly added stage content is transmitted, and the full data of the confirmed master event is not sent repeatedly. When the same event master identifier and stage identifier already exist, and the currently uploaded content is consistent with the cached content, no new event package is generated, and local deduplication is performed directly on the robot side.

[0045] It should be noted that the first threshold is the lower limit for network status determination. When the signal strength or transmission delay index detected by the robot is lower than this value, the system determines that it is currently in a weak network environment and triggers the summary event packet generation logic. This threshold is set by the system based on historical weak network scenarios. The second threshold is the upper limit for anomaly level determination. When the anomaly level index of the current defect is higher than this value, the system determines that the defect is a serious anomaly and triggers the critical event packet generation logic. This threshold is set by the system based on the anomaly handling priority strategy. Local deduplication refers to the robot checking whether an event packet with the same main event identifier and stage identifier with completely identical content already exists in the local cache queue before generating a new event packet. If it exists, the current packet to be generated is discarded without sending, thereby avoiding duplicate data consuming bandwidth and duplicate data entry on the platform. The first and second thresholds are stored as preset constants in the robot's configuration file and are adjusted by maintenance personnel according to the actual network environment and anomaly handling strategy.

[0046] Understandably, by switching event packet types according to a preset condition matrix, when the network status is below the first threshold and the evidence is incomplete, a summary event packet is generated to retain the minimum necessary information and supplement it later. When the anomaly level is above the second threshold and the evidence is incomplete, a critical event packet is generated to prioritize the reporting of key anomaly information. When the network is normal and the evidence is complete, a full event packet is generated to support direct recovery by the platform. When the same event enters a new stage or new evidence is added, an incremental event packet is generated to avoid resending confirmed data. When the same event and stage already exist and the content is consistent, no new packet is generated and deduplication is performed locally. This achieves the goal of making the event packet switching conditions deterministic and predictable, enabling the robot to clearly select the corresponding event packet type under different network conditions and event evolution stages, avoiding bandwidth waste or omission of key information due to arbitrary upload strategies. At the same time, the local deduplication mechanism eliminates duplicate data at the source, reducing the processing pressure and storage redundancy of the platform.

[0047] Specifically, before generating each event packet, the event packet hierarchical generation module on the robot side checks the following preset conditions in sequence: First, it checks whether the current network status is below the first threshold. If it is below the first threshold and the current event has not yet formed a complete evidence set, a summary event packet is generated. This summary event packet only contains the event master identifier, anomaly level, timestamp, and upload sequence number. A lightweight result is sent first, and the master event identifier and time information are retained. The remaining content will be uploaded after the network recovers. If the network status is not below the first threshold but the anomaly level is higher than the second threshold and the current evidence is not yet complete, a key event packet is generated. This key event packet adds a source identifier, result score, and key evidence index to the fields of the summary event packet. The anomaly is sent first. The system includes a level, key evidence index, and action summary to ensure that serious anomalies are detected by the platform first. If the network is normal and the evidence index meets the completeness requirements, a full event packet is generated, sending the complete defective event object and the complete evidence index set so that the platform can directly recover the complete main event data. If the same event main identifier enters a new stage identifier, or if new evidence indexes, result scores, or event states are added, an incremental event packet is generated, only transmitting the newly added stage content and not retransmitting the confirmed full main event data. If the same event main identifier and stage identifier already exist in the local cache and the content to be uploaded matches the cached content after hash comparison, no new event packet is generated, and local deduplication is performed directly on the robot to avoid redundant bandwidth consumption.

[0048] Preferably, the step of performing retransmission, deduplication, and order maintenance according to the upload sequence number and event priority includes: A retransmission state machine is established around a single defect event object. The retransmission state machine includes an initial state, a state to be sent, a state that has been sent but not acknowledged, a state to be retransmitted, a state in the process of retransmission, a state that has been acknowledged, and a state that has been closed. After the main event is generated for the first time, it enters the pending state; after the event packet is sent, it enters the sent but unacknowledged state. If no confirmation information for the event master identifier and the upload sequence number is received from the platform within the preset time, the process will switch to the pending transmission state and the corresponding event packet will be retained in the pending transmission index table. The event packets to be retransmitted are sorted by their exception level, generation time, and upload sequence number and then enter the retry queue. When the network recovers or the retry conditions are met, they are transferred to the retransmission state. After successful retransmission and receipt of a confirmation message from the platform, the system transitions to the confirmed state. The confirmation message carries the event master identifier, the upload sequence number, the confirmation timestamp, and the confirmation result. The robot updates the confirmation status based on the confirmation message. The event transitions to the closed state after it is closed or archived.

[0049] It should be noted that the retransmission state machine refers to a state machine model with defined states and transition conditions between states built around a single defect event object. It is used to regulate the software state transitions throughout the entire lifecycle of an event packet, from generation to confirmation or closure. The initial state is the starting state of the state machine, indicating that the defect event object has just been created but has not yet entered the sending process. The pending-to-send state indicates that the event packet has been generated and is ready for network transmission. The sent-but-not-confirmed state indicates that the event packet has been sent to the platform but no feedback has been received. The pending-retransmission state indicates that the event packet has not received confirmation from the platform within a preset time and needs to enter the retry queue to wait for subsequent retransmission. The retransmission in progress state indicates that the event packet is currently undergoing network retry transmission. The confirmed state indicates that the platform has successfully received and verified the event packet. The closed state indicates that the defect event has been closed or archived, and no further sending or retransmission operations will be performed. The preset time refers to the time the robot is waiting for confirmation from the platform. The timeout window for a message is set by the system based on network latency characteristics. The pending transmission index table is a local data structure used to record event packets in the pending transmission state, containing fields such as event master identifier, upload sequence number, event packet type, generation time, exception level, and number of retries. The retry queue is a sequence of pending transmission event packets organized according to a composite sorting rule: exception level from high to low, generation time from early to late, and upload sequence number from small to large. The acknowledgment message is a reception confirmation message returned by the platform to the robot after successful reception and field verification, containing the event master identifier, upload sequence number, acknowledgment timestamp, and acknowledgment result fields. The acknowledgment timestamp is a field on the platform recording the time the acknowledgment operation occurred. The acknowledgment result is an indication from the platform of the event packet field verification result, such as success or failure. The acknowledgment status is a status marker maintained locally by the robot indicating whether the current event packet has been acknowledged by the platform.

[0050] Understandably, by establishing a retransmission state machine around a single defect event object, including initial state, pending state, sent but unacknowledged state, pending retransmission state, retransmission in progress state, acknowledged state, and closed state, the main event enters the pending state after its first generation, transitions to the sent but unacknowledged state after transmission, transitions to the pending retransmission state and is retained in the index table after acknowledgment timeout, and enters the retry queue according to the exception level, generation time, and upload sequence number. When the network recovers, it transitions to the retransmission in progress state, transitions to the acknowledged state after successful retransmission and receipt of the acknowledgment message, and transitions to the closed state after the event is closed. This achieves the goal of elevating event-level retransmission from general file retransmission to a software state transition process around a single defect event, giving the retransmission behavior clear state boundaries and transition conditions, avoiding resource waste caused by indiscriminate repeated retries of the same event packet in a weak network environment, and ensuring that high-level exceptions are prioritized for retransmission through the sorting mechanism of the retry queue. The closed-loop management of acknowledgment messages and acknowledgment status ensures that the platform and the robot end reach a consensus on the event packet reception status.

[0051] Specifically, such as Figure 6As shown, the robot establishes a retransmission state machine around a single defect event object. This state machine contains seven states and explicit transition paths. In the initial state, the defect event object has not yet generated an event packet. When the main event is generated for the first time, the state machine transitions from the initial state to the pending-to-send state, at which point the event packet is ready and waiting to be sent via the network. After the robot executes the sending action, the state machine transitions from the pending-to-send state to the sent-but-not-acknowledged state, and simultaneously starts a preset acknowledgment timeout timer. If an acknowledgment message for the main identifier and upload sequence number of the event is received from the platform within the preset time, and the acknowledgment result is successful, the state machine directly transitions from the sent-but-not-acknowledged state to the acknowledged state. If no acknowledgment information is received within the preset time, the state machine transitions from the sent-but-not-acknowledged state to the pending-retransmission state, and the robot writes the corresponding event packet into the pending-retransmission state. The system transmits an index table, recording the event master identifier, upload sequence number, event packet type, generation time, anomaly level, and number of retries. Event packets awaiting retransmission are sorted according to a composite sorting rule: anomaly level from high to low, generation time from early to late, and upload sequence number from small to large. When the network recovers or the retry conditions are met, the robot retrieves the event packet from the retry queue and sends it, transitioning its state machine from the awaiting retransmission state to the retransmission in progress state. After successful retransmission, the robot receives an acknowledgment message from the platform, transitioning its state machine from the retransmission in progress state to the acknowledged state. The robot updates its local acknowledgement status based on the event master identifier, upload sequence number, acknowledgement timestamp, and acknowledgement result carried in the acknowledgement message. When the defect event is closed or archived by maintenance personnel, the state machine transitions from the acknowledged or awaiting retransmission state to the closed state, terminating subsequent retransmission operations.

[0052] Preferably, the process state sequence for organizing the same defect event includes: After receiving the main event and incremental events, the platform performs unified recovery processing on the event package according to the state recovery key set, which includes the main event identifier, the parent event identifier, the stage identifier, the upload sequence number, and the version information. Under the constraints of the state recovery key set, event-level deduplication, sequential recovery, and stage recovery are performed on the event package. The main event and each incremental event are repaired and organized into a unified process state sequence. The process state sequence corresponds to the stage chain of the same defect event from initial discovery, reshoot, correction, review to archiving closure. The repaired process status sequence is provided for use in full process playback, alarm invocation, report generation, and manual review functions.

[0053] It should be noted that the state recovery key set refers to the basic field combination used by the platform to perform unified recovery processing on event packages. This includes the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information. These fields together constitute the constraints for the platform to identify the uniqueness of events, establish event associations, restore timing, and label environment versions. Repair and organize refers to the process by which the platform, under the constraints of the state recovery key set, performs field validation, event-level deduplication, sequential recovery, and stage recovery on master events and incremental events, eliminating duplicate data and timing errors, and integrating scattered stage records into a coherent sequence. Stage chain The "item" refers to the sequence of stage nodes arranged according to the lifecycle of a defect event, corresponding to the evolution path from initial discovery, re-photographing, correction, review to archiving and closure; "full process playback" refers to the platform's function of reconstructing the entire defect handling process along a timeline based on the process state sequence; "alarm invocation" refers to the alarm system's function of obtaining the defect level change trend based on the process state sequence to generate continuous alarms; "report generation" refers to the report system's function of generating inspection reports containing evidence from multiple stages based on the process state sequence; and "manual review function" refers to the manual review system's function of displaying the original evidence of each stage for operation and maintenance personnel to review based on the process state sequence.

[0054] Understandably, after receiving the main event and incremental events, the platform performs unified recovery processing on the event package based on the status recovery key set consisting of the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information. Under the constraints of the key set, it performs event-level deduplication, sequential recovery, and stage recovery, repairing and organizing the main event and each incremental event into a process state sequence of the same defect event from initial discovery, re-photographing, correction, review to archiving and closure. This sequence is then provided to the functions of full-process playback, alarm invocation, report generation, and manual review. This achieves the goal of reliably reconstructing the complete lifecycle of the same defect event from scattered and potentially out-of-order uploaded data, enabling downstream functional modules to continuously obtain the entire process data from defect discovery to defect elimination from a unified perspective, avoiding the inability to perceive the whole picture of the event due to accessing only scattered and isolated records.

[0055] Specifically, such as Figure 7 As shown, after receiving the main event and incremental events sent by the robot, the platform first extracts the main event identifier, parent event identifier, stage identifier, upload sequence number, and version information based on the state recovery key set. In the unified recovery processing stage, the platform uses the main event identifier as the aggregation key to gather all received records of the same defect event together. It then uses the combination of the main event identifier, stage identifier, upload sequence number, and version information as a unique constraint to perform event-level deduplication, eliminating duplicate received event packets. It then performs sequential recovery by sorting the upload sequence numbers from smallest to largest and performs stage recovery based on the stage identifier. For example... Figure 7The diagram shows that the main event corresponds to the initial defect discovery stage, denoted by E1001 as the main event identifier, S1 as the initial discovery stage, and V1 as the version environment corresponding to this stage. As processing actions such as robot re-environment tracking, platform correction, manual review, and archive closure occur, the same defect event continues to derive incremental events 1 to 4, each associated with the main event by its parent_event_id, corresponding to the stage identifiers S2 (re-environment tracking), S3 (platform correction), S4 (manual review), and S5 (archive closure), and the corresponding version environment V1 or V2. The platform side displays the status recovery button. Under set constraints, the main event E1001 and each incremental event are repaired and organized into a unified process state sequence, forming a stage chain from initial discovery, re-shooting, correction, review to archiving and closure. Subsequently, the platform provides the organized process state sequence to downstream functions for invocation. The full-process playback function restores the entire defect handling process according to the timeline of the sequence. The alarm system calls the sequence to obtain the level changes of the defect at each stage. The reporting system calls the sequence to generate an inspection report containing evidence indexes of each stage. The manual review system calls the sequence to display the complete evidence chain from initial discovery to review conclusion.

[0056] A graded compensation system for defect events in power distribution robots, such as Figure 2 As shown, it includes: The task access module is used to receive multi-source raw results and evidence indexes related to the same abnormal target generated by multiple software modules. The object encapsulation module is used to encapsulate the multi-source original results and evidence index into a defect event object. The defect event object includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number. The hierarchical generation module is used to generate summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status. The cache retransmission module is used to send the event packet to the platform when the network status is normal; when the network is unstable, the platform does not confirm, or the transmission fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. The platform recovery module is used to perform event-level deduplication, sequential recovery, and stage recovery on the event package based on the event master identifier, parent event identifier, stage identifier, and upload sequence number, so as to obtain the recovery results of the same defect event at different stages. The status call module is used to organize a process status sequence for the same defect event based on the recovery result, combined with the source identifier and the evidence index, and provide the process status sequence to downstream function calls.

[0057] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0058] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for hierarchical retransmission of defect events in power distribution robots, characterized in that, include: Receive multi-source raw results and evidence indexes associated with the same anomalous target generated by multiple software modules; The multi-source original results and evidence index are uniformly encapsulated into a defect event object, which includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number. Based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status, a summary event package, a key event package, a full event package, or an incremental event package is generated for the defect event object. When the network is in normal condition, the event packet is sent to the platform. When the network is unstable, the platform does not confirm, or the transmission fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. Based on the event master identifier, parent event identifier, stage identifier and upload sequence number, the event package is deduplicated at the event level, restored in sequence and restored at the stage to obtain the restoration results of the same defect event at different stages. Based on the recovery results, combined with the source identifier and the evidence index, a process state sequence for the same defect event is organized, and the process state sequence is provided to downstream function calls.

2. The method for graded retransmission of defect events in power distribution robots according to claim 1, characterized in that, The defect event object also includes version information; The platform performs event-level deduplication, sequential recovery, stage recovery, and version environment association on the event package based on the event master identifier, parent event identifier, stage identifier, upload sequence number, and version information, so as to obtain the recovery results of the same defect event in different stages and different version environments.

3. The method for graded retransmission of defect events in power distribution robots according to claim 1, characterized in that, The process of uniformly encapsulating the multi-source original results and evidence index into a defect event object includes: Extract basic fields from visible light anomaly results, infrared anomaly results, alarm results, action logs, manual review results, and task context; Map the unique anomaly number in the basic fields to the event master identifier, map the associated original master event number to the parent event identifier, map the stage information to the stage identifier, map the upstream source type to the source identifier, map the evidence file path or storage key to the evidence index, and map the sending sequence number to the upload sequence number. Perform unified format normalization processing on heterogeneous data formats from different upstream modules, convert time fields into a unified timestamp format, map anomaly levels to a preset level set, map source types to a preset source code, convert file paths or storage keys into a standardized representation, and fill or set null values, default values, and anomaly values ​​according to preset rules. For raw results that only include partial information, fill in the missing fields based on the task context and event relationships; After completing field extraction, field mapping, format normalization, and association completion, the results are uniformly encapsulated into the defect event object.

4. The method for graded retransmission of defect events in distribution network robots according to claim 1, characterized in that, The process of generating summary event packages, critical event packages, full event packages, or incremental event packages for the defect event object based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status includes: When the network status is below a preset threshold and the current event has not yet formed a complete evidence set, a summary event package is generated. The summary event package includes the event main identifier, the anomaly level, the timestamp, and the upload sequence number, which is used to enable the platform to complete event logging and lightweight perception. When the anomaly level is higher than a preset threshold and the current evidence is not yet complete, a key event package is generated. The key event package includes the fields of the summary event package, the source identifier, the result score, and the key evidence index, which is used to enable the platform to prioritize the detection of key anomalies. When the network status is normal and the evidence index meets the completeness requirements, a full event package is generated. The full event package includes all fields of the defective event object and a complete evidence index set, which is used by the platform to directly restore the complete main event data. When the same event master identifier enters a new stage identifier, or when the evidence index, result score, or event status is added, an incremental event package is generated. The incremental event package includes the event master identifier, the parent event identifier, the new stage identifier, and the new evidence index, and does not repeatedly send the full data of the confirmed master event.

5. The method for graded retransmission of defect events in power distribution robots according to claim 4, characterized in that, The generation of summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects is performed according to the following preset conditions: When the network status is below the first threshold and the current event has not yet formed a complete evidence set, the summary event packet is generated, a lightweight result is sent first and the main event identifier and time information are retained, and the data is uploaded after the network is restored. When the anomaly level is higher than the second threshold and the current evidence is not yet complete, the key event package is generated, and the anomaly level, key evidence index and action summary are sent first. When the network status is normal and the evidence index meets the completeness requirements, the full event packet is generated and the complete defect event object and complete evidence index are sent. When the same event master identifier enters a new stage identifier, or when a new evidence index, result score, or event status is added, the incremental event package is generated. Only the newly added stage content is transmitted, and the full data of the confirmed master event is not sent repeatedly. When the same event master identifier and stage identifier already exist, and the currently uploaded content is consistent with the cached content, no new event package is generated, and local deduplication is performed directly on the robot side.

6. The method for graded retransmission of defect events in distribution network robots according to claim 1, characterized in that, The process of performing retransmission, deduplication, and order maintenance according to the upload sequence number and event priority includes: A retransmission state machine is established around a single defect event object. The retransmission state machine includes an initial state, a state to be sent, a state that has been sent but not acknowledged, a state to be retransmitted, a state in the process of retransmission, a state that has been acknowledged, and a state that has been closed. After the main event is generated for the first time, it enters the pending state; after the event packet is sent, it enters the sent but unacknowledged state. If no confirmation information for the event master identifier and the upload sequence number is received from the platform within the preset time, the process will switch to the pending transmission state and the corresponding event packet will be retained in the pending transmission index table. The event packets to be retransmitted are sorted by their exception level, generation time, and upload sequence number and then enter the retry queue. When the network recovers or the retry conditions are met, they are transferred to the retransmission state. After successful retransmission and receipt of a confirmation message from the platform, the system transitions to the confirmed state. The confirmation message carries the event master identifier, the upload sequence number, the confirmation timestamp, and the confirmation result. The robot updates the confirmation status based on the confirmation message. The event transitions to the closed state after it is closed or archived.

7. The method for graded retransmission of defect events in power distribution robots according to claim 1, characterized in that, The process state sequence of organizing the same defect event includes: After receiving the main event and incremental events, the platform performs unified recovery processing on the event package according to the state recovery key set, which includes the main event identifier, the parent event identifier, the stage identifier, the upload sequence number, and the version information. Under the constraints of the state recovery key set, event-level deduplication, sequential recovery, and stage recovery are performed on the event package. The main event and each incremental event are repaired and organized into a unified process state sequence. The process state sequence corresponds to the stage chain of the same defect event from initial discovery, reshoot, correction, review to archiving closure. The repaired process status sequence is provided for use in full process playback, alarm invocation, report generation, and manual review functions.

8. A graded compensation system for defect events in a power distribution network robot, characterized in that, include: The task access module is used to receive multi-source raw results and evidence indexes related to the same abnormal target generated by multiple software modules. The object encapsulation module is used to encapsulate the multi-source original results and evidence index into a defect event object. The defect event object includes an event master identifier, a parent event identifier, a stage identifier, a source identifier, an evidence index, and an upload sequence number. The hierarchical generation module is used to generate summary event packages, key event packages, full event packages, or incremental event packages for the defect event objects based on the anomaly level, the completeness of evidence, the current network status, and the platform confirmation status. The cache retransmission module is used to send the event packet to the platform when the network status is normal; when the network is unstable, the platform does not confirm, or the transmission fails, the event packet is written to the local cache queue, and retransmission, deduplication, and order maintenance are performed according to the upload sequence number and event priority. The platform recovery module is used to perform event-level deduplication, sequential recovery, and stage recovery on the event package based on the event master identifier, parent event identifier, stage identifier, and upload sequence number, so as to obtain the recovery results of the same defect event at different stages. The status call module is used to organize a process status sequence for the same defect event based on the recovery result, combined with the source identifier and the evidence index, and provide the process status sequence to downstream function calls.

Images