Method for positioning abnormal data of communication module

Abstract

The invention provides a method for positioning abnormal data of a communication module in order to solve the problem that a root cause cannot be determined for accidental communication abnormity in the prior art. Comprising the following steps: establishing connection by a master station, judging the type of connection abnormity when the connection is abnormal, executing corresponding operation, opening each log storage function, and establishing short connection between a module and an event server. According to the invention, detailed communication data can be provided, deep analysis of abnormal reasons is facilitated, and the basis and accuracy of problem solving are enhanced.

Description

Technical Field

[0001] The invention relates to the field of digital information transmission, and in particular to a method for locating abnormal data of a communication module. Background Art

[0002] When a communication anomaly occurs in the remote communication module, engineers need to reproduce the problem on site, capture log files, and analyze them. It is very difficult to reproduce and locate sporadic and random problems. For random communication anomalies, since there are no logs when the communication anomaly occurs, it is necessary to reproduce on site, capture logs, and analyze them, which is difficult to locate and inefficient. When the communication is normal, since it is impossible to obtain logs remotely, it is impossible to assist in locating the communication anomaly between the main station and the smart meter.

[0003] In order to solve the above problems, the Chinese invention patent with patent number CN107046485A proposes a method for remotely locating the position of abnormal devices, including: step 1, real-time monitoring of system devices to obtain abnormal messages of the system devices; step 2, filtering and processing the abnormal messages to obtain valid abnormal messages of external disk array devices; step 3, after parsing the valid abnormal messages, the valid abnormal messages are updated to the device status table through the device number-system device name-device type mapping table and the device interface location-device interface system path mapping table; step 4, querying the device status table to obtain the type, number, and interface location information of the abnormal device on the external panel. However, this invention obtains the type, number, and interface location information of the abnormal device on the external panel, which only has the function of positioning, and does not process or help the analysis of subsequent abnormal problems. Summary of the invention

[0004] The present invention mainly solves the problem in the prior art that, for occasional communication anomalies, the root cause of the problem product cannot be determined due to the lack of log information during communication, and provides a method for locating abnormal data of a communication module.

[0005] The above technical problems of the present invention are mainly solved by the following technical solutions: A method for locating abnormal data of a communication module comprises the following steps: S1. The master station first establishes a connection with the module, and then establishes a connection with the smart meter. If a connection abnormality occurs, the type of the connection abnormality is determined. For occasional communication abnormalities, a log saving function will be triggered after exceeding a threshold. The threshold includes a time threshold, an event number threshold, and a retry number threshold. S2. The master station sends a command to open the communication abnormality log saving function, and the module responds to the master station; S3. The master station sends a command to turn on the communication full log saving function. The module responds to the master station and saves all logs in real time. S4, the master station sends a command to turn on the subsystem log saving function, the module responds to the master station and saves the subsystem log in real time; S5. The module establishes a short connection with the event server. If the short connection is successfully established, the module pushes the event to the event server and closes the short connection after confirmation.

[0006] As a preferred solution, after the module communication returns to normal, the module will automatically turn off the log saving function, and the module will also automatically push the log to the server.

[0007] As a preferred solution, in step S1, if the communication anomaly occurs randomly, the master station can enable the log saving function of the module through the remote channel.

[0008] As a preferred solution, if the module communication returns to normal, the module does not record the abnormal log.

[0009] As a preferred solution, if the module communication continues to be abnormal, the module automatically records the abnormal log.

[0010] As a preferred solution, if the remote communication function is always abnormal, the module can be taken back to the laboratory and the log information at the time of the abnormality can be obtained through the serial port.

[0011] As a preferred solution, if the remote communication function is always abnormal, the log information of the abnormality can also be obtained locally through the serial port.

[0012] As a preferred solution, after any step is completed, the master station can obtain the log remotely.

[0013] As a preferred solution, the remote log acquisition method includes the following steps: The master station sends a command to upload the log to the server, and the server includes an http server and an ftp server; The module sends the currently saved logs to the specified server. The module can dynamically select a server for uploading according to the command.

[0014] As a preferred solution, in step S5, if the address of the event push is the same as the address of the master station, the following steps are performed: S5.1, the smart meter sends an event push request to the main station through the module; S5.2, the master station confirms the push event; S5.3, smart meter cyclically reads smart meter data; S5.4. After the data reading is completed, close the DLMS application layer connection.

[0015] Therefore, the advantages of the present invention are: 1. Automatic log saving: ensures that all key information is recorded during communication anomalies to avoid information loss and speed up problem location.

[0016] 2. Remote log acquisition: It is convenient to obtain data when there is no direct access to the device, which improves the flexibility and efficiency of fault analysis.

[0017] 3. Multiple acquisition methods: Provide multiple options for debuggers to adapt to different situations, reduce debugging time and improve work efficiency.

[0018] 4. Communication abnormality records: Provide detailed communication data to help in-depth analysis of abnormal causes and enhance the basis and accuracy of problem solving.

[0019] 5. The protocol adopts an automatic switching design to improve the reliability of log acquisition. It supports both FTP and HTTP protocols. It also provides more choices and compatibility in the customer's network architecture, and provides another option when one service is difficult to deploy. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0021] The technical solution of the present invention is further specifically described below through embodiments and in conjunction with the accompanying drawings.

[0022] Example: The remote communication module is the key bridge between the master station and the smart meter (such as a smart meter or other remote device). It is responsible for data collection, transmission and instruction issuance, and its stability and reliability directly affect the operating efficiency and accuracy of the entire system. Therefore, when an abnormality occurs in the communication module, it is crucial to quickly locate and solve the problem. After a communication abnormality occurs in the remote communication module, engineers need to reproduce the problem on site, capture log files and analyze them. For occasional and random problems, reproduction and positioning are very difficult. For random communication anomalies, because there is no log when the communication is abnormal, it is necessary to reproduce on site, capture logs and analyze them, which is difficult to locate and inefficient. When the communication is normal, because the log cannot be obtained remotely, it is impossible to assist in locating the abnormal communication problem between the master station and the smart meter.

[0023] The present invention provides a method for locating abnormal data of a communication module, comprising the following steps: S1. The master station first establishes a connection with the module, specifically a TCP connection or a udp connection, and then establishes a connection with the smart meter, specifically a DLMS connection or an IEC connection or a 698 connection. This step is the basis of the communication process. The TCP connection is a channel for data transmission, ensuring the reliable transmission of data packets. The DLMS protocol (Distribution Line Message Specification) defines the format and procedures for data exchange, ensuring effective communication between the master station and the smart meter. Establishing a TCP connection requires the module to have stable network access capabilities, whether through a wired network or a wireless network. Once the TCP connection is successfully established, the master station can send instructions to the module through the connection, and then establish a DLMS connection with the smart meter. The establishment of a DLMS connection requires the module to correctly parse and execute the instructions of the master station, and the smart meter also needs to correctly respond to the module's request.

[0024] Regarding the judgment of abnormalities, after the module is started, the cyclic status monitoring will be started. If an abnormality is detected, it will be judged whether it exceeds the time threshold, event number threshold, or TCP connection number threshold. If it exceeds the threshold, log recording will begin. If the abnormality is detected and recovered, the log saving will be closed, and the main station will be notified through events or the log will be uploaded.

[0025] If a TCP connection exception occurs, determine the type of connection exception. TCP connection exceptions may be caused by a variety of reasons, such as network interruption, module hardware failure, software error, etc. Determining the type of exception is the key to locating the problem. The type of exception can be preliminarily determined by analyzing the network status when the exception occurs, the module operation log, and the error information of the master station.

[0026] For occasional communication anomalies, the log saving function will be triggered after exceeding the threshold. The thresholds include time threshold, event number threshold and retry number threshold. After the duration of the anomaly exceeds the threshold, the module will automatically start the log saving function. After the module is online, the log will be automatically closed. The empirical value is 1 hour. If the number of offline times exceeds the threshold, the log saving function will also be triggered, otherwise the log will be automatically closed. The empirical value is 6 times. If the number of retries, that is, the number of TCP connection retries, exceeds the threshold, the log saving function will also be triggered. After the module is online, the log will be automatically closed. The empirical value is 30 times. Occasional anomalies are usually difficult to reproduce, so it is particularly important to record the log information when the anomaly occurs. Setting the threshold is to avoid frequently recording insignificant short-term anomalies and only focus on those continuous anomalies that may affect system operation. The setting of the threshold needs to be adjusted according to the actual situation. A too short threshold may cause too much irrelevant information to be recorded, and a too long threshold may miss important anomaly records.

[0027] If the communication anomaly occurs randomly, the master station can turn on the module's log saving function through the remote channel. Random anomalies are more difficult to predict and capture, so a mechanism to actively trigger log recording is required. The remote channel can be a TCP / IP-based network connection or a control instruction based on SMS or other communication methods. The master station sends an instruction to turn on the log saving function to the module through the remote channel. After receiving the instruction, the module starts to record the log and stores the log data locally or uploads it to a specified server. This method can capture random anomaly information in a timely manner and provide a basis for subsequent analysis.

[0028] If the module communication returns to normal, the module does not record the abnormal log. If the module communication continues to be abnormal, the module automatically records the abnormal log. This is an intelligent logging strategy. If the communication abnormality is only temporary and returns to normal quickly, there is no need to record the log to avoid generating a lot of useless information. However, if the communication is continuously abnormal, it is necessary to record the log for subsequent analysis. This strategy can effectively reduce the log storage space and improve the efficiency of log analysis.

[0029] If the remote communication function is always abnormal, you can retrieve the module back to the laboratory and obtain the log information when the abnormality occurs through the serial port. You can also obtain the log information when the abnormality occurs locally through the serial port. Serial communication usually has higher reliability and stability, which can ensure the integrity and accuracy of the data.

[0030] After the module communication returns to normal, the module will automatically turn off the log saving function, and the module will automatically push the log to the server. This function can ensure the normal operation of the module and avoid affecting the performance of the module due to excessive log records.

[0031] S2. The master station sends a command to turn on the communication abnormality log saving function, and the module responds to the master station. If the module communication is normal, no log is recorded. If the module communication is abnormal, the abnormal log is recorded. That is, the master station sends a specific command to the remote communication module to turn on the communication abnormality log saving function. When the module receives this command, it will respond and confirm, and start the internal communication status monitoring mechanism. It is worth noting that this method adopts an efficient logging strategy: when the communication is normal, the module will not log, thereby avoiding unnecessary storage space occupation and system resource consumption. Only when the module detects a communication abnormality will the logging function be triggered to record key data such as the time, type, and related data packet information of the abnormality in detail.

[0032] This event-triggered logging method ensures the integrity and accuracy of key information while avoiding interference from irrelevant logs. By analyzing these exception logs, engineers can quickly understand the specific circumstances when the exception occurred, thereby quickly locating the root cause of the problem. More importantly, since the exception log is stored inside the module, even randomly occurring communication exceptions can be effectively recorded, providing valuable clues for subsequent fault analysis.

[0033] In addition, this step of the present invention also takes into account the need to remotely obtain logs when communication is normal. Through preset instructions and protocols, the master station can remotely request the communication module to upload log information when necessary, thereby assisting in locating communication problems between the master station and the smart meter. This remote log acquisition function greatly improves the efficiency of troubleshooting and reduces the need for engineers to operate on site.

[0034] S3. The master station sends a command to turn on the communication full log saving function. The module responds to the master station, the communication full log saving function is turned on, and all logs are saved in real time.

[0035] S4. The master station sends a command to turn on the subsystem log saving function. The module responds to the master station that the subsystem log saving function has been turned on and saves the subsystem log in real time.

[0036] Turn on the communication full log saving function and the subsystem log saving function. The significance of this measure is to change the log capture from passive to active, from offline to online. The communication full log saving function means that the module will record all communication-related events, including the sending and receiving of data packets, changes in connection status, etc. The subsystem log saving function focuses on recording the operating status and events within the subsystem. Through these logs, engineers can have a more comprehensive understanding of the operation of the equipment and locate the problem more accurately.

[0037] After the log saving function is turned on, the module will save all logs in real time, which means that no matter whether the communication is abnormal or not, the log will be recorded. This provides engineers with valuable historical data. Even if the abnormality occurs randomly, clues can be found by analyzing the log afterwards. At the same time, real-time log saving also improves the efficiency of troubleshooting. Engineers no longer need to wait for the abnormality to recur, but can directly analyze the log data.

[0038] S5. The module and the event server establish a short connection and try multiple times. A short connection means that the connection will be closed after each data exchange. This method is conducive to reducing the long-term occupation of server resources, especially for scenarios where the data transmission frequency is not fixed or the data volume is small. The process of establishing a short connection involves the handshake protocol at the network level to ensure that the communication link between the module and the server can be established correctly. If the short connection is successfully established, the module pushes the event to the event server. These data are pre-processed by the module, packaged into a specific format, and sent to the event server through the established short connection. After confirmation, the short connection is closed to release the occupied network resources.

[0039] However, the complexity of the network environment determines that the connection establishment process is not always smooth. There may be problems such as network fluctuations and temporary unreachable servers, which may lead to the failure of short connection establishment. If the short connection establishment fails, the connection establishment will continue after a delay. This strategy usually includes setting the maximum number of attempts and the time interval between each attempt (i.e., delay). The purpose of the delay is to avoid excessive connection requests when the network is unstable, which increases the network burden, and also provides a certain buffer time for network recovery.

[0040] Through this mechanism based on short connections and multiple retries, the module can effectively push event data to the event server, while ensuring the rational use of network resources and the stability of the system. This design fully considers various problems that may arise in network communication and provides corresponding response strategies, reflecting the robustness and reliability of the system design.

[0041] In actual applications, in order to further optimize performance, you can also consider introducing connection pools, dynamically adjusting delay time, optimizing data packet formats, and other strategies. These optimization measures can further improve data transmission efficiency, reduce network latency, and enhance the performance of the entire system and user experience.

[0042] Step S5 is the core link of smart meter event push, which is directly related to the immediacy and accuracy of data. In step S5, if the address of event push is the same as the address of the main station, the following steps are performed: S5.1, the smart meter sends an event push request to the master station through the module. In the first step, the smart meter plays the role of the active party. It first initiates a communication request to inform the master station that there is new data to be sent. This request contains key information, such as event type, occurrence time, and related data, to ensure that the master station can quickly locate and process after receiving the request.

[0043] S5.2. The master station confirms the push event. The master station system verifies the received data to confirm its integrity and correctness to avoid information loss or misunderstanding caused by errors that may occur during data transmission. The push event confirmation is pushed to the module. This move is a manifestation of two-way communication, which ensures the reliability and immediacy of information transmission. The module then pushes the push event confirmation back to the smart meter. After receiving the feedback, the smart meter knows that the data has been received and confirmed by the master station.

[0044] S5.3. After receiving the confirmation information, the smart meter cyclically reads the smart meter data. This involves the smart meter periodically reading the data of the physical meter to ensure the real-time and continuity of the data. During the reading process, the smart meter will collect data according to the predetermined reading strategy, at a fixed time or according to the trigger event, to ensure that the data update frequency meets the system requirements.

[0045] S5.4. After reading the data, close the DLMS application layer connection. DLMS is a standard protocol for meter reading systems, ensuring interoperability between devices from different manufacturers. Closing the connection not only saves resources, but also avoids potential safety hazards caused by long-term open connections.

[0046] After any step is completed, the master station can obtain the log remotely. This function is crucial for data analysis, troubleshooting and system optimization.

[0047] The remote method of obtaining logs includes the following steps: The main station sends a command to upload the log to the server, which includes an http (Hypertext Transfer Protocol) server and an ftp (File Transfer Protocol) server; after the smart meter communication module receives the command, the module sends the currently saved log to the specified server, and the module can dynamically select the server for upload according to the command. In this process, the module acts as a medium for data transmission, ensuring that the log data can be safely and accurately delivered to the target server. For uploads to the HTTP server, the smart meter communication module will use the HTTP protocol to package the log data into HTTP messages and upload them to the specified HTTP server. After receiving the data, the HTTP server will store it according to the preset rules and can be used for subsequent analysis and query. The adoption of the HTTP protocol ensures the wide compatibility and convenience of data transmission.

[0048] The present invention designs a multi-protocol support architecture, and the content of the log is independent of the transmission method. The log module can dynamically select HTTP or FTP to upload the log according to the instructions; it also supports automatic switching between HTTP and FTF protocols, that is, if one protocol operation fails, it automatically switches to another protocol to ensure that the log file can be uploaded normally.

[0049] For uploading to an FTP server, the FTP protocol is used for file transfer. FTP is a protocol specifically used for file transfer, which can efficiently and stably transfer large amounts of data. The smart meter communication module uses the FTP protocol to transfer log files to the FTP server for storage. The advantage of the FTP protocol is its efficient processing capability for large file transfers, which is suitable for scenarios where frequent file exchange is required.

[0050] Throughout the entire process, whether it is event push or log upload, the security and integrity of the data are fully guaranteed. The close collaboration between the smart meter and the master station ensures that every link from data generation, transmission to storage can be carried out accurately. This efficient and secure data interaction mechanism is the basis for the stable operation of the smart grid, and also provides solid data support for subsequent data analysis and system optimization.

[0051] In summary, the innovations of the present invention are mainly reflected in the following aspects: 1. Automatic log saving: Traditional communication systems often lack intelligent responses to abnormal situations, and log records often rely on manual triggering or pre-settings. This results in the failure to save key log information in a timely manner when sudden communication anomalies occur, which greatly increases the difficulty of problem diagnosis. In response to this pain point, the present invention introduces an automatic log saving mechanism. The system can monitor the status of the communication link in real time, and once a communication anomaly is detected and persists for a certain period of time, the log saving function will be automatically started.

[0052] 2. Remote log acquisition: In actual application scenarios, devices are often deployed in remote areas or places that are difficult to reach, and on-site debugging personnel cannot arrive at the site in time to troubleshoot. In order to solve this problem, the present invention provides a diversified remote log acquisition method, supporting multiple mainstream network protocols such as FTP and HTTP.

[0053] Through the FTP server, users can download log files stored on the device safely and conveniently. The maturity and wide application of the FTP protocol ensure the stability and reliability of remote log acquisition. HTTP (Hypertext Transfer Protocol) support: Through the HTTP server, users can directly access and download log files through the browser, which is more convenient and quick. The ease of use of the HTTP protocol lowers the user's threshold for use, allowing non-professionals to easily obtain logs.

[0054] 3. Multiple acquisition methods: In addition to remote log acquisition, the present invention also provides a local serial port method, which provides debuggers with more flexible choices. The advantages of the local serial port method are: it is suitable for on-site debugging. At the equipment site, debuggers can directly obtain logs through the serial port connection, which is convenient for real-time debugging and analysis. It is suitable for network failures. When there is a problem with the network connection, remote log acquisition may not be possible. At this time, the local serial port method can be used as a reliable alternative. Suitable for low-level debugging, the local serial port method can obtain lower-level communication data, which is convenient for in-depth fault analysis and debugging. By combining remote and local serial port methods, the present invention provides debuggers with a variety of log acquisition methods. They can choose the most appropriate solution according to actual conditions, thereby improving debugging efficiency.

[0055] 4. Communication abnormality record: For abnormalities between the smart meter and the main station, detailed communication data is recorded to provide a basis for in-depth analysis. In the industrial automation system, the communication between the smart meter and the main station is the core link of data acquisition and control. Once the communication is abnormal, it will directly affect the normal operation of the entire system. The present invention has carried out a special optimization design for the communication abnormalities between the smart meter and the main station, which can record detailed communication data and provide a solid foundation for in-depth analysis.

[0056] Specifically, the system can record: Communication timestamp, which accurately records the time when the communication event occurs, so as to facilitate the analysis of the timing relationship of the exception. Data packet content, which completely records the content of the communication data packet, including the format of the data frame, the value of the data field, etc., so as to facilitate the analysis of the correctness of data transmission. Error code, which records the error code generated during the communication process, so as to facilitate the rapid location of the cause of the error. Status information, which records the current status information of the smart meter and the main station, so as to facilitate the analysis of the context in which the exception occurs. By recording detailed communication data, the present invention can provide rich information for in-depth analysis, help debuggers quickly locate the root cause of the problem, and take appropriate measures to repair it.

[0057] The specific embodiments described herein are merely examples of the spirit of the present invention. Those skilled in the art may make various modifications or additions to the specific embodiments described or replace them in similar ways, but they will not deviate from the spirit of the present invention or exceed the scope defined by the appended claims.

Claims

1. A method for locating abnormal data of a communication module, characterized in that: The following steps are involved: S1. The master station first establishes a connection with the module, and then establishes a connection with the smart meter. If a connection abnormality occurs, the type of the connection abnormality is determined. For occasional communication abnormalities, a log saving function will be triggered after exceeding a threshold. The threshold includes a time threshold, an event number threshold, and a retry number threshold. S2. The master station sends a command to open the communication abnormality log saving function, and the module responds to the master station; S3. The master station sends a command to turn on the communication full log saving function. The module responds to the master station and saves all logs in real time. S4, the master station sends a command to turn on the subsystem log saving function, the module responds to the master station and saves the subsystem log in real time; S5. The module establishes a short connection with the event server. If the short connection is successfully established, the module pushes the event to the event server and closes the short connection after confirmation.

2. A method for locating abnormal data of a communication module according to claim 1, characterized in that: After the module communication returns to normal, the module will automatically turn off the log saving function, and the module will also automatically push the log to the server.

3. A method for locating abnormal data of a communication module according to claim 1, characterized in that: In step S1, if the communication anomaly occurs randomly, the master station can turn on the log saving function of the module through the remote channel.

4. A method for locating abnormal data of a communication module according to claim 3, characterized in that: If the module communication returns to normal, the module will not record the abnormal log.

5. A method for locating abnormal data of a communication module according to claim 3, characterized in that: If the module communication continues to be abnormal, the module will automatically record the abnormal log.

6. A method for locating abnormal data of a communication module according to claim 3, characterized in that: If the remote communication function is always abnormal, you can take the module back to the laboratory and obtain the log information of the abnormality through the serial port.

7. A method for locating abnormal data of a communication module according to claim 3 or 6, characterized in that: If the remote communication function is always abnormal, you can also obtain the log information of the abnormality locally through the serial port.

8. A method for locating abnormal data of a communication module according to claim 1, characterized in that: After any step is completed, the master station can obtain the log remotely.

9. A method for locating abnormal data of a communication module according to claim 8, characterized in that: The remote method of obtaining logs includes the following steps: The master station sends a command to upload the log to the server, and the server includes an http server and an ftp server; The module sends the currently saved logs to the specified server. The module can dynamically select a server for uploading according to the command.

10. A method for locating abnormal data of a communication module according to claim 1, characterized in that: In step S5, if the address of the event push is the same as the address of the master station, the following steps are performed: S5.1, the smart meter sends an event push request to the main station through the module; S5.2, the master station confirms the push event; S5.3, smart meter cyclically reads smart meter data; S5.

4. After the data reading is completed, close the DLMS application layer connection.

Images