Remote intelligent fault diagnosis and analysis method for electric energy acquisition terminal

Abstract

The invention provides an intelligent remote fault diagnosis and analysis method for an electric energy acquisition terminal, and the method comprises the steps: obtaining a current firmware version number and a self-inspection execution mode from the electric energy acquisition terminal, collecting fault code generation timestamps and an abnormal report sequence of all modules, and obtaining terminal version information and a fault time sequence record; aiming at a corresponding basis of a fault source and code expression, obtaining real-time self-inspection data of a current terminal, extracting a fault triggering time sequence of each functional module in a parallel detection mode, and identifying a fault diffusion sequence that a single hardware fault affects adjacent modules; and a diagnosis report is generated from a positioning result of a single hardware fault source, and fault representation forms of serial and parallel detection modes in a fault identification basis library are updated through a diagnosis record, so that fault diagnosis adaptation under different firmware versions is realized.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a remote intelligent fault diagnosis and analysis method for power acquisition terminals. Background Technology

[0002] In the field of power system operation and maintenance, remote fault diagnosis of power acquisition terminals is particularly crucial, as it directly relates to the accuracy of power data and the stable operation of the system. This technology is not only an important link in ensuring power supply, but also a core support for improving user service quality and reducing operating costs. With the popularization of smart grids, the demand for fault diagnosis of terminal equipment is increasing, placing higher demands on the accuracy and adaptability of diagnostic technologies. However, many current fault diagnosis methods often struggle to adapt to changes in equipment operating mechanisms in complex environments, especially during equipment upgrades, where diagnostic logic is prone to deviations. These methods typically cannot dynamically respond to changes in equipment operating modes, limiting the accuracy of fault identification. Especially when equipment functions are upgraded or operating logic is adjusted, traditional diagnostic approaches often fail to keep pace with the changes, revealing significant shortcomings. Among these, changes in equipment self-testing methods directly affect the manifestation of faults. Early terminal equipment, due to the use of single-core processors and limited computing power, could only use a serial detection method, that is, checking each module sequentially, stopping and reporting a fault as soon as a problem was found. With advancements in processor technology, newer devices are generally equipped with multi-core processors. To improve detection efficiency and shorten self-test time, parallel detection methods have been adopted, allowing all modules to be checked simultaneously. While this upgrade from serial to parallel technology has increased detection speed, it has also brought new challenges. The same hardware problem can now trigger alarms from multiple modules simultaneously, making previously simple and clear fault signals complex and ambiguous. Specifically, in actual business operations, the common problem of power module failure fully demonstrates this contradiction. In older devices, power problems only manifested as a single power anomaly warning, which maintenance personnel could immediately identify as a power supply failure. However, in the new version, because all modules are tested simultaneously, a power problem will immediately affect multiple modules that rely on power supplies, such as communication, metering, and storage. The system may receive five, six, or even more anomaly reports simultaneously, appearing as if multiple faults have occurred. This inconsistency between the appearance and the actual root cause of the fault makes it difficult for maintenance personnel to quickly determine whether there are truly multiple problems or a chain reaction triggered by a single problem, significantly prolonging fault handling time. Therefore, in the context of upgrading device self-test methods from serial to parallel, accurately distinguishing the correspondence between fault manifestations and the true root cause has become a key issue in improving the efficiency of remote fault diagnosis. Summary of the Invention

[0003] This invention provides a remote intelligent fault diagnosis and analysis method for power acquisition terminals, mainly including: The version information and fault timing records are obtained from the power acquisition terminal to determine the self-test execution method. Based on the version information and the fault timing record, analyze the triggering pattern of the fault code to identify the candidate range of a single hardware fault source; Based on the self-test execution method and the candidate range, the consistency of fault performance is evaluated, and a fault identification basis library with version adaptation is constructed. Fault performance characteristics are extracted from the fault identification database, and the correspondence between a single hardware fault source and fault code performance is analyzed to obtain the basis for the correspondence between fault sources and code performance. The real-time self-test data of the power acquisition terminal is obtained, and the fault propagation sequence is identified based on the correspondence between the fault source and the code manifestation. Based on the fault propagation sequence and the fault timing record, verify the timing consistency and determine the location result of a single hardware fault source; A diagnostic report is generated based on the location results, and the fault identification database is updated to adapt to different versions.

[0004] Furthermore, the step of obtaining version information and fault timing records from the power acquisition terminal to determine the self-test execution mode includes: A version query command is sent to the power acquisition terminal via a remote communication protocol to obtain the firmware version number and parse the major version number and sub-version number in the firmware version number. If the main version number is less than a preset threshold, it is determined to be a serial detection method; otherwise, it is determined to be a parallel detection method. According to the serial detection method or the parallel detection method, the power acquisition terminal is connected through a security protocol to read the log file and extract the fault codes and timestamps of each functional module; The fault code sequence is formed by arranging the timestamps in ascending order, and the firmware version number, the self-test execution mode, and the fault code are combined into the version information and the fault timing record.

[0005] Furthermore, the step of analyzing the triggering pattern of fault codes based on the version information and the fault timing record to identify the candidate range of a single hardware fault source includes: Extract the timestamps of each fault code from the fault timing record and calculate the time interval between adjacent timestamps; If the time interval is less than a preset threshold, the corresponding fault codes are grouped into the same time window, and the number and distribution characteristics of fault codes within the time window are statistically analyzed. If the number of fault codes exceeds a preset threshold within the time window, the relevant functional module identifiers are extracted, the power supply relationship and signal dependency relationship between modules are queried, and the fault propagation link is identified. Based on the frequency of fault codes in the fault propagation link, a probability value is calculated. If the probability value exceeds a preset threshold, the link source node is determined as a candidate for the single hardware fault source.

[0006] Furthermore, the step of evaluating the consistency of fault performance and constructing a version-adaptive fault identification basis library based on the self-test execution method and the candidate range includes: Extract the abnormal report sequences of each fault source under different self-test execution modes from the candidate range, and compare the fault code performance of serial detection and parallel detection; A consistency score is obtained by calculating the ratio of the number of fault codes and the degree of difference in timing distribution; If the consistency score is lower than a preset threshold, a fault code mapping table is established to record the corresponding relationship under different detection methods; Based on the mapping table and the version information, configure the corresponding rule set, associate the rule set with the version range, and store it as a fault identification basis library for version adaptation.

[0007] Furthermore, the step of extracting fault manifestation features from the fault identification database, analyzing the correspondence between single hardware fault sources and fault code manifestations, and obtaining the basis for the correspondence between fault sources and code manifestations includes: Fault records in parallel detection mode are read from the fault identification database, and fault code combinations and related features are extracted. Clustering algorithms are used to group fault records to obtain a set of common performance features of each fault source; Based on the feature set, the frequency of fault code combinations is statistically analyzed, a mapping matrix is ​​constructed, and typical code performance patterns are extracted. Based on the typical code behavior pattern, the fault propagation path is traced. If the fault codes on the path appear simultaneously within a preset time window, it is determined to be a chain reaction. The characteristics of the chain reaction are recorded, and a correspondence between the fault source and the code behavior is established.

[0008] Furthermore, the step of acquiring the real-time self-test data of the power acquisition terminal and identifying the fault propagation sequence based on the correspondence between the fault source and the code manifestation includes: The real-time self-test data stream of the power acquisition terminal is obtained through the remote communication interface, and the fault codes and timestamps are parsed to form a fault triggering time sequence. Based on the module identifiers in the time sequence, query the hardware connection relationship table and extract the physical dependency relationship network between modules; Starting from the earliest faulty module in the time sequence, the fault propagation is traced along the connection path, and the time difference is calculated; If the time difference is less than a preset threshold, it is determined that there is a diffusion relationship, a fault diffusion tree structure is constructed, and the fault diffusion order is obtained.

[0009] Furthermore, the step of determining the location result of a single hardware fault source by verifying the timing consistency based on the fault propagation sequence and the fault timing record includes: Extract the module-level position from the fault propagation sequence and calculate the theoretical trigger time; Read the actual timestamp from the fault timing record, and subtract the theoretical trigger time from the actual timestamp to obtain the time deviation value; The consistency ratio is calculated based on the time deviation value. If the consistency ratio exceeds a preset threshold, the propagation relationship is confirmed. The diffusion paths that have passed the screening and verification are selected, and the path with the highest consistency ratio is identified as the root node module of the path as the source of the fault. The location result is then output by combining the module location and the fault code.

[0010] Furthermore, the step of generating a diagnostic report based on the location results and updating the fault identification database to adapt to different versions includes: Extract the fault source module name, location coordinates, and fault code set from the location results, and write them into a text file in the order of the fields to form a structured diagnostic report; Based on the version information, the detection mode is determined, and the set of fault codes is appended to the corresponding partition of the fault identification basis library; If it is in serial detection mode, a single fault code is stored; In parallel detection mode, multiple fault code combinations are stored to complete the fault diagnosis adaptation for different versions.

[0011] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a remote intelligent fault diagnosis and analysis method for power acquisition terminals. Addressing the challenges of traditional diagnostic methods in distinguishing cascading multiple fault codes caused by a single hardware fault in parallel self-test mode, and the inconsistency in fault manifestations across different firmware versions, this method integrates terminal version information with fault timing records. It identifies the timestamp distribution of abnormal reports and the self-test execution method, determines the fault triggering mode, and evaluates whether multiple codes represent a single fault cascade during parallel detection, thereby defining the candidate range of fault sources. Furthermore, this invention extracts the correspondence between the abnormal report order and the self-test method, dynamically adjusts the fault identification criteria, and constructs a version-adaptive fault identification criterion library. From this library, it analyzes the common manifestations of multiple abnormalities and the fault propagation order, verifies timing consistency using real-time self-test data, and ultimately locates a single hardware fault source and generates a diagnostic report. Simultaneously, it updates the criterion library to adapt to both serial and parallel modes. This method significantly improves the accuracy and adaptability of fault diagnosis, reduces misjudgments, and optimizes terminal maintenance efficiency. Attached Figure Description

[0012] Figure 1 This is a flowchart of a remote intelligent fault diagnosis and analysis method for an energy acquisition terminal according to the present invention.

[0013] Figure 2 This is a schematic diagram of a remote intelligent fault diagnosis and analysis method for an energy acquisition terminal according to the present invention.

[0014] Figure 3 This is another schematic diagram of a remote intelligent fault diagnosis and analysis method for an energy acquisition terminal according to the present invention. Detailed Implementation

[0015] To further understand the content of this invention, a detailed description of the invention is provided in conjunction with the accompanying drawings and embodiments. The specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0016] like Figure 1-3 This embodiment of a remote fault intelligent diagnosis and analysis method for an energy acquisition terminal may specifically include: S101. Obtain the current firmware version number and self-test execution mode from the power acquisition terminal, collect the fault code generation timestamps and abnormal report order of each module, and obtain terminal version information and fault timing records.

[0017] A version query command is sent to the power acquisition terminal via a remote communication protocol to obtain the firmware version number returned by the terminal. The major version number and minor version number in the version number are parsed. If the major version number is less than a preset threshold, it is determined to be a serial detection mode; otherwise, it is determined to be a parallel detection mode. According to the serial or parallel detection mode, the terminal is connected via SSH protocol to read the log file, extract the fault codes and Unix timestamps of each functional module, arrange them in ascending order of timestamps to form a fault code sequence, and combine the firmware version number, detection mode, and fault code sequence to form terminal version information and fault timing record.

[0018] Specifically, in one implementation, the version information of the power acquisition terminal is obtained by establishing a TCP / IP connection. After receiving a version query command, the terminal returns a string in the format "V major version number.minor version number", where the major version number reflects the generational update of the terminal's hardware architecture. According to the design specifications, when the major version number is less than 3, it indicates that the terminal uses a single-core processor architecture and only supports serial self-test mode; when the major version number is greater than or equal to 3, it indicates that the terminal has been upgraded to a multi-core processor and supports parallel self-test mode. The correspondence between version number and architecture follows the terminal hardware design standards. The SSH protocol connection establishes a secure channel using key authentication. The terminal log file is stored in JSON format in the / var / log / terminal / directory, and each fault record contains three fields: module identifier, fault code, and Unix timestamp. The power module fault record is {"module":"power","code":"E001","timestamp":1736323200}, indicating a fault in power module E001 with a timestamp of 1736323200. The communication module fault record is {"module":"comm","code":"E002","timestamp":1736323201}, indicating a fault in communication module E002 with a timestamp of 1736323201. By parsing these records and sorting them by timestamp, a complete fault sequence chain is formed.

[0019] Preferably, the terminal version information and fault timing records are stored in a structured data format, including a version number field, a detection method field, and a fault sequence array, providing standardized input data for subsequent fault source location analysis.

[0020] S102. Based on the terminal version information and fault timing records, identify the timestamp distribution of the abnormal reports, determine the triggering mode of the fault codes, and when identified as parallel detection, evaluate whether the multiple fault codes triggered at the same time are a chain reaction of a single hardware fault, and determine the candidate range of single hardware fault sources.

[0021] The Unix timestamps of each fault code are extracted from the terminal version information and fault timing records. Adjacent timestamps are subtracted to obtain the time interval. If the time interval is less than a preset millisecond threshold, the corresponding fault codes are grouped into the same time window. The number and distribution characteristics of fault codes within each time window are statistically analyzed. Based on the number of fault codes within the time window, when the number of fault codes in a single window exceeds a preset threshold, the functional module identifiers corresponding to all fault codes within that window are extracted. The power supply relationship and signal transmission dependency between the power module and the communication module, metering module, and storage module are queried. Module combinations with direct dependencies are identified to obtain the fault propagation link between modules. For the fault propagation link, the frequency of fault codes occurring at each node module on the link is statistically analyzed. The probability value of a simultaneous failure of downstream node modules when the source node module fails is calculated. When the probability value exceeds a preset threshold and the propagation link length is greater than a preset value, the hardware module corresponding to the source node of the link is identified as a candidate range for a single hardware fault source.

[0022] Specifically, the time window is divided based on the characteristics of fault code generation under the parallel detection mechanism. Because multi-core processors simultaneously launch their module self-test programs, related faults will erupt in a very short time, within a timeframe of less than 5 milliseconds. This quantitative standard is derived from actual test data of multi-core processor self-test programs.

[0023] Specifically, the difference between adjacent timestamps is calculated by subtracting the previous timestamp from the subsequent timestamp. When the difference is less than 100 milliseconds, these fault codes are considered to belong to the same batch of parallel detection results. The module dependencies within the power acquisition terminal present a tree-like topology, with the power module at the root node, connecting downwards to the communication module, metering module, and storage module. The communication module relies on the 12V DC voltage provided by the power module, the metering module relies on the 5V regulated output of the power module, and the storage module relies on both the power supply and the data bus signal of the communication module. When the power module fails, its power supply anomaly propagates downwards along the dependency relationship, causing the communication module to report "E101 Communication Interruption," the metering module to report "E201 Metering Anomaly," and the storage module to report "E301 Storage Failure." This propagation characteristic manifests as multiple modules reporting faults almost simultaneously in parallel detection mode, while in serial detection mode, only the first detected power fault, "E001 Power Anomaly," is reported. By recording the dependency type and strength of each module on other modules, possible fault propagation paths can be identified.

[0024] Preferably, the fault propagation link is constructed using a directed graph structure, where nodes represent functional modules and directed edges represent the propagation direction of dependencies.

[0025] For example, the edge weight from the power module to the communication module is 0.95, which means that there is a 95% probability that a power failure will cause a communication failure.

[0026] In one possible implementation, the probability value is calculated based on statistical analysis of historical fault data. The propagation probability is quantified by calculating the conditional probability P(downstream module failure | source node failure). This involves first extracting fault data from the past year from equipment operation logs and fault record databases; second, counting the co-occurrence frequency of source node failures and downstream module failures; and finally, calculating the conditional probability as the ratio of co-occurrence frequency to the total number of source node failures. When the probability value exceeds 0.8 and the propagation path contains three or more nodes, the source node is marked as a high-priority candidate fault source. Furthermore, the candidate range for a single hardware fault source is prioritized according to the length of the propagation path and the probability value. Source nodes with longer paths and higher probability values ​​have a higher probability of being fault sources, thus providing maintenance personnel with accurate fault location guidance.

[0027] S103. After obtaining the candidate range of a single hardware fault source, extract the correspondence between the abnormal report order and the self-test execution method, evaluate the consistency between the detection method and the fault manifestation, dynamically adjust the fault identification basis, and obtain a version-adapted fault identification basis library.

[0028] From the candidate range of single hardware fault sources, abnormal report sequences of each candidate fault source under different self-test execution modes are extracted. A single fault code during serial detection and a combination of multiple fault codes during parallel detection are compared. A fault performance consistency score is obtained by calculating the ratio of the number of fault codes and the difference in temporal distribution. Based on the fault performance consistency score, when the score is below a preset threshold, a fault code mapping table is established to record the correspondence between single fault codes in serial mode and combinations of multiple fault codes in parallel mode. The correspondence in the mapping table is converted into fault identification rules. Based on the fault identification rules and firmware version number, a rule set for identifying a single fault using a single code is configured when the version number corresponds to serial detection, and a rule set for identifying a single fault using multiple codes is configured when the version number corresponds to parallel detection. The correspondence between the two rule sets and the version number range is stored as a version-adaptive fault identification basis library.

[0029] Specifically, the consistency score for fault performance is quantitatively evaluated through two dimensions. The fault code number ratio is calculated by dividing the number of fault codes during parallel detection by the number of fault codes during serial detection. The temporal distribution difference is characterized by calculating the standard deviation of the timestamps of each fault code. The final score is obtained by weighted summation of the two indicators, with the weights being preset.

[0030] Preferably, the threshold for the fault performance consistency score is set to 0.3. When the score is lower than this value, it indicates a significant difference in fault performance between serial and parallel detection, requiring the establishment of a mapping relationship for conversion. The fault code mapping table uses a key-value pair structure to store the mapping relationship. In serial detection mode, a power failure only generates a single code "E001", while in parallel detection mode, the same power failure triggers five fault codes: "E001 Power Abnormality", "E101 Communication Interruption", "E201 Metering Failure", "E301 Storage Error", and "E401 Display Abnormality". The mapping table uses "E001" as the key and the combination of the five fault codes as the value. By traversing historical fault data, the co-occurrence frequency of each single fault code and multiple fault code combinations is statistically analyzed. When the co-occurrence frequency exceeds 80%, a mapping relationship is established. The fault identification rule is automatically converted based on the mapping table. When a multiple fault code combination in parallel mode is detected to match a value in the mapping table, the corresponding key value is searched in reverse to determine the true single fault source.

[0031] For example, the version-adaptive fault identification database adopts a hierarchical storage structure. The first layer is indexed by firmware version number ranges; for instance, versions 1.0-2.9 correspond to the serial detection rule set, and versions 3.0 and above correspond to the parallel detection rule set. The second layer stores the specific identification rules. In the serial rule set, each rule is a one-to-one mapping between "fault code and fault type," while in the parallel rule set, each rule is a many-to-one mapping between "fault code combination and fault type." Furthermore, in practical applications, when fault information reported by the terminal is received, the terminal version number is first queried to determine the applicable rule set, and then the fault code or fault code combination is matched against the corresponding rule set to output an accurate fault type determination result.

[0032] S104. Extract the common characteristics of multiple anomaly reports from the fault identification base library for version adaptation, identify the correspondence between a single hardware fault source and multiple code manifestations, analyze the manifestation of a single hardware fault source causing a chain of anomalies in dependent modules in parallel detection mode, evaluate whether it conforms to the single code manifestation mode of serial detection in the old version, and obtain the correspondence between fault sources and code manifestations.

[0033] Fault records in parallel detection mode are read from the fault identification database adapted to the version. From these records, fault code combinations triggered by each hardware fault source, time intervals between adjacent codes, and the number and type of affected modules are extracted. K-means clustering is used to group records with the same fault source according to time interval and number of modules. The input data consists of two fields: time interval and number of modules. The output is the grouping results based on these two dimensions, yielding a common set of characteristics for each fault source. For this common set of characteristics, the frequency of each fault source triggering various fault code combinations is statistically analyzed. A mapping matrix between fault sources and code behaviors is constructed, where matrix rows represent single hardware fault source types, matrix columns represent fault code combination patterns, and matrix element values ​​represent the frequency with which the fault source triggers that code combination. The code combination with the highest frequency is extracted as the typical code behavior pattern for that fault source. Based on the fault code sequence in the typical code behavior pattern, the propagation path of the fault between modules is traced. The temporal relationship between the source module fault triggering the dependent module anomaly is recorded. If the fault codes of all nodes on the propagation path appear simultaneously within a preset time window, it is determined to be a chain reaction behavior. The propagation path length and time window size are used as chain reaction features. By comparing the chain reaction characteristics with the single code behavior in the old version of the serial detection record, the matching degree is calculated by matching the fault source type and the scope of the module ultimately affected. When the matching degree exceeds the preset threshold, the equivalence relationship between multiple code combinations in parallel mode and single code in serial mode is established, forming the basis for the correspondence between fault sources and code behavior.

[0034] Specifically, the extraction of common performance feature sets is based on statistical analysis of a large amount of historical fault data.

[0035] Specifically, the system retrieves all terminal fault records from the past six months using parallel detection mode from a fault identification database adapted to the version. Each record includes a fault source identifier, a fault code sequence, a Unix timestamp for each code, and a list of involved functional modules. The application of the K-means clustering algorithm requires pre-determining the number of cluster centers. Preliminary analysis of historical data indicates that hardware fault sources in the power acquisition terminal are mainly categorized into four types: power supply faults, communication faults, metering faults, and storage faults. Therefore, a K value of 4 is set. The clustering feature vector contains two dimensions: the average time interval between adjacent fault codes and the number of affected modules.

[0036] For example, the construction of the mapping matrix involves in-depth mining of the clustered data. The rows of the matrix correspond to four types of hardware fault sources, and the columns correspond to different fault code combination patterns. Taking power supply faults as an example, in 1000 power supply fault records, 850 triggered a five-fold code combination of "E001+E101+E201+E301+E401", 120 triggered a three-fold code combination of "E001+E101+E201", and 30 triggered only the single code "E001". The element values ​​of each column corresponding to the power supply fault row in the matrix are 0.85, 0.12, and 0.03, respectively, reflecting the trigger probability of different code combinations. By comparing the element values ​​in each row, the code combination with the highest probability is extracted as the typical manifestation pattern of that fault source. For power supply failures, the typical code pattern is a five-code combination "E001+E101+E201+E301+E401", which accounts for 85% of the occurrences and is highly representative.

[0037] Preferably, the fault propagation path is traced using a directed graph traversal method. Starting from the source fault code in a typical code representation pattern, a propagation graph is constructed based on the dependencies between modules. Each node represents a functional module, and directed edges indicate the direction of fault propagation. The construction of the propagation graph may include first collecting the call relationships and data interaction information between modules; quantifying the dependencies by using call frequency or data interaction volume as edge weights; and finally converting the dependencies into directed edges, with edges having higher weights indicating a stronger probability of propagation.

[0038] In one possible implementation, chain reaction determination is based on strict timing constraints. A preset time window of 500 milliseconds is used; a chain reaction is identified when the timestamps of all fault codes along the propagation path fall within this window. The propagation path length is calculated by counting the number of edges from the source node to the farthest leaf node. A typical propagation path length for a power supply fault is 4, meaning the fault propagates from the power module to the display module four times. The size of the time window reflects the density of fault propagation; a smaller window indicates that modules report anomalies almost simultaneously, and the chain reaction characteristics are more pronounced. These characteristic parameters collectively constitute a fault behavior profile in parallel detection mode. Statistical analysis of the chain reaction characteristics of different fault sources reveals that the average propagation path length for power supply faults is 4.2, with an average time window of 450 milliseconds; the average propagation path length for communication faults is 2.8, with an average time window of 320 milliseconds; and the propagation paths for metering and storage faults are shorter, at 1.5 and 1.2 respectively, with relatively smaller time windows.

[0039] Specifically, the matching degree calculation comprehensively considers two factors: the consistency of fault source types and the similarity of module impact ranges. Fault source types are determined through keyword matching; for example, "E001" in parallel mode and "power abnormality" in serial mode both point to power failures. Module impact ranges are obtained by calculating the Jaccard similarity coefficient by comparing the sets of affected modules. Furthermore, the establishment of equivalence relations requires satisfying bidirectional verification conditions. Forward verification confirms that multiple code combinations in parallel mode can be mapped to a single code in serial mode, while reverse verification ensures that a single code in serial mode will necessarily generate corresponding multiple code combinations in a parallel environment. When the matching degree exceeds the threshold of 0.75 and both bidirectional verifications pass, an equivalence relation is established and stored in the corresponding basis.

[0040] For example, a power supply fault manifests as a single "E001 Power Abnormality" code in serial detection mode, while in parallel detection mode it manifests as a combination of five codes. Through matching calculations, the fault source types in both modes are completely identical, the Jaccard coefficient for the module's impact range is 0.88, and the overall matching degree is 0.94, far exceeding the threshold requirement. This correspondence between fault sources and code manifestations forms a cross-version fault diagnosis knowledge base.

[0041] S105. Based on the correspondence between the fault source and the code behavior, obtain the real-time self-test data of the current terminal, extract the fault triggering sequence of each functional module in parallel detection mode, and identify the fault propagation sequence of a single hardware fault affecting adjacent modules.

[0042] Based on the correspondence between the fault source and the code behavior, the real-time self-test data stream of the current terminal is obtained through the remote communication interface. The fault codes and their Unix timestamps of each functional module in the data packets are parsed and arranged in ascending order of timestamps to form a fault triggering time sequence. The triggering time and corresponding module identifier of each fault code are recorded. According to the module identifier in the fault triggering time sequence, the hardware connection relationship table of the power acquisition terminal is queried. This table records two types of relationships between modules: power supply connection and signal connection. The connection path between the fault module and other modules is extracted, and directly connected adjacent modules are identified to obtain the physical dependency relationship network between modules. For the physical dependency relationship network, starting from the module that triggered the fault earliest in the time sequence, the fault propagation is traced along the power supply or signal connection path. The triggering time of the subsequent module is subtracted from the triggering time of the previous module to obtain the time difference value. If the time difference value is less than a preset millisecond threshold, it is determined that there is a fault propagation relationship, and the order of each module on the propagation path is recorded. By analyzing the order of the modules along the diffusion path, a fault diffusion tree structure is constructed. The earliest faulty module is set as the root node, and the modules directly affected by it are set as child nodes. The relationships between nodes at each level are established sequentially. The hierarchy of the tree reflects the level of fault diffusion, thus obtaining the fault diffusion order of a single hardware fault affecting adjacent modules.

[0043] Specifically, the real-time self-test data stream is acquired using a long-connection mechanism based on the TCP / IP protocol. The terminal pushes a self-test data packet to the server every 500 milliseconds. The data packet is encapsulated in JSON format and includes the terminal number, detection timestamp, fault code array, and module identifier field corresponding to each code. Constructing the fault triggering time sequence requires preprocessing the raw data.

[0044] Specifically, duplicate fault codes are first filtered out, and the first occurrence of each code is retained. Then, the codes are sorted in ascending order by Unix timestamps to form a sequence of fault events on the timeline.

[0045] Preferably, the hardware connection relationship table is pre-stored in the system database, using an adjacency matrix to represent the connection relationships between modules. The rows and columns of the matrix correspond to each functional module, with a value of 0 indicating no connection, 1 indicating a power supply connection, 2 indicating a signal connection, and 3 indicating both power supply and signal connections. The matrix is ​​stored as a two-dimensional array structure, and the database table fields include module identifiers and connection types. Matrix elements are updated via the system interface or manually entered by the administrator.

[0046] For example, the construction of the physical dependency network involves a deep analysis of the connection relationships. In the power acquisition terminal, the power supply module is at the top level of the dependency relationship, providing 12V DC power to the communication module, 5V regulated power to the metering module, and 3.3V power to the storage module. In addition to relying on the power supply, the communication module also provides data bus signals to the storage module, forming a second-level dependency relationship. The metering module transmits measurement data signals to the display module, forming another dependency link. These dependencies form a multi-layered network topology, where power supply dependency has a mandatory characteristic, meaning that a failure of an upstream module will inevitably lead to the malfunction of a downstream module; signal dependency has a selective characteristic, meaning that a failure of an upstream module may cause partial functional limitations of a downstream module. By traversing the connection relationship table, all adjacent nodes of each failed module are extracted, and the dependency strength is determined according to the connection type, ultimately constructing a complete physical dependency network.

[0047] In one possible implementation, fault propagation tracing employs a breadth-first search algorithm. Starting with the module that first triggered the fault, it is set as the starting node. All directly connected downstream modules are then searched, and the time difference between the fault trigger time of these modules and that of the starting node is calculated.

[0048] Specifically, the calculation and determination of the time difference needs to consider hardware response latency. Power supply interruptions caused by power failures will affect directly connected modules within 10 milliseconds, while the impact latency of signal transmission interruptions is typically within 50 milliseconds. Based on this characteristic, a time threshold of 20 milliseconds is set for power supply connections, and a time threshold of 100 milliseconds is set for signal connections. When the actual time difference is less than the corresponding threshold, a fault propagation relationship is determined to exist. Through iterative tracing, all fault propagation paths that meet the time constraints are recorded, forming a complete propagation chain from the source to each affected module. The modules on each chain are arranged in the order in which the faults are triggered, reflecting the propagation process of the fault within the terminal. For cases where multiple propagation paths reach the same module, the path with the shortest time is selected as the primary propagation path, and the other paths are used as auxiliary verification information. Furthermore, the construction of the fault propagation tree follows a strict hierarchical structure principle. The root node is the module that triggered the fault earliest, the first-level child nodes are modules directly affected by the root node, the second-level child nodes are modules affected by the first-level nodes but not directly affected by the root node, and so on, establishing a multi-level tree structure.

[0049] For example, when a power module fails, the constructed fault propagation tree presents a four-layer structure: the root node is the power module; the first layer includes the communication, metering, and storage modules; the second layer includes the display module; and the third layer may include some peripheral interface modules. The depth of the tree reflects the scope of the fault's impact, and the number of leaf nodes reflects the severity of the fault. By accurately identifying the fault propagation sequence, maintenance personnel can quickly locate the source of the fault, avoiding being misled by multiple fault symptoms, thus improving the accuracy of remote fault diagnosis and maintenance efficiency.

[0050] S106. Based on the fault propagation sequence, combined with the terminal version information and the fault code generation timestamp in the fault timing record, verify the temporal consistency between the abnormal reporting sequence and the fault propagation sequence, evaluate the degree of agreement between the propagation path and the actual timing, and obtain the location result of a single hardware fault source.

[0051] Based on the fault propagation order, module identifiers and their hierarchical positions in the tree are extracted from each layer of the fault propagation tree. The theoretical trigger time is calculated by multiplying the hierarchical depth by a preset propagation delay time. The actual fault timestamp of the corresponding module is read from the terminal version information and fault timing records. The theoretical trigger time is subtracted from the actual timestamp to obtain the time deviation value. For the time deviation value, the number of nodes with an absolute deviation value less than a preset tolerance threshold is counted. This number is divided by the total number of nodes in the propagation tree to obtain the timing consistency ratio. If the ratio exceeds a preset judgment threshold, the propagation relationship of the propagation path is confirmed, and a path verification mark is obtained. Based on the path verification mark, all verified propagation paths are filtered, and the timing consistency ratios of each path are compared. The path with the highest ratio is selected, and the root node module of this path is taken as the fault source. Combining the physical location of the module, the fault type, and the set of triggered fault codes, the location result of a single hardware fault source is output.

[0052] Specifically, in one implementation, the calculation of the theoretical triggering time is based on the physical characteristics of fault propagation.

[0053] Specifically, the propagation delay for power supply faults is set to 10 milliseconds per layer, the propagation delay for signal faults is set to 30 milliseconds per layer, the theoretical trigger time of the root node is set to 0, and the theoretical trigger time of the nth layer node is equal to n multiplied by the corresponding propagation delay time.

[0054] It should be noted that the time deviation value is represented by a signed number, with a positive value indicating that the actual triggering is later than the theoretical expectation, and a negative value indicating that the actual triggering is earlier than the theoretical expectation. The absolute value of the deviation value reflects the degree of agreement between the actual propagation and the theoretical model.

[0055] For example, the timing consistency verification process involves the comprehensive judgment of multiple parameters. The tolerance threshold is dynamically adjusted according to the terminal hardware response speed. For newer terminals using high-speed processors, the tolerance threshold is set to 50 milliseconds; for older terminals, the tolerance threshold is relaxed to 100 milliseconds. In a typical power failure case, the fault propagation tree contains 8 nodes, of which 6 nodes have an absolute time deviation of less than 50 milliseconds. The timing consistency ratio is calculated as 6 divided by 8, which equals 0.75. The judgment threshold is usually set to 0.7, indicating that at least 70% of the nodes need to meet the timing constraints. When the timing consistency ratio of 0.75 is greater than the judgment threshold of 0.7, it is confirmed that the propagation path reflects the actual fault propagation process, and the path verification flag is set to true. This verification mechanism can effectively filter out occasional, unrelated fault codes, ensuring that the identified propagation paths have a causal relationship.

[0056] Preferably, when there are multiple verified diffusion paths, the most likely source of failure is determined by ranking them by proportion.

[0057] For example, if the timing consistency ratio of the power failure path is 0.85 and the ratio of the communication failure path is 0.65, then the power module is selected as the fault source. Furthermore, the location result of a single hardware fault source includes four elements: the name of the fault source module, the physical location coordinates of the module within the terminal, the fault type classification code, and a complete list of fault codes triggered by that fault.

[0058] S107. Generate a diagnostic report from the location results of a single hardware fault source, update the fault manifestations of serial and parallel detection modes in the fault identification basis library through diagnostic records, and realize fault diagnosis adaptation under different firmware versions.

[0059] The fault source module name, physical location coordinates, fault code set, and firmware version number are extracted from the location results of the single hardware fault source. This information is written into a text file in the order of four fields: fault source, location, code, and version, forming a structured diagnostic report. The detection mode is determined based on the firmware version number in the diagnostic report: version numbers less than 3.0 correspond to serial detection, while versions greater than or equal to 3.0 correspond to parallel detection. The fault code set is appended as a new record to the corresponding partition of the fault identification basis library. The serial partition stores single fault codes, and the parallel partition stores combinations of multiple fault codes, completing the fault diagnosis adaptation.

[0060] Specifically, in one implementation, the diagnostic report is stored in CSV format, with each row containing four fields separated by commas. The fault source field stores the standard name of the module, such as "PWR_MODULE"; the location field stores the three-dimensional coordinates, such as "X12Y08Z03"; the code field stores the list of fault codes; and the version field stores the firmware version number. The fault identification database uses a partitioned storage structure, with serial and parallel partitions corresponding to different data tables. Each record in the serial partition contains only a single fault code and its mapping to the fault type, such as "E001" mapping to "power failure". Records in the parallel partition contain combinations of fault codes, such as "E001, E101, E201, E301, E401" all mapping to "power failure". Automatic detection mode determination is achieved by comparing version numbers, which are in floating-point format for easy comparison. The append operation of a new record uses a transaction mechanism, first writing the fault code set to a temporary table, verifying data integrity, and then committing it to the formal partition to ensure database consistency and achieve seamless connection of fault diagnosis across different terminal versions.

[0061] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A remote intelligent fault diagnosis and analysis method for an energy acquisition terminal, characterized in that, include: The version information and fault timing records are obtained from the power acquisition terminal to determine the self-test execution method. Based on the version information and the fault timing record, analyze the triggering pattern of the fault code to identify the candidate range of a single hardware fault source; Based on the self-test execution method and the candidate range, the consistency of fault performance is evaluated, and a fault identification basis library with version adaptation is constructed. Fault performance characteristics are extracted from the fault identification database, and the correspondence between a single hardware fault source and fault code performance is analyzed to obtain the basis for the correspondence between fault sources and code performance. The real-time self-test data of the power acquisition terminal is obtained, and the fault propagation sequence is identified based on the correspondence between the fault source and the code manifestation. Based on the fault propagation sequence and the fault timing record, verify the timing consistency and determine the location result of a single hardware fault source; A diagnostic report is generated based on the location results, and the fault identification database is updated to adapt to different versions.

2. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The step of obtaining version information and fault timing records from the power acquisition terminal to determine the self-test execution mode includes: A version query command is sent to the power acquisition terminal via a remote communication protocol to obtain the firmware version number and parse the major version number and sub-version number in the firmware version number. If the main version number is less than a preset threshold, it is determined to be a serial detection method; otherwise, it is determined to be a parallel detection method. According to the serial detection method or the parallel detection method, the power acquisition terminal is connected through a security protocol to read the log file and extract the fault codes and timestamps of each functional module; The fault code sequence is formed by arranging the timestamps in ascending order, and the firmware version number, the self-test execution mode, and the fault code are combined into the version information and the fault timing record.

3. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The step of analyzing the triggering pattern of fault codes based on the version information and the fault timing record to identify the candidate range of a single hardware fault source includes: Extract the timestamps of each fault code from the fault timing record and calculate the time interval between adjacent timestamps; If the time interval is less than a preset threshold, the corresponding fault codes are grouped into the same time window, and the number and distribution characteristics of fault codes within the time window are statistically analyzed. If the number of fault codes exceeds a preset threshold within the time window, the relevant functional module identifiers are extracted, the power supply relationship and signal dependency relationship between modules are queried, and the fault propagation link is identified. Based on the frequency of fault codes in the fault propagation link, a probability value is calculated. If the probability value exceeds a preset threshold, the link source node is determined as a candidate for the single hardware fault source.

4. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The process of evaluating the consistency of fault behavior based on the self-test execution method and the candidate range, and constructing a version-adaptive fault identification basis library, includes: Extract the abnormal report sequences of each fault source under different self-test execution modes from the candidate range, and compare the fault code performance of serial detection and parallel detection; A consistency score is obtained by calculating the ratio of the number of fault codes and the degree of difference in timing distribution; If the consistency score is lower than a preset threshold, a fault code mapping table is established to record the corresponding relationship under different detection methods; Based on the mapping table and the version information, configure the corresponding rule set, associate the rule set with the version range, and store it as a fault identification basis library for version adaptation.

5. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The step of extracting fault manifestation features from the fault identification database, analyzing the correspondence between single hardware fault sources and fault code manifestations, and obtaining the basis for the correspondence between fault sources and code manifestations includes: Fault records in parallel detection mode are read from the fault identification database, and fault code combinations and related features are extracted. Clustering algorithms are used to group fault records to obtain a set of common performance features of each fault source; Based on the feature set, the frequency of fault code combinations is statistically analyzed, a mapping matrix is ​​constructed, and typical code performance patterns are extracted. Based on the typical code behavior pattern, the fault propagation path is traced. If the fault codes on the path appear simultaneously within a preset time window, it is determined to be a chain reaction. The characteristics of the chain reaction are recorded, and a correspondence between the fault source and the code behavior is established.

6. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The process of acquiring real-time self-test data from the power acquisition terminal and identifying the fault propagation sequence based on the correspondence between the fault source and the code manifestation includes: The real-time self-test data stream of the power acquisition terminal is obtained through the remote communication interface, and the fault codes and timestamps are parsed to form a fault triggering time sequence. Based on the module identifiers in the time sequence, query the hardware connection relationship table and extract the physical dependency relationship network between modules; Starting from the earliest faulty module in the time sequence, the fault propagation is traced along the connection path, and the time difference is calculated; If the time difference is less than a preset threshold, it is determined that there is a diffusion relationship, a fault diffusion tree structure is constructed, and the fault diffusion order is obtained.

7. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The step of determining the location result of a single hardware fault source by verifying the timing consistency based on the fault propagation sequence and the fault timing record includes: Extract the module-level position from the fault propagation sequence and calculate the theoretical trigger time; Read the actual timestamp from the fault timing record, and subtract the theoretical trigger time from the actual timestamp to obtain the time deviation value; The consistency ratio is calculated based on the time deviation value. If the consistency ratio exceeds a preset threshold, the propagation relationship is confirmed. The diffusion paths that have passed the screening and verification are selected, and the path with the highest consistency ratio is identified as the root node module of the path as the source of the fault. The location result is then output by combining the module location and the fault code.

8. The remote fault intelligent diagnosis and analysis method for power acquisition terminals as described in claim 1, characterized in that, The process of generating a diagnostic report based on the location results and updating the fault identification database to adapt to different versions includes: Extract the fault source module name, location coordinates, and fault code set from the location results, and write them into a text file in the order of the fields to form a structured diagnostic report; Based on the version information, the detection mode is determined, and the set of fault codes is appended to the corresponding partition of the fault identification basis library; If it is in serial detection mode, a single fault code is stored; In parallel detection mode, multiple fault code combinations are stored to complete the fault diagnosis adaptation for different versions.

Images