A concentrator fault information acquisition and analysis method and device and medium

CN122601443APending Publication Date: 2026-08-18QINGDAO ITECHENE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610932386.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-26
Publication Date
2026-08-18

AI Technical Summary

Technical Problem

目前,行业内的集中器普遍采用集中式架构设计,其通信模块主要服务于电网内部数据交互,缺乏面向设备制造商的独立诊断通道,在集中器出现故障时,其故障信息无法通过集中器内部的通信模块传输至厂家

Benefits of technology

1)能够基于协议特征识别当前通信场景类型,判定传输模式,若判定为本地路由模式,则集中器向上位机发送故障报文,上位机接收并存储故障报文;若判定为透明传输模式,则集中器向故障信息采集分析单元发送故障报文,消除了对上位机的依赖,在集中器发生故障时,故障若不能及时存储至上位机中,则能够存储至故障信息采集分析单元中,以便实时采集并记录集中器的故障信息,而无需再次采集故障信息,能够基于采集的故障信息,及时对集中器的故障问题进行处理,提升故障处理的效率;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122601443A_ABST
    Figure CN122601443A_ABST
Patent Text Reader

Abstract

The application provides a concentrator fault information collection and analysis method and device and a medium, which can identify the current communication scene type based on protocol characteristics, determine the transmission mode, if it is determined as a local routing mode, the concentrator sends a fault message to an upper computer, and the upper computer receives and stores the fault message, if it is determined as a transparent transmission mode, the concentrator sends the fault message to a fault information collection and analysis unit, and the dependence on the upper computer is eliminated, when the concentrator fails, if the fault cannot be stored in the upper computer in time, the fault can be stored in the fault information collection and analysis unit, so that the fault information of the concentrator can be collected and recorded in real time, and it is not necessary to collect the fault information again, the fault problem of the concentrator can be processed in time based on the collected fault information, and the efficiency of fault processing is improved, the current communication scene type can be identified based on protocol characteristics, and the transmission mode can be switched in time, and it is not necessary to use a physical jumper or replace a module, and the switching time is greatly reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of smart grid equipment technology, and in particular to a method, device and medium for collecting and analyzing concentrator fault information. Background Technology

[0002] In the fields of smart grids and industrial automation, concentrators, as key data acquisition and transmission devices, play a crucial role in connecting terminal equipment with the master station system. With the expansion of power grids and the development of IoT technology, the number of concentrators deployed has increased dramatically, making their reliability and maintainability critical factors affecting the stable operation of the entire system. Currently, concentrators in the industry generally adopt a centralized architecture design, with their communication modules primarily serving internal power grid data exchange. They lack independent diagnostic channels for equipment manufacturers, meaning that when a concentrator malfunctions, fault information cannot be transmitted to the manufacturer through the concentrator's internal communication modules.

[0003] In existing technologies, when a concentrator malfunctions, operators need to go to the site to collect fault information. This typically involves connecting the concentrator to a host computer and running it for a period of time. If the concentrator malfunction is intermittent, the time required to collect fault information can vary, sometimes lasting several days. Maintenance personnel must then wait at the site to collect, analyze, and identify problems before performing maintenance on the concentrator. This process is time-consuming, leading to untimely fault information acquisition and incomplete fault analysis. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method, apparatus, and medium for collecting and analyzing concentrator fault information.

[0005] A first aspect of this application provides a method for collecting and analyzing concentrator fault information, the method comprising the following steps: Step S1: Establish a communication connection between the fault information acquisition and analysis unit and the concentrator; Step S2: Continuously monitor the communication data received by the target channel; Step S3: Analyze the protocol features in the communication data; Step S4: Identify the current communication scenario type based on protocol characteristics and determine the transmission mode; if it is determined to be a transparent transmission mode, the concentrator sends a fault message to the host computer, and the host computer receives and stores the fault message; if it is determined to be a local routing mode, the concentrator sends a fault message to the fault information collection and analysis unit and executes subsequent steps. Step S5: The fault information acquisition and analysis unit receives the fault message and parses the fault message to obtain structured fault data. Step S6: Store the parsed structured fault data and fault messages.

[0006] In some embodiments of this application, the method further includes the following steps: Step S7: Determine the structured fault data. If it is determined to be a protocol fault, switch to point-to-point transmission mode.

[0007] In some embodiments of this application, in step S4, the protocol features include the protocol field of the handshake frame, baud rate matching features, and link interaction instructions.

[0008] In some embodiments of this application, the logic for determining the transmission mode in step S4 is as follows: When it is detected that the handshake protocol does not contain routing addressing instructions, has no local data parsing requirements, and only contains point-to-point transparent heartbeat frames and pass-through interaction messages, it is determined to be transparent transmission mode; When the handshake protocol contains routing addressing instructions, multi-terminal data scheduling instructions, or protocol interaction verification frames issued by the platform, it is determined to be in local routing mode.

[0009] In some embodiments of this application, step S5 includes the following steps: Step S51, frame validity check: determine whether the received fault message is a valid fault reporting message. If so, continue to the next step. Step S52: Field segmentation and extraction of fault code, channel number, time information, number of faults, and fault level data in sequence according to the specification definition; Step S53: Data comparison and matching, compare the fault code with the local fault dictionary database to locate the cause of the fault; Step S54: Determine fault attributes and obtain structured fault data.

[0010] In some embodiments of this application, in step S4, under transparent transmission mode, the dual-buffered queue pass-through mechanism is activated, and two independent dual-buffered queues are constructed, one from the first UART channel to the second UART channel and the other from the second UART channel to the first UART channel. Each queue is configured with a receive buffer and a transmit buffer, and a ping-pong switching scheduling logic is adopted to enable the receive buffer and the transmit buffer to operate in parallel.

[0011] In some embodiments of this application, the step of switching to point-to-point transmission mode in step S7 is as follows: Step S71: Collect the physical layer status parameters of the target channel through the hardware detection circuit and generate a hardware integrity judgment signal; Step S72: In response to the hardware integrity determination signal, suspend the protocol parsing, frame verification, data sorting and fault reporting business logic of the target channel. Step S73: Clear the unprocessed data cache of the target channel; Step S74: Construct a direct data link between the target channel and the communication endpoint, close the protocol encapsulation and decoding process, and realize point-to-point transparent data transmission; Step S75: Store and record the mode switching event; Step S76: Start link quality monitoring. When a preset number of consecutive data frame interactions meet the quality threshold conditions, automatically resume the protocol parsing working mode.

[0012] In some embodiments of this application, step S7 further includes the following steps: If a preset number of consecutive data frame interactions do not meet the quality threshold conditions, switch to another protocol.

[0013] A second aspect of this application provides a concentrator fault information acquisition and analysis unit, including a main control module, an isolation communication module, a storage module, and a mode switching module; The main control module is used to parse fault messages; The isolation communication module is used to achieve communication and electrical isolation with the concentrator and the host computer; The storage module is used to store communication protocols, fault messages, and structured fault data; The mode switching module is used to automatically identify and switch the data transmission mode based on the protocol characteristics in the communication data.

[0014] A third aspect of this application provides a computer-readable medium storing a computer program that, when executed by a processor, implements the steps of the above-described concentrator fault information acquisition and analysis method.

[0015] Compared with the prior art, the present invention has the following advantages and beneficial effects: 1) It can identify the current communication scenario type and determine the transmission mode based on protocol characteristics. If it is determined to be in local routing mode, the concentrator sends a fault message to the host computer, which receives and stores the fault message. If it is determined to be in transparent transmission mode, the concentrator sends a fault message to the fault information collection and analysis unit, eliminating the dependence on the host computer. When the concentrator fails, if the fault cannot be stored in the host computer in time, it can be stored in the fault information collection and analysis unit so as to collect and record the concentrator's fault information in real time without having to collect the fault information again. Based on the collected fault information, the concentrator's fault problems can be handled in a timely manner, improving the efficiency of fault handling. 2) It can identify the current communication scenario type based on protocol characteristics and switch the transmission mode in a timely manner without the need for physical jumpers or module replacement, thus significantly reducing the switching time; 3) In transparent transmission mode, the double-buffered queue pass-through mechanism is activated to realize hardware-level pass-through forwarding of data without application layer processing, reducing communication latency, making device deployment flexible and suitable for various scenarios.

[0016] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this document. Attached Figure Description

[0017] The accompanying drawings, which form part of this document, are used to provide a further understanding of the document. The illustrative embodiments and descriptions herein are used to explain the document and do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the principle of the concentrator fault information collection and analysis method provided in an exemplary embodiment of this application; Figure 2 This is a schematic diagram of a transparent transmission mode provided in an exemplary embodiment of this application; Figure 3 This is a schematic diagram of a local routing mode provided in an exemplary embodiment of this application; Figure 4 This is a schematic diagram of a concentrator fault information acquisition and analysis unit provided in an exemplary embodiment of this application; Figure 5 This is a circuit diagram of the main control module provided in an exemplary embodiment of this application; Figure 6 This is a circuit diagram of an isolated communication module provided in an exemplary embodiment of this application; Figure 7 This is a circuit diagram of a storage module provided in an exemplary embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other.

[0019] In the fields of smart grids and industrial automation, concentrators, as key data acquisition and transmission devices, play a crucial role in connecting terminal equipment with the master station system. With the expansion of power grids and the development of IoT technology, the number of concentrators deployed has increased dramatically, making their reliability and maintainability critical factors affecting the stable operation of the entire system. Currently, concentrators in the industry generally adopt a centralized architecture design, with their communication modules primarily serving internal power grid data exchange. They lack independent diagnostic channels for equipment manufacturers, meaning that when a concentrator malfunctions, fault information cannot be transmitted to the manufacturer through the concentrator's internal communication modules.

[0020] In existing technologies, when a concentrator malfunctions, operators need to go to the site to collect fault information. This typically involves connecting the concentrator to a host computer and running it for a period of time. If the concentrator malfunction is intermittent, the time required to collect fault information can vary, sometimes lasting several days. Maintenance personnel must then wait at the site to collect, analyze, and identify problems before performing maintenance on the concentrator. This process is time-consuming, leading to untimely fault information acquisition and incomplete fault analysis.

[0021] Based on this, exemplary embodiments of this application provide a concentrator fault information collection and analysis method, apparatus, device, and medium. It can identify the current communication scenario type and determine the transmission mode based on protocol characteristics. If determined to be a local routing mode, the concentrator sends a fault message to the host computer, which receives and stores the fault message. If determined to be a transparent transmission mode, the concentrator sends a fault message to the fault information collection and analysis unit, eliminating dependence on the host computer. When a concentrator fault occurs, if the fault cannot be stored in the host computer in a timely manner, it can be stored in the fault information collection and analysis unit, enabling real-time collection and recording of the concentrator's fault information without needing to collect fault information again. Based on the collected fault information, the concentrator's fault problems can be handled promptly, improving fault handling efficiency. It can identify the current communication scenario type and switch the transmission mode in a timely manner based on protocol characteristics, without the need for physical jumpers or module replacement, significantly reducing switching time. In transparent transmission mode, a double-buffered queue pass-through mechanism is activated, enabling hardware-level pass-through forwarding of data without application layer processing, reducing communication latency, making device deployment flexible, and suitable for various scenarios.

[0022] Example 1: An exemplary embodiment of this application provides a method for collecting and analyzing concentrator fault information, such as... Figure 1 As shown, the method includes the following steps: Step S1: Establish a communication connection between the fault information acquisition and analysis unit and the concentrator; Step S2: Continuously monitor the communication data received by the target channel; for example, the fault information acquisition and analysis unit includes three serial port channels, namely the first UART channel, the second UART channel, and the third UART channel. During power-on initialization and operation, continuously monitor the host computer handshake messages, link interaction protocols, and heartbeat frame data of the first UART channel; Step S3: parse the protocol features in the communication data; wherein, the protocol features in the communication data include the handshake protocol frame structure, baud rate matching features, and link interaction instructions; Step S4: Identify the current communication scenario type based on protocol characteristics and determine the transmission mode; such as... Figure 2 and 3 As shown, if the device is determined to be in local routing mode, the concentrator sends a fault message to the host computer, which receives and stores the fault message. If the device is determined to be in transparent transmission mode, the concentrator sends a fault message to the fault information acquisition and analysis unit and executes subsequent steps. When a host computer direct transmission handshake command is detected, the device automatically enters transparent forwarding mode; when a platform routing scheduling or local data aggregation handshake command is detected, the device automatically enters local routing mode. Using the first UART channel handshake protocol frame as the sole criterion, the device achieves fully automatic and seamless identification and switching of operating modes, completely eliminating the limitations of manual configuration and forced switching by external commands, and realizing dynamic adaptive matching between the device communication mode and the field network architecture. The fault information acquisition and analysis unit has two built-in sets of dedicated handshake protocol identification rules, which can accurately distinguish between the two operating scenarios and solve problems such as mode aliasing and misjudgment.

[0023] In step S4, the logic for determining the transmission mode is as follows: When the handshake protocol is found to contain no routing addressing instructions, no local data parsing requirement, and only point-to-point transparent heartbeat frames and direct interaction messages, it is determined to be in transparent transmission mode, which is a simple point-to-point communication scenario. The protocol parsing, data routing, and fault storage and sorting logic of the fault information collection and analysis unit are automatically turned off, and the direct link from the first UART channel to the second UART channel and the third UART channel is opened to achieve zero data parsing and low-latency transparent forwarding, which is suitable for simple terminal direct connection networking scenarios on site.

[0024] When the handshake protocol contains routing addressing instructions, multi-terminal data scheduling instructions, or protocol interaction verification frames issued by the platform, it is determined to be in local routing mode, which means it is determined to be a multi-terminal aggregation networking scenario. It automatically activates local routing scheduling, multi-UART channel data distribution, fault message parsing, and FLASH log storage functions. Relying on the industrial-grade MCU three-channel UART resources of the main control module, it realizes multi-channel data aggregation, local processing, and proactive reporting, adapting to complex industrial multi-terminal networking scenarios.

[0025] In step S4, under transparent transmission mode, a dual-buffered queue pass-through mechanism is activated, constructing two independent dual-buffered queues: one from the first UART channel to the second UART channel, and the other from the second UART channel to the first UART channel. This differs from the single-buffered shared read-write architecture, achieving physical buffer isolation between the two transmission directions. Each queue is configured with dual partitions for receiving and transmitting buffers, employing a "ping-pong switching" scheduling logic to allow the receiving and transmitting buffers to operate in parallel. The receiving buffer is responsible for real-time capture of the serial port data stream, while the transmitting buffer is responsible for synchronous data push. Reading and writing operations are executed in parallel without resource contention, resolving the technical problems of mutual exclusion, waiting blocking, and data overwriting in the single-buffered mechanism. This provides a hardware scheduling foundation for bidirectional, fully concurrent, zero-latency forwarding. In this application, a dedicated bypass pass-through logic is designed for transparent transmission mode. When the system enters the transparent forwarding scenario, redundant protocol parsing, fault parsing, log caching, and routing scheduling business threads are automatically shut down, retaining only the underlying hardware data transport logic of the dual-buffered queues. Data is not processed by the MCU application layer, but is directly passed through the UART channel via a double buffer queue, eliminating software-level processing delay and truly realizing hardware-level zero-latency bidirectional forwarding between each UART channel.

[0026] Preferably, in local routing mode, the third UART channel can be used as a debug port storage mapping strategy.

[0027] In step S5, the fault information acquisition and analysis unit receives the fault message and parses the fault message to obtain structured fault data.

[0028] Step S6: Store the parsed structured fault data and fault messages so that operators can retrieve the fault messages and structured fault data at any time to obtain complete fault data and the fault environment, so as to conduct comprehensive fault analysis.

[0029] In transparent transmission mode, the device can independently complete data routing and recording without relying on host computer software, thanks to its built-in protocol parsing engine and log storage function, thus improving deployment flexibility.

[0030] Step S5 includes the following steps: Step S51, frame validity check: determine whether the received fault message is a valid fault reporting message. If so, continue to the next step. Step S52: Field segmentation and extraction of fault code, channel number, time information, number of faults, and fault level data in sequence according to the specification definition; Step S53: Data comparison and matching, compare the fault code with the local fault dictionary database to locate the cause of the fault; Step S54: Determine fault attributes and obtain structured fault data.

[0031] The method further includes the following steps: Step S7: Determine the structured fault data. If it is determined to be a protocol fault, switch to point-to-point transmission mode.

[0032] In step S7, the steps for switching to point-to-point transmission mode are as follows: Step S71: Collect the physical layer status parameters of the target channel through the hardware detection circuit and generate a hardware integrity judgment signal; Step S72: In response to the hardware integrity determination signal, suspend the protocol parsing, frame verification, data sorting and fault reporting business logic of the target channel. Step S73: Clear the unprocessed data cache of the target channel; Step S74: Construct a direct data link between the target channel and the communication endpoint, close the protocol encapsulation and decoding process, and realize point-to-point transparent data transmission; Step S75: Store and record the mode switching event; Step S76: Start link quality monitoring. When a preset number of consecutive data frame interactions meet the quality threshold conditions, automatically resume the protocol parsing working mode.

[0033] For example, the concentrator's second serial port downlink communication timed out, and there was no response to the terminal data request for 3 consecutive frames. The device actively generated a fault reporting message with fault code 0x0203, which means serial port communication timeout fault. The fault location is the second serial port channel, the fault time is 2026-05-11 10:25:36, the fault level is level 2 fault, the link is abnormal, and it is not due to device hardware damage.

[0034] The concentrator's MCU polls the serial communication status of the first, second, and third serial ports in real time, continuously monitoring data transmission, reception, and response. If, after the second serial port sends three consecutive data request messages without receiving a response frame from the terminal device within 500ms, a serial communication timeout fault is identified. Subsequently, the MCU automatically encapsulates a standardized fault reporting message according to the "Power Concentrator Serial Communication Fault Protocol" and proactively sends the message to the fault information acquisition and analysis unit through the second serial port communication channel.

[0035] The original fault message hexadecimal data sent this time is: 68 10 02 03 02 26 05 11 10 25 3600 01 03 00 7F. Its message field definitions are as follows: 68 (frame header), 10 (message effective length), 02 03 (fault code), 02 (fault channel identifier), the following 6 bytes are the fault occurrence time, 00 01 (accumulated number of faults), 03 (fault level), 00 (reserved bit), 7F (frame tail).

[0036] The fault message first enters the isolated communication module, where electrical isolation and level conversion are achieved through the isolated TTL-RS232 conversion circuit. Simultaneously, the built-in ESD protection device filters out static electricity, surges, and line noise interference, repairing minor signal distortions during transmission and ensuring the message frame is complete and distortion-free. Subsequently, the fault information acquisition and analysis unit fully receives the valid fault message, automatically matches it to the DL / T645 power communication protocol to complete message parsing, and finally obtains accurate structured fault data. The fault data includes: fault type: second serial port communication timeout fault; fault channel: the second serial port channel out of three serial port channels; fault occurrence time: 2026-05-11 10:25:36; cumulative fault count: 1; fault level: level 2 link abnormality fault; fault attribute: recoverable soft fault, no hardware damage.

[0037] The specific process of parsing the message is as follows: First, frame validity verification: identify the message header 0x68 and frame tail 0x7F, verify the message length and checksum, remove incomplete frames and interference / garbled frames, and determine that the current message is a legitimate fault reporting message; Second, field segmentation: extract the fault code, channel number, time information, number of faults, and fault level data in sequence according to the protocol definition; Third, data comparison and matching: compare the fault code 0x0203 with the local fault dictionary to locate the cause of the fault as serial port continuous response timeout and temporary link communication abnormality; Fourth, fault attribute determination: combine the UART2 port voltage and pin status feedback from the hardware detection circuit to rule out hardware faults such as serial port hardware burnout and short circuit, and confirm that the fault is a temporary link abnormality caused by external interference.

[0038] After completing message parsing and verification, the SPI high-speed communication interface is invoked to store the original hexadecimal fault message, the parsed structured fault information, the fault determination result, and the operation status log into the onboard SPI interface FLASH chip. The entire storage process utilizes the chip's configured write balancing algorithm, dynamically allocating FLASH storage sectors to avoid wear and data loss caused by frequent erasure and writing of a single sector, thus improving the long-term operational stability of the device. Simultaneously, the system establishes a time index for fault data, enabling fault logs to be queryable, traceable, and not lost even after power failure, providing data support for subsequent equipment maintenance, fault review, and link optimization.

[0039] For fault diagnosis, the system relies on a dual-mode switching mechanism of hardware detection circuit and software protocol recognition to make a comprehensive judgment: if the detected fault is a self-healing fault that is not hardware damage, temporary link interference, or abnormal protocol interaction, the exemplary second serial port communication timeout fault meets this condition, then the system immediately exits the normal protocol parsing working mode and automatically switches to point-to-point transmission mode to avoid continuous communication interruption caused by protocol parsing lag and frame verification misjudgment.

[0040] The process of switching to point-to-point transmission mode is as follows: First, the hardware detection circuit collects the pin levels of the second serial port channel and the working status of the transceiver circuit in real time to confirm that the communication hardware circuit is intact and outputs a hardware fault-free judgment signal to provide hardware basis for software switching; Second, the software system suspends the custom business logic of the second serial port channel, such as DL / T645 protocol parsing, frame verification, data sorting, and fault reporting, and clears the cached data that has not been parsed in the current channel; Third, the MCU establishes a direct data link between the second serial port and the upper and lower computer, closes the protocol encapsulation and decoding process, and realizes point-to-point data transmission; Then, the mode switching event, switching time, and triggered fault type are synchronously written to the FLASH log; Finally, the system starts real-time link monitoring, continuously counts the data transmission and reception success rate of the second serial port channel, and automatically switches back to the normal protocol parsing working mode after 10 consecutive frames of normal data interaction without timeout or packet loss, restoring the normal fault monitoring and data processing functions of the device.

[0041] Step S7 further includes the following steps: When a preset number of consecutive data frame interactions fail to meet the quality threshold, the system switches to another protocol to ensure timely switching and prevent the concentrator from remaining in a faulty state for an extended period.

[0042] Example 2: This invention also provides a concentrator fault information acquisition and analysis unit, such as... Figure 4 As shown, the concentrator fault information acquisition and analysis device includes a main control module, an isolation communication module, a storage module, and a mode switching module. The main control module is used to parse fault messages. The isolation communication module is used to achieve communication and electrical isolation between the concentrator and the host computer. The storage module is used to store communication protocols, fault messages, and structured fault data. The mode switching module is used to automatically identify and switch data transmission modes based on protocol characteristics in the communication data. For example,... Figure 5 As shown, the main control module is an industrial-grade MCU equipped with three UART channels: a first UART channel, a second UART channel, and a third UART channel. The third UART channel provides an AT command set, supporting operations such as custom log queries, baud rate modifications, and hardware status readings, improving secondary development efficiency. Figure 6 As shown, the isolated communication module integrates an isolated TTL-RS232 conversion circuit, and the RS232 interface is configured with a TVS array, which enhances isolation and reduces the chip failure rate. Figure 7The diagram shows the circuit of the storage module, featuring an SPI interface FLASH chip configured with a write-balanced algorithm. It can be divided into a protocol storage area and a circular log area. Furthermore, the protocol conversion table of the FLASH chip can be updated via a third UART channel serial port to adapt it to various communication protocols. The mode switching module incorporates a dual-mode switching mechanism with built-in hardware detection circuitry and software protocol recognition.

[0043] The concentrator fault information acquisition and analysis device may also include a battery module, which is electrically connected to the main control module, the isolation communication module, the storage module, and the mode switching module to provide power to the above modules, making it convenient for use in scenarios where it is inconvenient to supply mains power.

[0044] Example 3: The present invention also provides a computer-readable medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the concentrator fault information acquisition and analysis method as described in Embodiment 1.

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

[0046] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0047] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations fall within the scope of the claims of this application and their equivalents, the intent of this application also includes these modifications and variations.

Claims

1. A method for collecting and analyzing concentrator fault information, characterized in that, The method includes the following steps: Step S1: Establish a communication connection between the fault information acquisition and analysis unit and the concentrator; Step S2: Continuously monitor the communication data received by the target channel; Step S3: Analyze the protocol features in the communication data; Step S4: Identify the current communication scenario type based on protocol characteristics and determine the transmission mode; if it is determined to be a local routing mode, the concentrator sends a fault message to the host computer, and the host computer receives and stores the fault message; If the transmission mode is determined to be transparent, the concentrator sends a fault message to the fault information collection and analysis unit and executes subsequent steps. Step S5: The fault information acquisition and analysis unit receives the fault message and parses the fault message to obtain structured fault data. Step S6: Store the parsed structured fault data and fault messages.

2. The method for collecting and analyzing concentrator fault information according to claim 1, characterized in that, The method further includes the following steps: Step S7: Determine the structured fault data. If it is determined to be a protocol fault, switch to point-to-point transmission mode.

3. The method for collecting and analyzing concentrator fault information according to claim 1, characterized in that, In step S4, the protocol features include the protocol field of the handshake frame, baud rate matching features, and link interaction instructions.

4. The method for collecting and analyzing concentrator fault information according to claim 1, characterized in that, In step S4, the logic for determining the transmission mode is as follows: When it is detected that the handshake protocol does not contain routing addressing instructions, has no local data parsing requirements, and only contains point-to-point transparent heartbeat frames and pass-through interaction messages, it is determined to be transparent transmission mode; When the handshake protocol contains routing addressing instructions, multi-terminal data scheduling instructions, or protocol interaction verification frames issued by the platform, it is determined to be in local routing mode.

5. The method for collecting and analyzing concentrator fault information according to claim 1, characterized in that, Step S5 includes the following steps: Step S51, frame validity check: determine whether the received fault message is a valid fault reporting message. If so, continue to the next step. Step S52: Field segmentation and extraction of fault code, channel number, time information, number of faults, and fault level data in sequence according to the specification definition; Step S53: Data comparison and matching, compare the fault code with the local fault dictionary database to locate the cause of the fault; Step S54: Determine fault attributes and obtain structured fault data.

6. The method for collecting and analyzing concentrator fault information according to claim 1, characterized in that, In step S4, under transparent transmission mode, the dual-buffered queue pass-through mechanism is activated, and two independent dual-buffered queues are constructed, one from the first UART channel to the second UART channel and the other from the second UART channel to the first UART channel. Each queue is configured with a receive buffer and a transmit buffer, and a ping-pong switching scheduling logic is adopted to enable the receive buffer and the transmit buffer to operate in parallel.

7. The method for collecting and analyzing concentrator fault information according to claim 2, characterized in that, In step S7, the steps for switching to point-to-point transmission mode are as follows: Step S71: Collect the physical layer status parameters of the target channel through the hardware detection circuit and generate a hardware integrity judgment signal; Step S72: In response to the hardware integrity determination signal, suspend the protocol parsing, frame verification, data sorting and fault reporting business logic of the target channel. Step S73: Clear the unprocessed data cache of the target channel; Step S74: Construct a direct data link between the target channel and the communication endpoint, close the protocol encapsulation and decoding process, and realize point-to-point transparent data transmission; Step S75: Store and record the mode switching event; Step S76: Start link quality monitoring. When a preset number of consecutive data frame interactions meet the quality threshold conditions, automatically resume the protocol parsing working mode.

8. The method for collecting and analyzing concentrator fault information according to claim 7, characterized in that, Step S7 further includes the following steps: If a preset number of consecutive data frame interactions do not meet the quality threshold conditions, switch to another protocol.

9. A concentrator fault information acquisition and analysis unit, characterized in that, It includes a main control module, an isolated communication module, a storage module, and a mode switching module; The main control module is used to parse fault messages; The isolation communication module is used to achieve communication and electrical isolation with the concentrator and the host computer; The storage module is used to store communication protocols, fault messages, and structured fault data; The mode switching module is used to automatically identify and switch the data transmission mode based on the protocol characteristics in the communication data.

10. A computer-readable medium, wherein a computer program is stored on the computer-readable storage medium, characterized in that, When the computer program is executed by the processor, it implements the steps of the concentrator fault information acquisition and analysis method as described in any one of claims 1 to 8.