Communication data real-time monitoring method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of communication, in particular to a communication data real-time monitoring method and device, electronic equipment and a computer storage medium, and the method comprises the steps: receiving an original data stream of to-be-debugged equipment transmitted by a communication adaption module, recognizing the original data stream according to a protocol description file which is customized by a user and imported in advance, and transmitting the recognized original data stream to a communication adaption module; and determining a corresponding complete data frame, analyzing and checking the complete data frame to obtain structured data, and associatively storing the structured data and the original data stream. The problems that a universal serial port debugging assistant is low in efficiency and prone to making mistakes, a logic analyzer and the like are high in cost and poor in flexibility, a self-compiled temporary debugging program is long in development period and poor in reusability are solved, and the requirement for real-time monitoring of communication data in program development and debugging in the fields of an embedded system and the like can be effectively met.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, electronic device and storage medium for real-time monitoring of communication data. Background Technology

[0002] In the development and debugging of programs in embedded systems, IoT devices, and industrial control, data interaction between devices and host computers (such as PCs), or between devices themselves, is a core element ensuring the normal operation of the system. This data interaction requires specific communication protocols, such as UART, I2C, MODBUS, and custom binary protocols. However, current debugging methods have many drawbacks and are difficult to meet actual needs. Specifically: 1) General serial port debugging assistants are one of the most commonly used tools for developers, but these tools are limited in function, only able to display the transmitted and received data streams in hexadecimal, decimal, or text format. This means that developers must manually refer to the protocol document and parse the meaning of the data byte by byte during debugging, which is not only extremely inefficient, but also prone to errors due to human negligence when processing large amounts of data, seriously affecting development progress and debugging quality. 2) Logic analyzers or professional protocol analyzers are also debugging tools available to developers. While they can capture signals and parse certain standard protocols, they are expensive, making them too costly for many development teams and increasing project development costs. Furthermore, they typically cannot directly parse developer-defined non-standard protocols, and even if they can, complex script configurations are required, making operation cumbersome, inflexible, and unable to meet the demands of rapid and ever-changing development. 3) Writing temporary debugging programs: Developers write simple parsing programs for specific projects. While highly targeted, this method has a long development cycle, poor reusability, and wastes human resources. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies, this invention provides a method, device, electronic device, and storage medium for real-time monitoring of communication data, which meets practical development needs by automatically parsing data and flexibly supporting custom protocol methods.

[0004] A first aspect of this application provides a method for real-time monitoring of communication data, the method comprising: A second aspect of this application provides a real-time monitoring device for communication data, the device comprising: A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the real-time monitoring method for communication data.

[0005] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described real-time monitoring method for communication data.

[0006] In summary, the real-time monitoring method, apparatus, electronic device, and computer storage medium for communication data provided in this application have at least one of the following beneficial effects: 1. After receiving the raw data stream from the device to be debugged transmitted by the communication adapter module, the system identifies the raw data stream according to the user-defined and pre-imported protocol description file, determines the corresponding complete data frame, and then parses and verifies the complete data frame to obtain structured data. This achieves automatic data parsing, eliminating the need for developers to manually parse the protocol document byte by byte, greatly improving debugging efficiency, reducing errors caused by human negligence, and ensuring development progress and debugging quality.

[0007] 2. The protocol description file is user-defined and pre-imported, meaning it can be flexibly configured for various custom non-standard protocols without complex script configurations. Developers can customize the protocol description file according to actual project needs, thereby enabling the parsing of different protocol data, meeting rapid and ever-changing development requirements, and avoiding the cost of purchasing expensive professional equipment.

[0008] 3. By importing user-defined protocol description files, different protocol data can be parsed, rather than writing temporary parsing programs for each specific project. This has high reusability. Once developed, it can be used directly for projects using the same or similar protocols, greatly shortening the development cycle and saving human resources. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a real-time monitoring method for communication data according to an embodiment of this application; Figure 2 This is another flowchart illustrating a real-time monitoring method for communication data, as shown in an embodiment of this application. Figure 3 This is a functional block diagram of a real-time monitoring device for communication data, as shown in an embodiment of this application. Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0010] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0011] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0012] Reference Figure 1 and Figure 2 The diagram shown is a flowchart illustrating a real-time monitoring method for communication data according to an embodiment of this application. The real-time monitoring method for communication data includes the following steps.

[0013] S11, Receive the raw data stream of the device to be debugged transmitted by the communication adapter module.

[0014] The raw data stream is generated by the debugging equipment and transmitted to the electronic equipment via the communication adapter module.

[0015] In some embodiments, the communication adapter module integrates multiple physical communication interfaces, each equipped with a corresponding interface chip. The interface chip detects and calculates the duration of each bit and automatically matches the communication frequency to achieve stable data transmission between different physical communication interfaces and the external device under test. These multiple physical communication interfaces may include, but are not limited to: USB to TTL, USB to RS-232, USB to RS-485, USB to I2C, USB to SPI, USB to wireless dongle, etc. When receiving raw data streams (e.g., binary data, hexadecimal data) from the device under test via the physical communication interface provided by the communication adapter module, the module compares these raw data streams with a custom protocol description file. Based on the comparison result, it automatically selects the appropriate communication protocol, achieving compatibility with different communication protocols. This greatly simplifies the process for developers, eliminating the need for tedious manual switching settings and enabling the handling of various protocol scenarios. Furthermore, the communication adapter module also supports manually changing the adapted communication protocol via electronic devices to meet diverse communication needs. The protocol-adapted data is then transmitted to the electronic device or other designated receiving device through the corresponding physical communication interface according to the selected communication protocol, ensuring accurate and timely data transmission. Because the communication adapter module integrates multiple interfaces, it can reduce the number of device ports, making the device more compact and saving space and cost. At the same time, unified interface management avoids abuse such as interface conflicts caused by indiscriminate use of multiple ports, ensuring stable and orderly communication and improving the reliability and efficiency of the entire debugging system.

[0016] In some embodiments, the electronic device may provide a configuration interface for the communication adapter module. The interface includes an interface selection drop-down menu, from which the user can select the communication interface to be configured, such as "USB to RS-232". When the "USB to RS-232" interface is selected, the configuration interface displays parameter setting options related to that interface, such as baud rate, data bits, stop bits, and parity. The user can set these parameters according to actual needs, for example, setting the baud rate to 9600, the data bits to 8, the stop bits to 1, and the parity to no parity. If the "USB to I2C" interface is selected, the configuration interface displays parameter setting options such as the I2C slave address and clock frequency. The user can set the I2C slave address to 0x50 and the clock frequency to 100kHz.

[0017] When an electronic device receives a raw data stream, it does not know what the raw data stream specifically describes. The electronic device then parses the raw data stream using a protocol description file imported by the user.

[0018] S12, Identify the original data stream according to the protocol description file and determine the complete data frame corresponding to the original data stream.

[0019] The protocol description file is user-defined and pre-imported.

[0020] In some embodiments, the configuration interface also includes options related to "protocol description files." If the user already has a predefined protocol description file (which defines the verification method of the communication protocol and the flag information corresponding to each bit), they can click the "Import Protocol File" button and select the appropriate file to import. If no existing protocol description file exists, the user can click the "Create Protocol File" button and follow the wizard in the pop-up window to create a new protocol description file step by step. For example, the user can define the protocol name as "Custom_Protocol," select the verification method as CRC-16, and set the flag information corresponding to each bit position. Specifically, the electronic device provides a graphical user interface or script interface that allows users to import predefined protocol description files or create new protocol description files through the graphical interface or script. The communication protocol of each device to be debugged is different, including but not limited to the verification method and the flag information corresponding to each bit. For example, regarding the verification method, a specific flag bit in a BIT might correspond to: bit 1 for power-on, bit 2 for device alarm, bit 3 for device fault alarm, bit 4 for device lifespan expiration, and so on. Existing technology converts these bits into binary upon receipt and then compares them one by one, which is time-consuming and error-prone. Therefore, this application imports a protocol description file to determine what information each bit represents, allowing direct parsing of the BIT bits upon receiving data.

[0021] Generally, during new product development, users (i.e., developers) determine the fixed communication protocol for the new product and match the corresponding protocol from the protocol document based on the communication protocol type. For example, if the communication types are the same, the new product's communication protocol can be compatible with the old product's communication protocol. Developers can add new communication protocols based on the old product's communication protocols and the new product's functionalities. To save development time and improve efficiency, the new product's communication protocol can include both the old product's communication protocol and the communication protocols corresponding to the new product's functionalities. Then, the new product's communication protocol can be added to the protocol description file. When developing other new products, their corresponding communication protocols are accumulated in the protocol description file for easy creation and retrieval later.

[0022] In this embodiment, the protocol description file can be defined using a structured language (such as JSON, XML, or YAML) or by filling in a form, and its content may include, but is not limited to: Global protocol attributes: used to define the protocol name, byte order (big-endian / little-endian), and default checksum algorithm (such as CRC16, Sum8).

[0023] Frame structure: Used to define the components of a data frame, such as frame header (fixed value or pattern), data field length (fixed length or indicated by a field), command field, data payload, checksum field, frame trailer, etc.

[0024] Field level: Used to define each field in the frame structure, including field name, data type (such as uint8, int16, float, string), byte offset, bit field definition, parsing format (such as enumeration, unit, scaling factor), etc.

[0025] Command-response mapping: Used to define the correspondence between request command words and expected response command words, and to monitor request-response pairing.

[0026] Upon receiving the raw data stream, since the raw data stream itself is a series of bytes without a clear structure, in order to achieve full lifecycle monitoring of the data, it is necessary to identify the raw data stream according to the currently active protocol description file and determine the complete data frame corresponding to the raw data stream.

[0027] In an optional implementation, identifying the original data stream according to the protocol description file and determining the complete data frame corresponding to the original data stream includes: A sliding window is set in the raw data stream according to the frame header information in the protocol description file; the size of the sliding window is at least enough to accommodate the frame header information. A window is slid across the raw data stream according to a preset step size. After each slide, the data in the window is compared with the frame header information. When the data within the window matches the frame header information, the matching position is determined as the potential frame start position; Determine whether the protocol description file contains frame tail information; When it is determined that the protocol description file contains frame tail information, the complete data frame is determined based on the potential frame start position and the frame tail information; When it is determined that the protocol description file does not contain frame tail information, the actual data frame length is calculated based on the potential frame start position. In the original data stream, determine the data segment corresponding to the actual data frame length, and determine the complete data frame based on the data segment.

[0028] In some embodiments, each communication protocol typically includes a frame header, and some may also include a frame trailer and checksum. The protocol description file, as the configuration carrier of the communication protocol, records detailed parameter information of the communication protocol currently under testing. By reading and parsing this protocol description file, the electronic device can accurately obtain the frame header feature information of the communication protocol corresponding to the currently tested device. Based on this frame header information, the start position of the protocol data can be quickly located in the received raw data stream. Regarding the frame length setting of the communication protocol, in most communication protocols, a specific number of bits after the fixed hardware position of the frame header are specifically designated as the frame length indicator field. The protocol description file provides detailed and precise configuration of this frame length setting rule for different communication protocols. When the electronic device successfully identifies the frame header in the raw data stream, it can accurately determine the length of the entire data packet by parsing and calculating the values ​​of the specific bits after the frame header according to the preset frame length setting rules in the protocol description file. This allows for the identification and extraction of the complete data frame.

[0029] Specifically, based on the frame header information (e.g., "0xAA 0xBB") in the protocol description file, a sliding window is set in the raw data stream, with a window size that at least accommodates the frame header information. For example, the "0xAA 0xBB" frame header information occupies 2 bytes, so the sliding window size is set to at least 2 bytes to ensure that the frame header information can be fully accommodated. Next, the window slides across the raw data stream according to a preset step size (e.g., 1 byte). After each slide, the data within the window is compared with the frame header information "0xAA 0xBB". For example, initially, the window is located at the beginning of the raw data stream. If the data within the window is not "0xAA 0xBB", the window slides forward 1 byte and the comparison is repeated; if the data within the window matches "0xAA 0xBB", the matching position is determined as the potential frame start position. For example, in the raw data stream, when the sliding window slides to the 5th and 6th bytes, and finds that the values ​​of these two bytes are "0xAA" and "0xBB" respectively, then the position of the 5th byte is determined as the potential frame start position. Next, examine the protocol description file to determine if it contains end-of-frame information. If end-of-frame information (e.g., "0xCC 0xDD") is found, continue searching for "0xCC 0xDD" in the original data stream, starting from the potential frame start position. When the end-of-frame information is found, the data segment between the potential frame start position and the end-of-frame information is considered a complete data frame. For example, if the search starts from the potential frame start position (byte 5) and "0xCC 0xDD" is found at bytes 20 and 21, then the data segment between bytes 5 and 21 is a complete data frame.

[0030] Alternatively, if the protocol description file lacks a frame end information, the data frame length defined / specified in the protocol description file is determined. If the protocol description file specifies a data frame length of 10 bytes, it means the effective data portion is 10 bytes long. According to the protocol, the total data frame length is the frame header length (2 bytes) plus the effective data length (10 bytes), meaning the actual data frame length is 12 bytes. Therefore, starting from the potential frame start position (let's say the 5th byte), a 12-byte data segment is extracted and identified as the complete data frame. For example, starting from the 5th byte, the data segment from the 5th to the 17th byte is the complete data frame identified according to the protocol description file.

[0031] To facilitate understanding of the inventive concept of this application, the following provides a basic format of data in a data packet as shown in Table 1 below. For example, total frame length = frame header + length of frame length description + checksum + true tail.

[0032] Table 1:

[0033] S13, the complete data frame is parsed and verified to obtain structured data.

[0034] Once a complete data frame is identified, it is essentially still a string of binary data. The order, data type, and meaning of its various fields can only be determined according to specific protocol rules. Different communication scenarios employ different protocols. To ensure accurate transmission, processing, and use of data between different devices or systems, the complete data frame needs to be parsed and verified according to the corresponding protocol description file. Through parsing and verification, the binary data frame can be transformed into data with a clear structure and meaning—structured data—facilitating subsequent storage, analysis, and display operations.

[0035] In an optional implementation, parsing and verifying the complete data frame to obtain structured data includes: The complete data frame is parsed field by field according to the protocol description file, and the word order is converted to obtain a set of data fields; Each data field in the data field set is validated according to the default validation algorithm defined in the protocol description file; When it is determined that each data field in the data field set has been verified correctly, the actual verification value of the data field set is calculated. Compare the actual verification value with the preset verification value; When it is determined that the actual verification value is consistent with the preset verification value, the actual data frame length is verified according to the data frame length defined in the protocol description file. When it is determined that the actual data frame length is consistent with the data frame length defined in the protocol description file, each data field in the data field set is organized into the structured data.

[0036] In some embodiments, the electronic device protocol description file parses the complete data frame field by field. The protocol description file defines in detail the start position, length, and data type of each field in the data frame. According to these definitions, the raw binary data of each field is extracted from the data frame. Simultaneously, considering that different devices or systems may use different byte orders (such as big-endian and little-endian), the extracted raw binary data is converted to a unified byte order form that meets the requirements of subsequent processing, ultimately resulting in a set of data fields. Next, each data field in the data field set is verified according to the default verification algorithm defined in the protocol description file. Different protocols may use different verification algorithms, commonly including parity check and CRC check. For each data field, its check value is calculated according to the corresponding verification algorithm and compared with the correct check value specified in the protocol. If the calculated check value matches the specified value, the data field is considered correctly verified; otherwise, it indicates that an error may have occurred in the data field during transmission or processing. Once it is confirmed that each data field in the data field set has been validated correctly, the actual checksum of the entire data field set is calculated according to the default checksum algorithm specified in the protocol description file. This default checksum algorithm may be the result of performing some mathematical operation (such as summation, XOR, etc.) on all data fields. The calculated actual checksum is compared with a preset checksum, which is usually calculated at the data sending end using the same algorithm and sent along with the data. If the actual checksum matches the preset checksum, it indicates that no overall error occurred during data transmission; if they do not match, it indicates that the data may contain errors and requires further investigation. When the actual checksum matches the preset checksum, the actual data frame length is checked according to the data frame length defined in the protocol description file. The protocol description file explicitly specifies the length that a complete data frame should have, and the actual received data frame length is compared with this specified length. If the actual data frame length matches the data frame length defined in the protocol description file, it indicates that no data loss or extra data insertion occurred during data frame transmission; if they do not match, it indicates that the data frame may contain errors and requires further processing. When the actual data frame length is determined to be consistent with the data frame length defined in the protocol description file, each data field in the data field set is organized according to the format and structure specified in the protocol description file. For example, the fields are arranged in their logical order in the data frame, each field is given a corresponding name and meaning description, and the binary data is converted into values ​​with explicit data types (such as integers, floating-point numbers, strings, etc.), ultimately forming structured data.

[0037] For example, suppose the currently active protocol description file is a description file for a smart meter communication protocol D. This protocol specifies that data frames begin with a frame header "0x55 0x66" and end with a frame tail "0x77 0x88". The data frame contains multiple fields, such as meter number (4 bytes), electricity consumption (4 bytes), timestamp (6 bytes), etc., and specifies the default verification algorithm as CRC16. The protocol description file also specifies a fixed data frame length of 20 bytes. Then, according to the protocol description file, the complete data frame is parsed field by field. For example, starting from the frame header "0x55 0x66", each field is extracted sequentially according to the field order and length specified in the protocol. Assume the complete data frame is "0x55 0x66 0x01 0x02 0x03 0x04 0x12 0x34 0x56 0x78 0x90 0xAB 0xCD 0xEF 0x01 0x02 0x03 0x04 0x05 0x06 0x77 0x88". First, extract the meter number field, which occupies 4 bytes and has a value of "0x01 0x02 0x03 0x04"; next, extract the electricity consumption field, which also occupies 4 bytes and has a value of "0x12 0x34 0x56 0x78"; finally, extract the timestamp field, which occupies 6 bytes and has a value of "0x90 0xAB 0xCD 0xEF 0x01 0x02". Because different devices may use different byte orders (big-endian or little-endian), and the protocol specifies specific word order requirements, it is necessary to convert the word order of each extracted field according to the protocol description file to conform to the format specified by the protocol, thus obtaining a data field set. The meter number field is converted to decimal representation as "16909060", the electricity consumption field is converted to decimal representation as "305419896", and the timestamp field is converted to a readable time format according to the encoding method specified by the protocol. For the meter number field, its CRC16 checksum is calculated. If the calculation result matches the preset checksum in the protocol, it indicates that the meter number field has not encountered an error during transmission. The same checksum operation is performed on the electricity consumption field and the timestamp field in turn. Only when it is determined that each data field in the data field set has been checked correctly is the actual checksum of the entire data field set calculated. The CRC16 checksum algorithm is also used to calculate the actual checksum for the entire data field set (the combination of meter number, electricity consumption, timestamp, etc.). This actual checksum is then compared with the preset checksum (the checksum that the entire data frame should have as specified in the protocol). For example, if the calculated actual checksum is "0xA1B2", and the preset checksum is also "0xA1B2", it indicates that the entire data field set did not experience any overall error during transmission. When the actual checksum matches the preset checksum, the actual data frame length is checked according to the data frame length (20 bytes) defined in the protocol description file.The actual data frame length is obtained by calculating the number of bytes from the frame header to the frame tail. If the actual data frame length is 20 bytes, consistent with the data frame length defined in the protocol description file, it indicates that no data loss or redundant insertion occurred during transmission. Once the actual data frame length matches the data frame length defined in the protocol description file, each data field in the data field set is organized into structured data. For example, fields such as meter number, electricity consumption, and timestamp are organized according to a specific format to form a structured data record, such as "{meter number: 16909060, electricity consumption: 305419896, timestamp: [specific time]}". This structured data has clear field definitions and a fixed format, facilitating subsequent storage, querying, analysis, and processing. It provides accurate and useful information for smart meter monitoring systems, such as analyzing electricity consumption trends and detecting abnormal electricity usage.

[0038] By parsing and validating the complete data frame, the original binary data frame is transformed into structured data. Structured data has a clear organization and explicit semantics; each field has its specific meaning and value range, making the data easier to understand and process.

[0039] To facilitate understanding of the inventive concept of this application, an example of a structured data structure is provided below: { "headers": { "deviceName": "123", "productid": "1123", "uid": "22222" }, "messageType": "REPORT PROPERTY", "deviceld": "195422288", "'properties": { "rssi": -63, "snr": 7, "IMS!": "461650", "ICCID": "89866341", "CELLID": "61CB", "rsrp": -93, "pci": 202, "rsrg": -10, "outType": 5, "faultSta": 2, "alarmSta": 0, "gasValue": 0, "coValue": 0, "devSn": 12, }, "timestamp": 1765552 } S14, the structured data and the original data stream are associated and stored.

[0040] In some embodiments, to facilitate subsequent data querying, analysis, and tracing, it is necessary to establish an association between structured data and the corresponding raw data stream. Electronic devices can create an association table in the database, containing two main fields: one for storing a unique identifier for the structured data (such as the hash value or auto-incrementing ID of the structured data), and the other for storing the storage path or reference identifier of the corresponding raw data stream in the storage system. For example, when a piece of structured data is generated, its hash value is calculated as a unique identifier, and the received raw data stream is stored in the file system, with the file path recorded in the association table corresponding to the unique identifier of the structured data. Next, the organized structured data is stored in the database. Relational databases (such as MySQL) or non-relational databases (such as MongoDB) can be selected for storage. If a relational database is used, a corresponding table structure can be created based on the fields of the structured data, and the data can be inserted into the table; if a non-relational database is used, the structured data can be directly stored in the form of a document. For example, using a MongoDB database, JSON-formatted structured data can be inserted as a document into a collection named "sensor_data". The received raw data stream is then stored in the file system. To facilitate management and retrieval, files can be named and organized according to certain rules. For example, files can be named according to information such as reception time and device number, such as "20240101_100000_sensor1234.bin", and these files can be stored in a specific directory, such as " / data / binary_streams / ". Simultaneously, the storage path of the original data stream is recorded in the association table so that the corresponding original data stream can be quickly located later based on the structured data.

[0041] By associating and storing structured data and raw data streams, real-time monitoring of communication data is achieved, providing support for subsequent data analysis, fault diagnosis, and other tasks.

[0042] In an optional implementation, the method further includes: The time window for expected data frame transmission is determined according to a preset data transmission rule; the data transmission rule includes a periodic transmission rule or a transmission rule based on an external trigger signal; Determine whether the expected data frame to be sent is sent within the time window; When it is determined that the expected data frame was not sent within the time window, a missed transmission is identified, and the information of the missed data frame and the missed transmission time are recorded.

[0043] In some embodiments, to ensure the integrity and accuracy of communication data and promptly detect potential data loss during communication monitoring, electronic devices can introduce a missed data transmission detection mechanism based on preset data transmission rules. Specifically, during the initialization phase of the data transmission end (the device to be debugged in this embodiment), the user presets data transmission rules through a configuration interface or configuration file according to actual communication needs. Data transmission rules are of two types: periodic transmission rules, such as specifying that a specific data frame is sent every 500 milliseconds; and transmission rules based on external trigger signals, such as triggering the transmission of a corresponding data frame when a specific external signal (such as a sensor trigger signal, manual operation command, etc.) is received. According to the preset data transmission rules, a time window is determined for each expected data frame to be sent. For periodic transmission rules, the next expected transmission time is determined based on the period duration, using the current transmission time as a baseline. A reasonable time window range is then set based on this, for example, if the period is 500 milliseconds, the time window can be set from 20 milliseconds before the expected transmission time to 30 milliseconds after the expected transmission time. For transmission rules based on external trigger signals, a preset time window is immediately determined when an external trigger signal is received. The size of this window can be set according to the actual application scenario and communication protocol requirements, such as 100 milliseconds.

[0044] During the operation of the equipment under commissioning, the transmission of its data frames is monitored in real time. For each data frame expected to be transmitted, it is determined whether it was transmitted within a defined time window. The system makes this determination by comparing the actual transmission timestamp of the data frame with the start and end timestamps of the preset time window. For example, if a data frame expected to be transmitted at 10:00:00.500 (time window 10:00:00.480-10:00:00.530) has an actual transmission timestamp of 10:00:00.550, then it is determined that the data frame was not transmitted within the time window. When it is determined that an expected data frame was not transmitted within the time window, the system determines that there is a missed transmission and immediately records the information of the missed data frame (such as data frame type, data frame number, data content, etc.) and the time of the missed transmission (i.e., the actual time point when it was not transmitted within the time window). This recorded information can be stored in a system log file or a database for subsequent querying and analysis. For example, the record format can be set as "[Missed Record] Data Frame Type: Temperature Data Frame, Data Frame Number: 001, Data Content: Temperature Value 25.6, Missed Time: 2024-01-01 10:00:00.550".

[0045] By implementing the above-described optional methods, and determining the expected data frame transmission time window based on preset data transmission rules, and judging whether the data frame is transmitted within the time window, missed transmissions during communication can be detected in a timely and accurate manner. This helps ensure the integrity of communication data, avoids data loss or communication failures caused by missed transmissions, and improves the reliability and stability of the communication system. Simultaneously, recording the information of the missed data frames and the time of the missed transmission provides important data support for subsequent troubleshooting and system optimization, facilitating technical personnel to analyze the causes of missed transmissions and take targeted measures for improvement.

[0046] In an optional implementation, the method further includes: When a request frame is detected, the preset timeout time corresponding to the request frame is determined according to the command-response mapping relationship defined in the protocol description file, and the timer is started to begin counting. During the start of the timer, it continuously monitors whether a response frame corresponding to the request frame is received; When it is determined that a response frame corresponding to the request frame is received within the preset timeout period, the timer is stopped. When it is determined that no response frame corresponding to the request frame is received within the preset timeout period, it is determined that there is a response timeout or a missed reply, and the request frame information, the preset timeout period, and the time information of the time when the response frame corresponding to the request frame was not received are recorded.

[0047] In some embodiments, during real-time monitoring of communication data, in addition to monitoring the integrity of the data transmission, to ensure the efficiency and accuracy of communication interaction and to promptly detect situations where a response frame is not received after a request frame is sent, the electronic device also introduces a response monitoring mechanism based on a preset timeout. Specifically, during the initialization phase of the data receiving end (the host computer in this embodiment), a command-response mapping relationship is defined according to the protocol description file. The protocol description file details the response frame type and preset timeout for each request frame. For example, if the request frame type is "Read Device Status," its corresponding response frame type is "Device Status Report," and the preset timeout is 200 milliseconds. When a request frame is detected, the preset timeout for that request frame is determined according to the command-response mapping relationship defined in the protocol description file. Simultaneously, a timer is started and begins counting. The timer can be implemented using a software timer, and the timing duration can be set to the preset timeout by programming. For example, for the aforementioned "Read Device Status" request frame, the timer is started and the timing duration is set to 200 milliseconds. During the timer's counting process, the system continuously monitors whether the response frame corresponding to the request frame is received. The system determines whether a response frame is valid by comparing the type of the received data frame with the type of the response frame corresponding to the request frame. For example, if a data frame of type "Device Status Report" is received, it is determined that a response frame corresponding to the "Read Device Status" request frame has been received. When a response frame corresponding to the request frame is received within the preset timeout period, the system stops the timer and records that the communication interaction is completed normally. For example, if a "Device Status Report" response frame is received when the timer reaches 150 milliseconds, the timer stops, and "Read Device Status Request - Device Status Report Response, Interaction Normal" is recorded. When a response frame corresponding to the request frame is not received within the preset timeout period, the system determines that there is a response timeout or a missed reply. In this case, the system records the request frame information (such as request frame type, request frame number, request content, etc.), the preset timeout period, and the time information of the time when no response frame was received (i.e., the timer timeout period). This recorded information can be stored in the system log file or database for subsequent querying and analysis. For example, the record format can be set as "[Abnormal Record] Request Frame Type: Read Device Status, Request Frame Number: 002, Request Content: Read Device Operating Status, Preset Timeout: 200 milliseconds, No Response Received Time: 2024-01-01 10:00:00.200".

[0048] Through the aforementioned optional implementation methods, when a request frame is detected, a preset timeout period is determined according to the protocol description file, and a timer is started. During the timeout period, the reception of response frames is continuously monitored, enabling timely and accurate detection of response timeouts or missed replies during communication. This monitoring mechanism helps ensure the timeliness and accuracy of communication interactions, avoiding data inconsistencies or communication failures caused by untimely or missed responses, thus improving the reliability and stability of the communication system. Simultaneously, recording request frame information, the preset timeout period, and the time information of no received response frames provides crucial data support for subsequent troubleshooting and system optimization, facilitating technical personnel to analyze the causes of response anomalies and take targeted improvement measures.

[0049] In some embodiments, to provide a more intuitive understanding of communication data and enhance users' comprehension and analysis capabilities, electronic devices offer a data visualization and interactive interface. This interface presents the parsed data to users in a clear and easy-to-understand manner through various view formats, while also providing rich interactive functions to facilitate data querying, analysis, and troubleshooting. Specifically, a protocol view area is set up in the data visualization and interactive interface, displaying the parsed fields and their values ​​in a tree structure or table format. If a tree structure is used, the protocol hierarchy is used as the root node, expanding each field level by level. For example, for the communication protocol of a smart device, the root node is "Device Communication Protocol," and its next-level nodes are "Device Basic Information," "Measurement Data," "Control Commands," etc., and the next-level nodes are specific fields, such as "Device Number," "Temperature," "Humidity," "Device Status," etc. Each field node displays its corresponding value, such as "Temperature: 25.6℃" or "Device Status: Running." If a table format is used, a table containing columns such as field names and field values ​​is designed, and the parsed fields and their values ​​are sequentially filled into the table. The parsed structured data is then bound to the protocol view. In the system backend, structured data is passed to the front-end interface through a specific data interface. The front-end interface dynamically generates tree structures or tables based on the field information in the data. For example, when new structured data is received, the front-end interface creates corresponding nodes in the tree structure and populates the values ​​based on the field names and values ​​in the data, or adds new rows to the table and populates the data. The parsed fields and their values ​​are clearly displayed in a tree structure or table format, allowing users to intuitively understand the specific information contained in the communication data. Users do not need to parse complex binary data themselves, greatly improving data readability and comprehension efficiency, and facilitating users to quickly obtain the key information they need.

[0050] Simultaneously, a raw data view area is set up next to or below the protocol view, synchronously displaying the raw hexadecimal or ASCII code stream. For example, when the protocol view displays the parsed data, the raw data view simultaneously displays the corresponding raw data stream, such as "0xAA 0xBB 0x12 0x34..." or the corresponding ASCII characters. This linkage between the protocol view and the raw data view is implemented using front-end technologies such as JavaScript. When a user clicks on a field in the protocol view, the corresponding raw data location for that field is automatically located in the raw data view and highlighted. For example, if a user clicks on the "temperature" field in the protocol view, the corresponding binary code segment storing the temperature data in the raw data view will be highlighted, allowing the user to easily see the specific representation of that field in the raw data. The synchronous display of the raw hexadecimal or ASCII code stream, linked with the protocol view, enables users to understand the raw data format while viewing the parsed data. This helps users gain a deeper understanding of the data parsing process, troubleshoot potential problems, and improve the accuracy and reliability of data processing.

[0051] Furthermore, during real-time monitoring of communication data, data is organized and managed in units of "sessions." Based on the characteristics of the communication protocol, a request and its corresponding response are defined as a session. For example, in client-server communication, the request data sent by the client and the response data returned by the server constitute a complete session. The system identifies and distinguishes different sessions by analyzing the identification information (such as request number, response number, etc.) in the data frames. A session view area is set up in the data visualization and interactive interface, displaying sessions in chronological order in timeline or list format. Each session displays key information about the request and response, such as request time, response time, request content summary, and response content summary. For example, when displaying sessions in timeline format, the request and response time points of each session are marked on the timeline; clicking on a time point expands to view detailed request and response data. When displaying sessions in list format, each row in the list displays key information about one session; users can click on a row to view detailed content. The system displays a request and its corresponding response in terms of "sessions," which helps users analyze the communication interaction logic, quickly locate problems that occur during the communication process, such as requests not being responded to or responses being incorrect, improves troubleshooting efficiency, and optimizes the communication process.

[0052] Simultaneously, anomaly detection rules can be set in the system backend. Based on communication protocol requirements and actual application scenarios, various anomalies can be defined, such as verification errors (data verification fails), timeouts (requests do not receive a response within a certain time), and missed transmissions (expected data frames are not received). For example, for communication protocols using CRC16 checksums, when the calculated checksum value is inconsistent with the preset checksum value, it is determined to be a verification error. The system monitors communication data in real time, and immediately triggers an alarm mechanism when an anomaly is detected. Alarm methods include list display, pop-up notifications, and audible alarms. An anomaly alarm list area can be set in the data visualization and interactive interface to display detected anomaly information in real time, including anomaly type, occurrence time, and abnormal device; simultaneously, a pop-up notification will appear to alert the user of the anomaly, and a specific sound will be played to remind the user. At the same time, anomaly information is recorded in a log file for subsequent querying and analysis. For example, when a verification error is detected, the error alarm list displays "Verification error, Device No.: 1234, Time: 2024-01-01 10:00:00", a pop-up window prompts "Device 1234 data verification error", and an alarm sound is played. Simultaneously, the error information is logged to the log file "error_log.txt". Real-time reporting of various detected anomalies in list, pop-up, or sound format promptly alerts users to problems during communication, enabling them to take swift action to prevent escalation and ensure the stable operation of the communication system. Logging the error information provides crucial data support for subsequent problem analysis and system optimization.

[0053] Meanwhile, set up a data recording module in the system background to support recording the data before and after parsing into files. For the original data stream before parsing, store it as a binary file at certain time intervals or based on the data volume. The file name can contain information such as the timestamp, device number, etc., like "20240101_100000_device1234_raw.bin"; for the structured data after parsing, store it as a file in JSON or XML format, such as "20240101_100000_device1234_structured.json". At the same time, record the relevant information of the data record in the database, such as the file path, recording time, etc., for convenient subsequent query and management. Set up an entrance for the data playback function in the data visualization and interaction interface, and users can import the playback data by selecting the recorded file. The system analyzes the data in the imported file according to the file type and redisplay it in each view (protocol view, original data view, session view, etc.) in chronological order to simulate the communication scenario at that time. For example, when a user selects a recorded binary file for playback, the system analyzes the original data stream in the file, re-analyzes and displays it. In the protocol view, it shows the parsed fields and values, in the original data view, it shows the original hexadecimal code stream, and in the session view, it shows the session information in chronological order, enabling users to reproduce the problem scenario for in-depth analysis. By supporting recording the data before and after parsing into files and supporting subsequent import and playback, it provides a powerful tool for system debugging, optimization, and fault troubleshooting. Users can reproduce the problem scenario by playing back historical data, deeply analyze the causes of problems, and thus take effective measures to solve problems, improving the reliability and stability of the system; at the same time, it also provides a data basis for system performance evaluation and optimization.

[0054] Compared with the prior art, with the help of the user-defined protocol description file, one system can adapt to countless custom or standard protocols without developing dedicated tools for each new protocol. For example, a protocol file can be imported, and the specific model protocol can be selected through the host computer for communication; it has achieved a revolutionary improvement in debugging efficiency, liberating developers from the cumbersome "manual decoding", making the data meaning clear at a glance, and greatly shortening the problem location time; and it has the ability to actively discover problems. Through the intelligent monitoring module, it can automatically and timely discover hidden defects that are easily overlooked, such as intermittent packet loss, response delay, occasional parity errors, etc., upgrading debugging from "passive viewing" to "active monitoring"; it has intuitive visualization effects, using multi-view linkage display to convert the original binary communication into parameters with clear engineering significance, greatly improving the readability of data; in addition, the defined protocol file can be used as part of the project documentation, facilitating team sharing and subsequent maintenance, and realizing the accumulation and reuse of debugging knowledge.

[0055] Reference Figure 3 The diagram shown is a functional block diagram of a real-time communication data monitoring device according to an embodiment of this application.

[0056] In some embodiments, the real-time communication data monitoring device 30 may include multiple functional modules composed of computer program segments. The computer programs for each program segment of the real-time communication data monitoring device 30 may be stored in the memory of an electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) This application describes a function for real-time monitoring of communication data. Based on its functions, it can be divided into multiple functional modules. These modules may include: a receiving module 301, an identification module 302, a parsing module 303, and a storage module 304. The term "module" in this application refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0057] The receiving module 301 is used to receive the raw data stream of the device to be debugged transmitted by the communication adapter module.

[0058] The identification module 302 is used to identify the original data stream according to the protocol description file and determine the complete data frame corresponding to the original data stream; the protocol description file is user-defined and pre-imported.

[0059] The parsing module 303 is used to parse and verify the complete data frame to obtain structured data.

[0060] The storage module 304 is used to associate and store the structured data and the original data stream.

[0061] It should be understood that the various variations and specific embodiments of the real-time monitoring method for communication data provided in the above embodiments are also applicable to the real-time monitoring device for communication data in this embodiment. Through the foregoing detailed description of the real-time monitoring method for communication data, those skilled in the art can clearly understand the implementation method of the real-time monitoring device for communication data in this embodiment. For the sake of brevity, it will not be described in detail here.

[0062] See Figure 4 The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 4 includes a memory 41, at least one processor 42, and at least one communication bus 43.

[0063] Those skilled in the art should understand that Figure 4The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 4 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0064] In some embodiments, the electronic device 4 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 4 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0065] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0066] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0067] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0068] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0069] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0070] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0071] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for real-time monitoring of communication data, characterized in that, The method includes: Receive the raw data stream from the device to be debugged, transmitted by the communication adapter module; The original data stream is identified according to the protocol description file to determine the complete data frame corresponding to the original data stream; the protocol description file is user-defined and pre-imported. The complete data frame is parsed and verified to obtain structured data; The structured data and the original data stream are stored together.

2. The real-time monitoring method for communication data according to claim 1, characterized in that, The protocol description file is defined using a structured language or form-based method, including global protocol attributes, frame structure, field-level parameters, and command-response mapping relationships; the global protocol attributes are used to define the protocol name, byte order, and default verification algorithm. The frame structure is used to define the components of a data frame; the field level defines each field in the frame structure; the command-response mapping defines the correspondence between request command words and expected response command words.

3. The real-time monitoring method for communication data according to claim 1, characterized in that, The step of identifying the original data stream according to the protocol description file and determining the complete data frame corresponding to the original data stream includes: A sliding window is set in the raw data stream according to the frame header information in the protocol description file; the size of the sliding window is at least enough to accommodate the frame header information. A window is slid across the raw data stream according to a preset step size. After each slide, the data in the window is compared with the frame header information. When the data within the window matches the frame header information, the matching position is determined as the potential frame start position; Determine whether the protocol description file contains frame tail information; When it is determined that the protocol description file contains frame tail information, the complete data frame is determined based on the potential frame start position and the frame tail information; When it is determined that the protocol description file does not contain frame tail information, the actual data frame length is calculated based on the potential frame start position. In the original data stream, determine the data segment corresponding to the actual data frame length, and determine the complete data frame based on the data segment.

4. The real-time monitoring method for communication data according to claim 3, characterized in that, The process of parsing and verifying the complete data frame to obtain structured data includes: The complete data frame is parsed field by field according to the protocol description file, and the word order is converted to obtain a set of data fields; Each data field in the data field set is validated according to the default validation algorithm defined in the protocol description file; When it is determined that each data field in the data field set has been verified correctly, the actual verification value of the data field set is calculated. Compare the actual verification value with the preset verification value; When it is determined that the actual verification value is consistent with the preset verification value, the actual data frame length is verified according to the data frame length defined in the protocol description file. When it is determined that the actual data frame length is consistent with the data frame length defined in the protocol description file, each data field in the data field set is organized into the structured data.

5. The real-time monitoring method for communication data according to claim 4, characterized in that, The method further includes: When it is determined that the actual data frame length is less than the data frame length defined in the protocol description file, it is determined that there are byte losses in the complete data frame, and the difference between the actual data frame length and the data frame length defined in the protocol description file is the number of lost bytes.

6. The real-time monitoring method for communication data according to any one of claims 1 to 5, characterized in that, The method further includes: The time window for expected data frame transmission is determined according to a preset data transmission rule; the data transmission rule includes a periodic transmission rule or a transmission rule based on an external trigger signal; Determine whether the expected data frame to be sent is sent within the time window; When it is determined that the expected data frame was not sent within the time window, a missed transmission is identified, and the information of the missed data frame and the missed transmission time are recorded.

7. The real-time monitoring method for communication data according to any one of claims 1 to 5, characterized in that, The method further includes: When a request frame is detected, the preset timeout time corresponding to the request frame is determined according to the command-response mapping relationship defined in the protocol description file, and the timer is started to count down. During the start of the timer, it continuously monitors whether a response frame corresponding to the request frame is received; When it is determined that a response frame corresponding to the request frame is received within the preset timeout period, the timer is stopped. When it is determined that no response frame corresponding to the request frame is received within the preset timeout period, it is determined that there is a response timeout or a missed reply, and the request frame information, the preset timeout period, and the time information of the time when the response frame corresponding to the request frame was not received are recorded.

8. A real-time monitoring device for communication data, characterized in that, The device includes: The receiving module is used to receive the raw data stream from the device to be debugged transmitted by the communication adapter module; The identification module is used to identify the original data stream according to the protocol description file and determine the complete data frame corresponding to the original data stream; the protocol description file is user-defined and pre-imported; The parsing module is used to parse and verify the complete data frame to obtain structured data; A storage module is used to associate and store the structured data and the original data stream.

9. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the real-time monitoring method for communication data according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the real-time monitoring method for communication data as described in any one of claims 1 to 7.

Images