A zero-code protocol analysis and full-link visual debugging method for heterogeneous terminals

Abstract

The application relates to the technical field of software development, in particular to a zero-code protocol analysis and full-link visual debugging method for heterogeneous terminals, which comprises the following steps: obtaining protocol configuration information of a heterogeneous terminal input by a user through a visual interface; constructing a standardized protocol model instance by analyzing communication parameters and message rules in the protocol configuration information; initializing a communication server according to the communication parameters in the protocol model instance; and establishing a one-to-one mapping binding relationship between a network listening port and the protocol model instance. The application listens to the data flow of the network listening port, calls corresponding protocol model instances based on protocol routing rules, performs bidirectional data automatic conversion and full-link debugging, constructs a transparent test channel with configuration running, breaks the black box operation drawbacks of the previous rule definition and effect verification split, and realizes the integration of a large number of inventory terminals into a unified business platform.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a zero-code protocol parsing and full-link visual debugging method for heterogeneous terminals. Background Technology

[0002] Currently, the industry has mainly evolved two technical approaches to solve the problem of integrating highly heterogeneous devices. Although they have made progress in the flexibility of protocol adaptation, based on publicly available solutions, there are still common shortcomings in key aspects of improving integration efficiency and reliability.

[0003] Option 1: Platform-centric standardization and adaptation-driven model (standardization-driven adaptation) The fundamental logic of this solution is to overcome heterogeneity by establishing a "unified standard" and completing "one-way adaptation" on the device, edge, or platform side.

[0004] 1. Standardization Definition: The platform provider (or industry alliance) predefines communication and data standards. At the data level, this is usually reflected in a "thing model" or a unified information model, providing standardized description templates for device functions and data points.

[0005] 2. One-way adaptation path: The device "actively approaches" the platform standard through the following two paths: 1) Path A (Native Device-Side Adaptation): This is the ideal path. Device manufacturers develop products according to platform standards, and the device firmware natively supports standard protocols and object models, allowing direct communication with the platform. For example, the device needs to integrate a specific SDK provided by the platform, or be designed according to standard protocols such as WMMP.

[0006] 2) Path B (Edge Gateway Adaptation): This fallback solution is used when the device uses a proprietary protocol. An edge gateway or protocol converter is added between the device and the platform. By developing an adaptation plugin on this gateway, the proprietary protocol is "translated" into the platform's standard format. This essentially moves the adaptation work from the cloud to the edge.

[0007] Advantages and disadvantages analysis: Advantages: Once adapted, the platform-side processing is extremely unified and efficient, easy to expand and manage, and meets the vision of large-scale deployment. Disadvantages: Particularly prominent when addressing the need for rapid and flexible integration of existing heterogeneous equipment. 1. Difficulty in integrating existing "dumb devices": The solution heavily relies on proactive modifications on the device or gateway side. For a large number of deployed, old industrial devices with fixed protocols ("dumb devices"), firmware modification is impossible, and adding a dedicated gateway would significantly increase costs, thus excluding these devices from the integration scope.

[0008] 2. Long implementation cycle and heavy reliance on external resources: Whether it's pushing equipment manufacturers to produce according to the new standard or developing gateway adaptation plugins for proprietary protocols, it's a lengthy, specialized, and uncontrollable process. Platform users cannot independently control the integration pace.

[0009] 3. The barriers to secondary development and debugging remain: "Secondary development" in the gateway adaptation path is essentially still hard-coding or complex script development for specific protocols. Configuring gateway protocols and data mapping remains a professional and cumbersome process, lacking efficient debugging tools. The correctness of the configuration can only be verified after deployment and interaction with real devices, resulting in high trial-and-error costs.

[0010] Option 2: Platform-driven device adaptation mode The core idea of ​​this model is that the platform side undertakes all heterogeneity resolution work, without requiring any modifications to the device side. It is mainly implemented through two technical paths, each with its own characteristics.

[0011] Path 1: Fully Custom Code Development: For each specific device protocol, develop independent communication connection, data parsing and processing programs from scratch on the platform side on a "one-to-one" basis.

[0012] Path 2: Parameterized Configuration Conversion: The platform provides a general protocol framework and a visual configuration interface. Users generate adaptation rules by filling in forms (such as selecting protocol type, setting port, defining data packet field structure, offset, data type, etc.), and the platform's built-in general engine performs the actual protocol conversion and data processing. This is the main evolutionary direction of this model.

[0013] Advantages of the solution: 1. Zero intrusion on devices and extremely strong compatibility: This is the most fundamental advantage of this solution. It does not require equipment manufacturers to modify any hardware or software, and can directly interface with all existing devices on the market, regardless of whether their communication protocols and data formats are proprietary or non-standard, completely solving the integration problem of existing devices.

[0014] 2. Fully internalized integration initiative: Platform users or integrators do not need to rely on the technical support or modification schedule of equipment manufacturers, and can independently control the integration pace, which significantly improves the autonomy and controllability of project implementation.

[0015] 3. Parameterized configuration improves flexibility and maintainability (for path 2): Compared to hard coding, adjusting protocol rules through the configuration interface avoids modifying the underlying code and complex recompiling and deployment processes, making protocol changes and iterations more agile and improving system maintainability.

[0016] Disadvantages and limitations of the solution: 1. The configuration process still has a high professional threshold (for path two): Although it eliminates the need to write code, accurately "translating" the binary protocol in the technical manual into a complete set of configuration parameters (such as precise offsets, bit fields, byte order, checksum calculations, etc.) requires the operator to have solid knowledge of communication and data structures. The configuration process is complex and prone to parsing failure due to minor errors.

[0017] 2. Inefficient Verification of Configuration Correctness: After configuration, there is a lack of immediate verification mechanism. Users must deploy the configuration to the runtime environment, connect to real physical devices, and indirectly determine whether the configuration is correct by triggering device reporting or checking subsequent system logs. If an error occurs, the configuration problem must be traced back from the result, going through a cycle of "modification-deployment-retesting". This process is time-consuming, inefficient, and highly dependent on the readiness of real devices, becoming a key bottleneck affecting integration efficiency.

[0018] 3. System-level configuration silos are easily created: Each heterogeneous device requires a separate and complex configuration package. When hundreds or thousands of devices are connected, a large number of fragmented configurations are generated, which brings complexity and potential risks to version management, batch updates, and long-term maintenance.

[0019] 4. Lack of upfront business logic integration capabilities: This solution primarily ensures the parsability of the data path, but it cannot provide an isolated environment to pre-verify the correctness of the complete control chain of "business command -> device action" before the business system development is completed. Control logic testing is postponed to the end-to-end integration phase, increasing debugging risks and costs in the later stages of the project.

[0020] In summary, both Scheme 1 and Scheme 2 face practical obstacles in addressing the access of highly heterogeneous devices, such as the cost of large-scale implementation and transformation, or technical process deficiencies in key aspects like zero-coding, closed-loop testing, and offline business simulation. Therefore, improvements are needed. Summary of the Invention

[0021] The purpose of this invention is to address the shortcomings of existing technologies by proposing a zero-code protocol parsing and full-link visualization debugging method for heterogeneous terminals.

[0022] To achieve the above objectives, the present invention adopts the following technical solution: a zero-code protocol parsing and full-link visual debugging method for heterogeneous terminals, comprising the following steps: Obtain protocol configuration information of heterogeneous terminals input by users through a visual interface, and construct standardized protocol model instances by parsing the communication parameters and message rules in the protocol configuration information; Initialize the communication server according to the communication parameters in the protocol model instance, establish a one-to-one mapping and binding relationship between the network listening port and the protocol model instance, and form a protocol routing rule based on port definition; The protocol model instance is used to perform static encoding and decoding verification on the input simulated test data. By comparing the conversion results of the simulated test data with the preset expected value, a verification result is generated to confirm the logical correctness of the protocol configuration information. Monitor the data traffic on the network listening port, call the corresponding protocol model instance based on the protocol routing rules, and perform bidirectional automatic data conversion and full-link debugging between heterogeneous terminals and the business platform.

[0023] Preferably, the steps of obtaining the protocol configuration information of heterogeneous terminals input by the user through a visual interface, and constructing a standardized protocol model instance by parsing the communication parameters and message rules in the protocol configuration information are as follows: A configuration form is generated in the visualization interface. The device model identifier, communication protocol type and network port number of the heterogeneous terminal are collected through the configuration form and encapsulated as the communication parameters. The visualization interface provides a field definition tool, through which the data packet structure of the heterogeneous terminal is obtained. The data packet structure includes field offset, field data type and byte length, and the Aviator expression script for data verification and conversion is obtained. The communication parameters, the data packet structure, and the Aviator expression script are dynamically serialized based on JSON format to generate the standardized protocol model instance. The protocol model instance includes a decoding rule set for describing uplink data and an encoding rule set for describing downlink data. A unique model index ID is assigned to the protocol model instance, and the model index ID is associated with and stored with the device model identifier.

[0024] Preferably, the steps of initializing the communication server based on the communication parameters in the protocol model instance, establishing a one-to-one mapping and binding relationship between the network listening port and the protocol model instance, and forming a protocol routing rule based on the port definition are as follows: Read the communication protocol type and network port number contained in the protocol model instance, and start the ServerBootstrap service instance corresponding to the communication protocol type using the Netty network framework; Bind the network port number to the ServerBootstrap service instance, and load a custom protocol handling handler in the ChannelPipeline of the ServerBootstrap service instance; Inject a reference to the protocol model instance into the protocol processing Handler to establish a static binding mapping between the network listening port and the protocol model instance; A global routing mapping table is constructed, with the network listening port as the key and the object reference of the protocol model instance as the value, and stored in the global routing mapping table to form the protocol routing rule based on the port definition.

[0025] Preferably, the step of using the protocol model instance to perform static encoding and decoding verification on the input simulated test data, and generating a verification result to confirm the logical correctness of the protocol configuration information by comparing the conversion result of the simulated test data with the preset expected value, specifically includes: Without initiating a real network connection, start an independent static debugging environment and load the protocol model instance within that static debugging environment; Receive hexadecimal simulated messages input by the user, call the decoding rule set in the protocol model instance to parse the hexadecimal simulated messages, and output the parsed JSON structured data; Receive JSON simulation commands input by the user, call the encoding rule set in the protocol model instance to reverse convert the JSON simulation commands, and output the generated binary byte stream; The generated binary byte stream is compared with the preset expected binary stream. If the two are completely consistent, a verification result marked as passed is generated; otherwise, a failure report containing error field location information is generated.

[0026] Preferably, the steps of monitoring the data traffic on the network listening port, invoking the corresponding protocol model instance based on the protocol routing rules, and performing bidirectional automatic data conversion and end-to-end debugging between heterogeneous terminals and the service platform are as follows: The communication server monitors the network listening port in real time to capture raw binary data streams from the heterogeneous terminals. Query the global routing mapping table and match the corresponding protocol model instance based on the network listening port; The original binary data stream is split into packets using the packet-merging processing strategy in the protocol model instance to obtain complete data frames; The Aviator expression script in the protocol model instance is used to dynamically parse the complete data frame, generate standardized business JSON data, and push the business JSON data to the business platform through the WebSocket channel; The system receives control JSON commands issued by the business platform, converts the control JSON commands into target binary commands using the encoding rule set in the protocol model instance, and sends them to the heterogeneous terminal through the Socket channel corresponding to the network listening port.

[0027] Preferably, the step of using the packet-merging processing strategy in the protocol model instance to perform packet fragmentation processing on the original binary data stream to obtain a complete data frame specifically includes: Read the packet splitting rule parameters configured in the protocol model instance. The packet splitting rule parameters include the length field offset, the number of bytes in the length field, and the packet header identifier. The position of the header identifier is retrieved in the original binary data stream to determine the start position of the data frame; The length field data is located based on the length field offset, and the length field data is parsed to obtain the theoretical payload length of the current data frame; According to the theoretical load length, a byte sequence of the corresponding length is extracted from the starting position, the byte sequence is assembled into the complete data frame, and the complete data frame is passed to the subsequent decoding engine. At the same time, the remaining byte data is cached in the receive buffer to wait for the next processing.

[0028] Preferably, the step of dynamically parsing the complete data frame using the Aviator expression script in the protocol model instance to generate standardized business JSON data, and then pushing the business JSON data to the business platform via the WebSocket channel, specifically includes: Iterate through the list of fields defined in the protocol model instance, and for each field in the list, extract the corresponding byte fragment from the complete data frame; The Aviator expression script is executed to perform numerical conversion, bitwise operations, and logical verification on the byte fragment to obtain the parsed field value; The parsed values ​​of the fields are assembled into JSON objects in key-value pair format to form the standardized business JSON data, which is then sent to the business platform through the WebSocket channel.

[0029] Preferably, the method further includes a step of generating a simulated device using the protocol model instance for reverse simulation, the step specifically being: When the business platform cannot connect to real heterogeneous terminals, the structure definition in the protocol model instance is invoked to automatically generate a simulated device operation instance. The simulated device operation instance randomly generates simulated state data that conforms to the protocol specification according to the downlink coding rules in the protocol model instance; The simulation device runs an instance to simulate TCP client behavior, actively connects to the network listening port, and sends simulated status data at preset time intervals; The system receives control commands returned by the communication server, parses the control commands using the uplink decoding rules in the protocol model instance, updates the internal state of the simulated device running instance according to the control commands, and constructs a closed-loop virtual test environment.

[0030] Preferably, the method further includes the steps of business system integration and data push, the steps of which are specifically as follows: The access point address and push protocol type of the service platform are set in the protocol configuration information; After generating the standardized business JSON data through the protocol model instance, a data connection with the business platform is established based on the access point address; The standardized business JSON data is encapsulated into an HTTP POST request body or an MQTT message payload and sent to the business platform; In response to the confirmation message returned by the business platform, if the confirmation message is not received within the preset timeout period, a retransmission mechanism is initiated to resend the standardized business JSON data until the transmission is successful or the maximum number of retransmissions is reached.

[0031] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, protocol configuration information input by the user into a visual interface is obtained, and communication parameters and message rules are parsed to construct standardized protocol model instances. The complex underlying binary conversion mechanism is transformed into a graphical form mapping, reducing the professional threshold for communication and data structure configuration. The communication server is initialized according to the communication parameters, and a one-to-one mapping and binding relationship is established between the network listening port and the protocol model instance, forming a protocol routing rule based on port definition. This completely cuts off hard-coded dependencies and achieves automatic and accurate distribution of network channels and data processing logic. The protocol model instance is used to perform static encoding and decoding verification on simulated test data, and the conversion results are compared with the preset expected values ​​to generate verification results. A pre-emptive offline isolation verification environment is established, so that the logical correctness confirmation action does not need to rely on the real physical environment and the readiness state of the upstream business system, reducing the trial and error cost and rework probability after equipment deployment. The data traffic of the network listening port is monitored, and the corresponding protocol model instance is called based on the protocol routing rules to perform bidirectional automatic data conversion and full-link debugging, constructing a transparent test channel that is configured and running immediately. This breaks the drawback of the previous black-box operation where rule definition and effect verification were separated, and realizes the integration of massive existing terminals into a unified business platform. Attached Figure Description

[0032] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of binary data frame segmentation according to the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0034] Please see Figure 1-2 This invention provides a technical solution: a zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals, comprising the following steps: Obtain protocol configuration information of heterogeneous terminals input by users through a visual interface, and construct standardized protocol model instances by parsing the communication parameters and message rules in the protocol configuration information; Initialize the communication server based on the communication parameters in the protocol model instance, establish a one-to-one mapping and binding relationship between the network listening port and the protocol model instance, and form a protocol routing rule based on the port definition. Static encoding and decoding verification is performed on the input simulated test data using protocol model instances. By comparing the conversion results of the simulated test data with the preset expected values, verification results are generated to confirm the logical correctness of the protocol configuration information. Monitor data traffic on the network listening port, call the corresponding protocol model instance based on protocol routing rules, and perform bidirectional automatic data conversion and full-link debugging between heterogeneous terminals and business platforms.

[0035] In this embodiment, the steps for obtaining the protocol configuration information of heterogeneous terminals input by the user through a visual interface, and constructing a standardized protocol model instance by parsing the communication parameters and message rules in the protocol configuration information are as follows: A configuration form is generated in the visual interface; the device model identifier, communication protocol type, and network port number of the heterogeneous terminals are collected through the configuration form and encapsulated as communication parameters; a field definition tool is provided in the visual interface; the data message structure of the heterogeneous terminals is obtained through the field definition tool, which includes field offsets, field data types, and byte lengths, and an Aviator expression script for data verification and conversion is obtained; the communication parameters, data message structure, and Aviator expression script are dynamically serialized based on JSON format to generate a standardized protocol model instance; the protocol model instance contains a decoding rule set for describing uplink data and an encoding rule set for describing downlink data; a unique model index ID is assigned to the protocol model instance, and the model index ID is associated with and stored with the device model identifier.

[0036] Specifically, the system acquires the protocol configuration information of heterogeneous terminals input by the user through a visual interface. It then renders a configuration form on the front-end page, containing three main sections: device identifier, network parameters, and packet structure. The system reads the device model identifier text entered on the page and compares its character length with a preset identifier length range (4 to 64 characters). If the length is less than 4 characters, it automatically pads the end with the default character 0. It also reads the communication protocol type selected from the drop-down menu, such as TCP or UDP, and reads the entered network port number. The system extracts the network port number and compares it with a preset range of valid ports. The range is 1024 to 65535. For example, if the port number read is 80, it is determined to be occupied or a non-service port, and the input box is cleared. The verified device model identifier, communication protocol type, and network port number are mapped to a dictionary structure and encapsulated as communication parameters. A two-dimensional data table is dynamically loaded on the page as a field definition tool. The system listens for new, modified, or deleted row operations triggered in the table, reads the data packet structure information filled in each row, reads the field offset value at the beginning of the packet, and sets the maximum offset threshold to 65535. For example, if the offset input is 70000, it is reset to 65535. The system reads the selected field data type, including unsigned integer, single-precision floating-point, and double-precision floating-point. The function reads the entered byte length parameter from a floating-point number. A maximum byte length threshold of 1024 bytes is set for a single field; if the length exceeds 1024 bytes, the current line of data is rejected. The input Aviator expression script is retrieved within a separate code editor. The functions parse the operators and logical operators contained in the Aviator expression script, comparing them against a preset set of valid operators. The valid operator set includes plus, minus, multiplication, division, and greater than or less than signs. Each character in the expression script is traversed; any exception control characters not belonging to the set are removed. Communication parameters, data packet structure, and key fields of the Aviator expression script are extracted and mapped into a multi-level tree structure. The memory object is dynamically serialized based on JSON format using a JSON parsing library, outputting serialized text in UTF-8 encoding. This serialized text is parsed to extract the uplink matching conditions and extraction actions, which are then combined to generate a decoding rule set describing the uplink data. The downlink formatting template and calculation logic are extracted and combined to generate an encoding rule set describing the downlink data. These two parts are aggregated and packaged to generate a standardized protocol model instance. A 32-bit string is generated using a hash calculation combining a timestamp and a random number, which is used as a unique model index ID assigned to the protocol model instance. The model index ID is then associated with and stored with the device model identifier.

[0037] In this embodiment, the steps of initializing the communication server based on the communication parameters in the protocol model instance, establishing a one-to-one mapping between the network listening port and the protocol model instance, and forming port-based protocol routing rules are as follows: Read the communication protocol type and network port number contained in the protocol model instance; start the ServerBootstrap service instance corresponding to the communication protocol type using the Netty network framework; bind the network port number to the ServerBootstrap service instance and load a custom protocol handling Handler in the ChannelPipeline of the ServerBootstrap service instance; inject a reference to the protocol model instance into the protocol handling Handler to establish a static binding mapping between the network listening port and the protocol model instance; construct a global routing mapping table, using the network listening port as the key and the object reference of the protocol model instance as the value, and store it in the global routing mapping table to form port-based protocol routing rules.

[0038] Specifically, the communication server is initialized based on the communication parameters in the protocol model instance. All protocol model instances loaded into memory are traversed, and the communication protocol type and network port number contained within each instance are read. Startup instructions are distributed based on the read communication protocol type. If the communication protocol type is TCP, a NioServerSocketChannel is instantiated. The ServerBootstrap service instance corresponding to the communication protocol type is started using the Netty network framework. The thread pool parameters of the ServerBootstrap service instance are configured. The current number of CPU cores on the server is obtained. The number of threads in the Boss thread group is fixed at 1, and the number of threads in the Worker thread group is set to twice the number of CPU cores. For example, if the number of CPU cores is 8, the number of Worker threads is set to 16. The read network port number is passed to the binding function, and the bind method is called to bind the network port number to the ServerBootstrap service instance. The return value of the port binding status is monitored. If the return value is positive... If the return port is occupied, an exception log is recorded and the initialization of the current instance is exited. In the ChannelPipeline of the ServerBootstrap service instance, processing components are loaded in a fixed order, namely the byte decoding component, the packet fragmentation handling component, and the custom protocol handling Handler. The physical address of the protocol model instance in memory is extracted and passed as a constructor parameter when the protocol handling Handler is instantiated. A reference to the protocol model instance is injected into the protocol handling Handler and stored in the local variable of the Handler. A static binding mapping between the network listening port and the protocol model instance is established. A data dictionary based on a hash table structure is instantiated in the system global scope to build a global routing mapping table. The integer value of the currently successfully bound network listening port is extracted as the key, and the object reference of the protocol model instance stored in the Handler is extracted as the value. The put method of the hash table is called to store it in the global routing mapping table, forming a protocol routing rule based on the port definition.

[0039] In this embodiment, the steps of using a protocol model instance to perform static encoding and decoding verification on the input simulated test data, and generating a verification result to confirm the logical correctness of the protocol configuration information by comparing the conversion result of the simulated test data with the preset expected value, are as follows: Without starting a real network connection, start an independent static debugging environment and load the protocol model instance in the static debugging environment; receive the hexadecimal simulated message input by the user, call the decoding rule set in the protocol model instance to parse the hexadecimal simulated message, and output the parsed JSON structured data; receive the JSON simulated command input by the user, call the encoding rule set in the protocol model instance to reverse convert the JSON simulated command, and output the generated binary byte stream; compare the generated binary byte stream with the preset expected binary stream. If the two are completely consistent, a verification result marked as passed is generated; otherwise, a failure report containing error field location information is generated.

[0040] Specifically, the protocol model instance is used to perform static encoding and decoding verification on the input simulated test data. The physical connection of the underlying network interface is severed from the external data input source. An independent static debugging environment is started in the sandbox memory space, and the protocol model instance is loaded through the class loader within this environment. A hexadecimal text input area is provided in the debugging panel to receive the input hexadecimal simulated messages. Spaces and newlines are removed from the message text. The hexadecimal string is parsed into a byte array in pairs. The decoding rule set in the protocol model instance is called to parse the hexadecimal simulated messages in byte array form. Byte fragments are extracted according to preset field offsets. The byte fragments are substituted into Aviator expressions to calculate specific values. The parsed JSON structured data is assembled and output according to key-value pair format. A JSON text input area is provided in the debugging panel to receive input JSON simulated commands and verify them. The JSON format validity check involves extracting each key-value pair from the JSON, invoking the encoding rule set in the protocol model instance to reverse-convert the JSON simulation instructions, converting the values ​​into corresponding byte arrays according to the field type definition, concatenating them in offset order to output the generated binary byte stream, retrieving the reference binary data corresponding to this test from memory, calculating the length difference between the generated binary byte stream and the preset expected binary stream, determining a comparison failure if the length difference is not 0, performing an XOR operation on each byte, recording the positions of bytes with non-zero XOR results, and outputting a verification result marked as passed if the XOR results of all bytes are 0, i.e., the two are completely identical, otherwise extracting the byte index where the XOR is not 0, comparing it with the protocol message structure to locate the specific field name, concatenating the error field name with the preset error message string, and outputting a failure report containing error field location information.

[0041] In this embodiment, the steps of monitoring data traffic on the network listening port, calling the corresponding protocol model instance based on protocol routing rules, and performing bidirectional automatic data conversion and full-link debugging between heterogeneous terminals and the business platform are as follows: The communication server monitors the network listening port in real time to capture the raw binary data stream from the heterogeneous terminal; it queries the global routing mapping table to match the corresponding protocol model instance based on the network listening port; it uses the packet-splitting strategy in the protocol model instance to split the raw binary data stream into packets to obtain complete data frames; it applies the Aviator expression script in the protocol model instance to dynamically parse the complete data frames, generate standardized business JSON data, and pushes the business JSON data to the business platform through the WebSocket channel; it receives control JSON commands issued by the business platform, uses the encoding rule set in the protocol model instance to convert the control JSON commands into target binary commands, and sends them to the heterogeneous terminal through the Socket channel corresponding to the network listening port.

[0042] Specifically, the process involves monitoring data traffic on the network listening port, polling all bound network ports using the operating system's underlying interface, and real-time monitoring of the network listening port via a communication server. Upon arrival of network data, a read event is triggered to capture the raw binary data stream from heterogeneous terminals. This raw binary data stream is stored in a circular buffer with an initial capacity of 2048 bytes. The source port number that triggered the read event is extracted and used as the input parameter for a hash lookup. The global routing table is queried, and all keys stored in the hash table are compared. Based on the network listening port, the corresponding protocol model instance is matched, and the rule set object within that instance is extracted. The buffer's read method is called to retrieve the data segment. The raw binary data stream is then segmented using the packet-splitting strategy within the protocol model instance. Complete data frames are obtained by truncating the length field. An empty JSON object dictionary is created, and the AVI object from the protocol model instance is applied. The ator expression script dynamically parses the complete data frame, assigns the extracted data segments to variables in the expression script and triggers the calculation logic, obtains the result string returned by the calculation, fills it into the JSON object dictionary to generate standardized business JSON data, establishes a persistent WebSocket connection with the external address, pushes the business JSON data to the business platform through the WebSocket channel, starts a receiving and listening thread for the business platform, receives control JSON commands issued by the business platform, parses the action code in the JSON commands, converts the control JSON commands into target binary commands using the encoding rule set in the protocol model instance, assembles the byte stream according to the message header, data body and checksum format defined by the protocol, finds the corresponding socket through the context object bound to the current session, and sends it to the heterogeneous terminal through the Socket channel corresponding to the network listening port.

[0043] In this embodiment, the steps for processing the original binary data stream into packets and obtaining a complete data frame using the packet merging strategy in the protocol model instance are as follows: Read the packet merging rule parameters configured in the protocol model instance, which include the length field offset, the number of bytes in the length field, and the header identifier; retrieve the position of the header identifier in the original binary data stream to determine the starting position of the data frame; locate the length field data according to the length field offset, parse the length field data to obtain the theoretical payload length of the current data frame; extract a byte sequence of the corresponding length from the starting position according to the theoretical payload length, assemble the byte sequence into a complete data frame, and pass the complete data frame to the subsequent decoding engine, while buffering the remaining byte data in the receive buffer for the next processing.

[0044] Specifically, the original binary data stream is segmented using the packet fragmentation strategy in the protocol model instance. The memory address of the protocol model instance is accessed and its configuration dictionary is parsed. The segmentation rule parameters configured in the protocol model instance are read, and key control variables are extracted. These parameters include the length field offset, the number of bytes in the length field, and the header identifier. The length field offset is an integer indicating the position of the data representing the message length. The number of bytes in the length field is an integer indicating the number of bytes occupied by the length data, for example, it is set to 2 or 4. The header identifier is a fixed hexadecimal signature, such as 0xAA55. A sliding window mechanism is used to retrieve the position of the header identifier in the original binary data stream. The size of the sliding window is set to be equal to the length of the header identifier. If the data in the current window matches the header identifier, the starting byte index of the current window is recorded to confirm the position. The starting position of the data frame is determined. The starting byte index is added to the length field offset. The byte interval containing the length field data is located according to the length field offset. The byte content of the corresponding interval is extracted according to the number of bytes in the length field. The length field data is parsed according to the big-endian or little-endian byte order. The bytes are converted into decimal integers to obtain the theoretical payload length of the current data frame. The starting byte index is extracted. The header length, theoretical payload length, and checksum length are added to the starting byte index to obtain the total length of the data frame. The corresponding length of byte sequence is extracted from the starting position according to the theoretical payload length. The extracted byte sequence is assembled into a complete data frame and placed into the processing queue and passed to the subsequent decoding engine. The starting position and length of the remaining data in the circular buffer are calculated. The remaining byte data is shifted from the current starting position to the head position of the buffer and buffered into the receive buffer to wait for the next processing.

[0045] In this embodiment, the steps of dynamically parsing the complete data frame using the Aviator expression script in the application protocol model instance to generate standardized business JSON data and pushing the business JSON data to the business platform via the WebSocket channel are as follows: traversing the field list defined in the protocol model instance, extracting the corresponding byte fragment from the complete data frame for each field in the field list; executing the Aviator expression script to perform numerical conversion, bitwise operations, and logical verification on the byte fragments to obtain the field parsing value; assembling the field parsing value into a key-value pair JSON object to form standardized business JSON data, and sending it to the business platform via the WebSocket channel.

[0046] Specifically, the Aviator expression script in the application protocol model instance dynamically parses the complete data frame. It reads the parsing rule set of the protocol model instance, extracts all dictionary items from the rule set, iterates through the field list defined in the protocol model instance, extracts the field name, offset, data type, and byte length attributes of the currently traversed element, calculates the absolute start and end positions of each field in the data frame for each field in the field list, copies the corresponding byte fragment from the complete data frame, instantiates an Aviator expression execution engine in memory, injects the byte fragment as input parameters into the execution engine's context, executes the Aviator expression script, extracts the conversion rules in the script, converts the byte fragment from binary array format to the corresponding decimal value, and performs specified bitwise operations on the value. If a bitwise AND operation is performed with the preset mask 0xFF, the conditional statements in the script are extracted for logical validation, and the operation result is compared to see if it falls within the preset valid value range. For example, the calculated temperature value is compared to see if it is between -40°C and 85°C. The final output field parsing value is obtained, a new JSON node object is instantiated, the previously traversed field names are extracted as JSON keys, the obtained field parsing values ​​are extracted as JSON values, the field parsing values ​​are assembled into key-value pair JSON objects, all JSON node objects are merged into a root node to form standardized business JSON data, a pre-established and kept active WebSocket communication handle is obtained, the send text method of the communication handle is called, and the serialized JSON string is sent to the business platform through the WebSocket channel.

[0047] In this embodiment, the method further includes a step of generating a simulated device for reverse simulation using a protocol model instance. The steps are as follows: when the business platform cannot connect to a real heterogeneous terminal, the structure definition in the protocol model instance is called to automatically generate a simulated device running instance; the simulated device running instance randomly generates simulated state data that conforms to the protocol specification according to the downlink encoding rules in the protocol model instance; the simulated device running instance simulates TCP client behavior, actively connects to the network listening port, and sends simulated state data at preset time intervals; the control commands returned by the communication server are received, the control commands are parsed using the uplink decoding rules in the protocol model instance, and the internal state of the simulated device running instance is updated according to the control commands to build a closed-loop virtual test environment.

[0048] Specifically, a periodic heartbeat detection mechanism is initiated to check network connectivity with real heterogeneous terminals. If no response message is received from the real terminal three times consecutively, the real network environment is determined to be disconnected. When the business platform cannot connect to the real heterogeneous terminal, the protocol model instance stored in memory is extracted. The structure definition within the protocol model instance is called, and all field configurations and protocol type information are extracted. An independent memory space is allocated in the virtual environment, and a new process execution entity is initialized in the memory space. A simulated device running instance is automatically generated. The encoding rule set in the protocol model instance is extracted. Based on the downlink encoding rules in the protocol model instance, the simulated device running instance randomly generates random values ​​of corresponding data types for each defined field. For example, for a humidity field defined as an unsigned integer, random integers between 0 and 100 are generated. These random values ​​are concatenated according to the message structure, and the correct header and checksum are appended to randomly generate simulated state data that conforms to the protocol specification. In the simulation instance, a Socket communication client is instantiated, and the target IP address is configured as the local loopback address. The simulation device runs the instance to simulate TCP client behavior, actively connecting to the network listening port by calling the connect method, starting a timer thread, and setting the timer's trigger period to a preset time interval, such as triggering once every 5000 milliseconds. When the timer triggers, simulated status data is sent according to the sending queue. The virtual Socket channel read events are listened for, and control commands returned by the communication server are received. The binary content of the control commands is extracted, matched with the decoding rules of the current model, and the control commands are parsed using the uplink decoding rules in the protocol model instance. The configuration parameter values ​​carried in the control commands are extracted, and the parsed values ​​are overwritten with the current memory values ​​of the corresponding attributes in the simulation device running instance. The internal state of the simulation device running instance is updated according to the control commands, forming a two-way closed-loop data interaction process and constructing a closed-loop virtual test environment.

[0049] In this embodiment, the method further includes the steps of business system integration and data push, which are as follows: setting the access point address and push protocol type of the business platform in the protocol configuration information; after generating standardized business JSON data through the protocol model instance, establishing a data connection with the business platform according to the access point address; encapsulating the standardized business JSON data into an HTTP POST request body or an MQTT message payload and sending it to the business platform; responding to the confirmation message returned by the business platform, and if no confirmation message is received within the preset timeout period, initiating a retransmission mechanism to resend the standardized business JSON data until successful transmission or the maximum number of retransmissions is reached.

[0050] Specifically, the system reads the content of the third-party system integration form filled out by the user in the visual console, extracts the URL link and communication protocol options from the form, sets the access point address and push protocol type of the business platform in the protocol configuration information, monitors the generation process of business JSON data, and after generating standardized business JSON data through the protocol model instance, extracts the IP and port number parameters from the access point address, calls the underlying network communication component to establish a data connection with the business platform based on the access point address, determines the set push protocol type, and if it is configured as HTTP, creates an HTTP client and constructs a POST request structure, placing the JSON data in the request body; if it is configured as MQTT, creates an MQTT publisher object and specifies the topic, uses the JSON data as the message payload, and encapsulates the standardized business JSON data into an HTTP... The POST request body or MQTT message payload calls the network sending interface to send to the business platform. Immediately after sending, an asynchronous timed task is started, with a preset timeout of 3000 milliseconds. It listens for the return data from the network channel, responds to the confirmation message returned by the business platform, extracts the status code from the confirmation message, and determines whether the status code indicates successful reception. If no confirmation message is received within the preset timeout period or the status code is not successful, the failed JSON data is pushed into a retransmission queue with a maximum length limit, triggering a retransmission timer and starting the retransmission mechanism to resend the standardized business JSON data. After each retransmission, the retransmission counter is incremented by one and compared with the preset maximum number of retransmissions, which is set to 3. The retransmission continues until a successful confirmation message is received (successful transmission) or the retransmission counter reaches 3 (maximum retransmission count is reached). The data is then discarded from the retransmission queue and an alarm log is recorded.

[0051] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for zero-code protocol parsing and end-to-end visual debugging of heterogeneous terminals, characterized in that, Includes the following steps: Obtain protocol configuration information of heterogeneous terminals input by users through a visual interface, and construct standardized protocol model instances by parsing the communication parameters and message rules in the protocol configuration information; The protocol model instance includes a set of decoding rules for describing uplink data and a set of encoding rules for describing downlink data; Initialize the communication server according to the communication parameters in the protocol model instance, establish a one-to-one mapping and binding relationship between the network port number and the protocol model instance, and form a protocol routing rule based on port definition; The protocol model instance is used to perform static encoding and decoding verification on the input simulated test data. By comparing the conversion results of the simulated test data with the preset expected value, a verification result is generated to confirm the logical correctness of the protocol configuration information. Monitor the data traffic of the network port number, call the corresponding protocol model instance based on the protocol routing rules, and perform bidirectional automatic data conversion and full-link debugging between heterogeneous terminals and the business platform.

2. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 1, characterized in that, The specific steps for obtaining protocol configuration information of heterogeneous terminals input by users through a visual interface, and constructing standardized protocol model instances by parsing the communication parameters and message rules in the protocol configuration information are as follows: A configuration form is generated in the visualization interface. The device model identifier, communication protocol type and network port number of the heterogeneous terminal are collected through the configuration form and encapsulated as the communication parameters. The visualization interface provides a field definition tool, through which the data packet structure of the heterogeneous terminal is obtained. The data packet structure includes field offset, field data type and byte length, and the Aviator expression script for data verification and conversion is obtained. The communication parameters, the data packet structure, and the Aviator expression script are dynamically serialized based on JSON format to generate the standardized protocol model instance. A unique model index ID is assigned to the protocol model instance, and the model index ID is associated with and stored with the device model identifier.

3. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 2, characterized in that, The specific steps for initializing the communication server based on the communication parameters in the protocol model instance, establishing a one-to-one mapping and binding relationship between network port numbers and the protocol model instance, and forming port-based protocol routing rules are as follows: Read the communication protocol type and network port number contained in the protocol model instance, and start the ServerBootstrap service instance corresponding to the communication protocol type using the Netty network framework; Bind the network port number to the ServerBootstrap service instance, and load a custom protocol handling handler in the ChannelPipeline of the ServerBootstrap service instance; Inject a reference to the protocol model instance into the protocol processing Handler to establish a static binding mapping between the network port number and the protocol model instance; A global routing mapping table is constructed, with the network port number as the key and the object reference of the protocol model instance as the value, and stored in the global routing mapping table to form the protocol routing rule based on the port definition.

4. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 3, characterized in that, The specific steps for monitoring data traffic on the network port number, invoking the corresponding protocol model instance based on the protocol routing rules, and performing bidirectional automatic data conversion and end-to-end debugging between heterogeneous terminals and the business platform are as follows: The communication server monitors the network port number in real time and captures the raw binary data stream from the heterogeneous terminal. Query the global routing mapping table and match the corresponding protocol model instance based on the network port number; The original binary data stream is split into packets using the packet-merging processing strategy in the protocol model instance to obtain complete data frames; The Aviator expression script in the protocol model instance is used to dynamically parse the complete data frame, generate standardized business JSON data, and push the business JSON data to the business platform through the WebSocket channel; The system receives control JSON commands issued by the business platform, converts the control JSON commands into target binary commands using the encoding rule set in the protocol model instance, and sends them to the heterogeneous terminal through the Socket channel corresponding to the network port number.

5. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 4, characterized in that, The specific steps for processing the original binary data stream into packets and obtaining complete data frames using the packet-merging handling strategy in the protocol model instance are as follows: Read the packet splitting rule parameters configured in the protocol model instance. The packet splitting rule parameters include the length field offset, the number of bytes in the length field, and the packet header identifier. The position of the header identifier is retrieved in the original binary data stream to determine the start position of the data frame; The length field data is located based on the length field offset, and the length field data is parsed to obtain the theoretical payload length of the current data frame; According to the theoretical load length, a byte sequence of the corresponding length is extracted from the starting position, the byte sequence is assembled into the complete data frame, and the complete data frame is passed to the subsequent decoding engine. At the same time, the remaining byte data is cached in the receive buffer to wait for the next processing.

6. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 4, characterized in that, The steps of dynamically parsing the complete data frame using the Aviator expression script in the protocol model instance to generate standardized business JSON data, and then pushing the business JSON data to the business platform via the WebSocket channel are as follows: Iterate through the list of fields defined in the protocol model instance, and for each field in the list, extract the corresponding byte fragment from the complete data frame; The Aviator expression script is executed to perform numerical conversion, bitwise operations, and logical verification on the byte fragment to obtain the parsed field value; The parsed values ​​of the fields are assembled into JSON objects in key-value pair format to form the standardized business JSON data, which is then sent to the business platform through the WebSocket channel.

7. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 1, characterized in that, The method further includes a step of generating a simulated device using the protocol model instance for reverse simulation, the step of which specifically includes: When the business platform cannot connect to real heterogeneous terminals, the structure definition in the protocol model instance is invoked to automatically generate a simulated device operation instance. The simulated device operation instance randomly generates simulated state data that conforms to the protocol specification according to the downlink coding rules in the protocol model instance; The simulation device runs an instance to simulate TCP client behavior, actively connects to the network port number, and sends the simulated status data at preset time intervals; The system receives control commands returned by the communication server, parses the control commands using the uplink decoding rules in the protocol model instance, updates the internal state of the simulated device running instance according to the control commands, and constructs a closed-loop virtual test environment.

8. The zero-code protocol parsing and end-to-end visual debugging method for heterogeneous terminals according to claim 4, characterized in that, The method also includes steps of business system integration and data push, the specific steps of which are as follows: The access point address and push protocol type of the service platform are set in the protocol configuration information; After generating the standardized business JSON data through the protocol model instance, a data connection with the business platform is established based on the access point address; The standardized business JSON data is encapsulated into an HTTP POST request body or an MQTT message payload and sent to the business platform; In response to the confirmation message returned by the business platform, if the confirmation message is not received within the preset timeout period, a retransmission mechanism is initiated to resend the standardized business JSON data until the transmission is successful or the maximum number of retransmissions is reached.

Images