Method, system and device for data interaction of multi-protocol conversion gateway and storage medium

Abstract

The application relates to a multi-protocol conversion gateway data interaction method, system, device and storage medium, the method comprising the following steps: receiving and reading a to-be-analyzed data packet, judging the source device type of the to-be-analyzed data packet; selecting a corresponding protocol analysis rule according to the source device type and analyzing the to-be-analyzed data packet to obtain an analysis field; performing address mapping and communication protocol selection according to the analysis field, determining the final device address and the target communication protocol of a target device; performing data packet format conversion according to the target communication protocol and the analysis field to obtain a to-be-forwarded data packet; and forwarding the to-be-forwarded data packet to the final device address according to the target communication protocol and sending the to-be-forwarded data packet to the target device. The application has the effect of improving the convenience of multi-protocol data interaction.

Description

Technical Field

[0001] This application relates to the technical field of communication in industrial automation systems, and in particular to a multi-protocol conversion gateway data interaction method, system, device, and storage medium. Background Technology

[0002] Currently, various communication protocols are widely used in industrial automation systems. Different manufacturers and devices often employ their own communication standards, such as CC-LINK, DeviceNet, Modbus, and EtherNet / IP. While these protocols each have their own characteristics, differences in protocol format, data structure, and communication mechanisms often make direct communication between devices using different protocols difficult, limiting the flexibility and scalability of system integration.

[0003] Existing multi-protocol data interaction is usually achieved through dedicated hardware interface converters. However, hardware interface modules are complex to design, costly, and can only perform data interaction for the communication protocols defined in the initial design of the hardware interface, resulting in poor versatility.

[0004] The existing technical solutions mentioned above have the following drawbacks: the existing multi-protocol data interaction methods are inconvenient. Summary of the Invention

[0005] To improve the convenience of multi-protocol data interaction, this application provides a multi-protocol conversion gateway data interaction method, system, device, and storage medium.

[0006] The above-mentioned objective of this application is achieved through the following technical solution:

[0007] A method for data interaction of a multi-protocol conversion gateway, the method comprising:

[0008] Receive and read the data packet to be parsed, and determine the source device type of the data packet to be parsed;

[0009] Select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields;

[0010] Based on the parsed fields, address mapping and communication protocol selection are performed to determine the final device address and target communication protocol of the target device.

[0011] The data packet format is converted according to the target communication protocol and the parsed fields to obtain the data packet to be forwarded;

[0012] According to the target communication protocol, the data packet to be forwarded is forwarded to the final device address and sent to the target device.

[0013] By adopting the above technical solutions, by receiving and reading the data packets to be parsed and determining the source device type, the accurate classification of the data source protocol can be completed at the ingress side, reducing subsequent parsing ambiguity and erroneous branches, and improving the accuracy of multi-protocol gateway data interaction. By selecting the corresponding protocol parsing rules based on the source device type and parsing the parsed fields, key elements such as the original packet header, data, and checksum can be extracted in a structured manner, thereby providing standardized input for subsequent mapping and conversion, and improving the accuracy of multi-protocol gateway data interaction. By performing address mapping and communication protocol selection based on the parsed fields to determine the final device address and target communication protocol, cross-protocol addressing and link policy decisions can be automatically completed, thereby avoiding manual configuration errors and improving the expansion and adaptation capabilities for new protocols / new devices, and improving the convenience of multi-protocol gateway data interaction. By converting the data packet format based on the target communication protocol and parsed fields and sending accordingly, the frame header / control and checksum can be reconstructed and forwarded according to the target protocol while maintaining the service load, thereby ensuring that the target side can accept and correctly parse it, and improving the accuracy and timeliness of multi-protocol gateway data interaction.

[0014] In a preferred embodiment, this application can be further configured such that: receiving and reading the data packet to be parsed, and determining the source device type of the data packet to be parsed, specifically includes:

[0015] Read the protocol identifier field from the data packet to be parsed and perform feature recognition to obtain the protocol identifier feature information;

[0016] The source device type of the data packet to be parsed is determined based on the protocol identifier feature information.

[0017] By adopting the above technical solution, the source device type can be determined by reading the protocol identifier field and performing feature recognition, which can realize the automatic identification of the source protocol of the data packet, shorten the access debugging time and improve the identification accuracy.

[0018] In a preferred embodiment, this application can be further configured such that: the step of selecting the corresponding protocol parsing rule according to the source device type and parsing the data packet to be parsed to obtain the parsed fields specifically includes:

[0019] Select the appropriate protocol parsing rule based on the source device type;

[0020] According to the protocol parsing rules, the data packet to be parsed is parsed into parsing fields of the corresponding format. The parsing fields include the original data packet header, the original data field, and the original CRC check bit.

[0021] By adopting the above technical solution, and by selecting the appropriate protocol parsing rules according to the source device type and parsing the data packet into the original data packet header, original data field and original CRC check bit, the load and integrity information can be completely preserved under a unified data model. This facilitates subsequent consistency verification and problem localization, reduces the risk of lost or incorrect fields during cross-protocol parsing, and improves the accuracy of multi-protocol gateway data interaction.

[0022] In a preferred embodiment, this application may be further configured to include, after parsing the data packet to be parsed into parsed fields of the corresponding format:

[0023] Based on the original CRC check bits, the data packet to be parsed is subjected to CRC check to obtain the check result;

[0024] If the verification result is a verification failure, the source device address is obtained from the original data packet header according to the protocol parsing rules, and a data packet retransmission request is sent to the source device address.

[0025] By adopting the above technical solution, and by performing CRC verification on the data packet to be parsed based on the original CRC check bit, and triggering a retransmission request by parsing the source device address when the verification fails, erroneous frames can be intercepted in time at the gateway entry point and the data quality can be restored from the source end. This avoids the propagation of erroneous data to the target network, reduces invalid forwarding, and improves the reliability and convenience of end-to-end communication.

[0026] In a preferred embodiment, this application can be further configured such that: the step of performing address mapping and communication protocol selection based on the parsed field to determine the final device address and target communication protocol of the target device specifically includes:

[0027] The target device address is obtained by parsing the original data packet header using the aforementioned protocol parsing rules;

[0028] Obtain a pre-built device address lookup table, and look up the target device type and final device address corresponding to the target device address in the device address lookup table;

[0029] Match the target communication protocol corresponding to the target device based on the target device type.

[0030] By adopting the above technical solution, the target device address is obtained by parsing the original data packet header, the corresponding target device type and final device address are found in the pre-built device address lookup table, and the target communication protocol is matched according to the target device type. This can automatically complete the destination address resolution and protocol decision, thereby reducing the amount of manual mapping configuration, adapting to changes in device topology and protocol combination, improving the system's versatility and scalability, and thus improving the convenience of multi-protocol gateway data interaction.

[0031] In a preferred embodiment, this application can be further configured such that: the step of performing address mapping and communication protocol selection based on the parsed field to determine the final device address and target communication protocol of the target device specifically includes:

[0032] The target device address is obtained by parsing the original data packet header using the aforementioned protocol parsing rules;

[0033] Obtain a pre-built device address lookup table, and look up the target device type and final device address corresponding to the target device address in the device address lookup table;

[0034] Match the target communication protocol corresponding to the target device based on the target device type.

[0035] By adopting the above technical solution, by generating the header of the data packet to be forwarded according to the target communication protocol and recalculating the CRC check value, and then encapsulating the header of the data packet to be forwarded, the CRC to be forwarded and the original data fields into a data packet to be forwarded according to the target communication protocol, it is possible to meet the frame structure and integrity requirements of the target protocol while maintaining the consistency of service load, thereby ensuring stable reception and correct parsing of the target device and improving the success rate and data integrity of cross-protocol forwarding.

[0036] The second objective of this invention is achieved through the following technical solution:

[0037] A multi-protocol conversion gateway data interaction system, the multi-protocol conversion gateway data interaction system comprising:

[0038] The data receiving module is used to receive and read the data packet to be parsed, and to determine the source device type of the data packet to be parsed;

[0039] The data parsing module is used to select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields;

[0040] The mapping and protocol selection module is used to perform address mapping and communication protocol selection based on the parsed fields, and to determine the final device address and target communication protocol of the target device.

[0041] The format conversion module is used to convert the data packet format according to the target communication protocol and the parsed field to obtain the data packet to be forwarded;

[0042] The data forwarding module is used to forward the data packet to be forwarded to the final device address according to the target communication protocol, and send it to the target device.

[0043] By adopting the above technical solutions, by receiving and reading the data packets to be parsed and determining the source device type, the accurate classification of the data source protocol can be completed at the ingress side, reducing subsequent parsing ambiguity and erroneous branches, and improving the accuracy of multi-protocol gateway data interaction. By selecting the corresponding protocol parsing rules based on the source device type and parsing the parsed fields, key elements such as the original packet header, data, and checksum can be extracted in a structured manner, thereby providing standardized input for subsequent mapping and conversion, and improving the accuracy of multi-protocol gateway data interaction. By performing address mapping and communication protocol selection based on the parsed fields to determine the final device address and target communication protocol, cross-protocol addressing and link policy decisions can be automatically completed, thereby avoiding manual configuration errors and improving the expansion and adaptation capabilities for new protocols / new devices, and improving the convenience of multi-protocol gateway data interaction. By converting the data packet format based on the target communication protocol and parsed fields and sending accordingly, the frame header / control and checksum can be reconstructed and forwarded according to the target protocol while maintaining the service load, thereby ensuring that the target side can accept and correctly parse it, and improving the accuracy and timeliness of multi-protocol gateway data interaction.

[0044] The above-mentioned objective three of this application is achieved through the following technical solution:

[0045] A computer device 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 above-described multi-protocol conversion gateway data interaction method.

[0046] The fourth objective of this application is achieved through the following technical solution:

[0047] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described multi-protocol conversion gateway data interaction method.

[0048] In summary, this application includes at least one of the following beneficial technical effects:

[0049] 1. By reading the protocol identifier field and performing feature recognition to determine the source device type, the source protocol of the data packet can be automatically identified, which shortens the access debugging time and improves the identification accuracy. By selecting the appropriate protocol parsing rules according to the source device type and parsing the data packet into the original data packet header, original data field and original CRC check bit, the load and integrity information can be completely preserved under a unified data model, which facilitates subsequent consistency verification and problem location, reduces the risk of lost and incorrect fields when parsing across protocols, and improves the accuracy of multi-protocol gateway data interaction;

[0050] 2. By performing CRC check on the data packet to be parsed based on the original CRC check bit and triggering a retransmission request by parsing the source device address when the check fails, erroneous frames can be intercepted in time at the gateway entry point and the data quality can be restored from the source end. This avoids the propagation of erroneous data to the target network, reduces invalid forwarding, and improves the reliability and convenience of multi-protocol gateway data interaction. By parsing the original data packet header to obtain the target device address, looking up the corresponding target device type and final device address in the pre-built device address lookup table, and matching the target communication protocol according to the target device type, the destination address resolution and protocol decision can be completed automatically. This reduces the amount of manual mapping configuration, adapts to changes in device topology and protocol combination, improves the versatility and scalability of the system, and thus improves the convenience of multi-protocol gateway data interaction.

[0051] 3. By generating the header of the data packet to be forwarded according to the target communication protocol and recalculating the CRC check value, and then encapsulating the header of the data packet to be forwarded, the CRC to be forwarded, and the original data fields into a data packet to be forwarded according to the target communication protocol, it is possible to meet the frame structure and integrity requirements of the target protocol while maintaining the consistency of service load, thereby ensuring stable reception and correct parsing of the target device and improving the success rate and data integrity of cross-protocol forwarding. Attached Figure Description

[0052] Figure 1 This is a flowchart of a multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0053] Figure 2 This is a flowchart illustrating the implementation of step S10 in the multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0054] Figure 3 This is a flowchart illustrating the implementation of step S20 in the multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0055] Figure 4 This is a flowchart illustrating the implementation of step S22 and beyond in the multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0056] Figure 5 This is a flowchart illustrating the implementation of step S30 in the multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0057] Figure 6 This is a flowchart illustrating the implementation of step S40 in the multi-protocol conversion gateway data interaction method in one embodiment of this application.

[0058] Figure 7 This is a schematic diagram of a multi-protocol conversion gateway data interaction system in one embodiment of this application.

[0059] Figure 8This is a schematic diagram of a device according to one embodiment of this application. Detailed Implementation

[0060] The present application will be further described in detail below with reference to the accompanying drawings.

[0061] In one embodiment, such as Figure 1 As shown, this application discloses a data interaction method for a multi-protocol conversion gateway, which specifically includes the following steps:

[0062] S10: Receive and read the data packet to be parsed, and determine the source device type of the data packet to be parsed.

[0063] Specifically, after data arrives in the receive buffer, a few leading bytes are copied to a temporary area for quick inspection. The protocol identifier field is read and compared with the identifier characteristics of known protocols to record the corresponding source type.

[0064] S20: Select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields.

[0065] Specifically, after determining the source device type, the corresponding parsing method is loaded. The fixed or variable length packet header segment is read according to the method, and the address bits, control bits and data length are parsed out. The business data area is truncated according to the length. At the same time, the integrity verification segment is read from the tail. The parsing result containing the original data packet header, original data field and related verification information is combined and output as the parsed field.

[0066] S30: Based on the parsed fields, perform address mapping and communication protocol selection to determine the final device address and target communication protocol of the target device.

[0067] Specifically, the target device address-related fields are located in the original data packet header. The target device address is used as the key to query a lookup table and read the corresponding target device's communication protocol type and valid address in the target network.

[0068] S40: Convert the data packet format according to the target communication protocol and parsed fields to obtain the data packet to be forwarded.

[0069] Specifically, the frame header is filled with the start marker, length, control and destination address information required according to the field definition of the target communication protocol. The length of the service data in the parsed field is included in the length field. Then, the CRC to be forwarded is calculated locally for "frame header + service data". The generated data packet header and the original data field are concatenated in the order specified by the target communication protocol. Finally, the CRC to be forwarded is appended, and the complete data packet to be forwarded is output.

[0070] S50: Forward the data packet to be forwarded to the final device address according to the target communication protocol and send it to the target device.

[0071] Specifically, the reassembled data packet to be forwarded is sent to the final device address where the target device is located using a communication protocol that the target device can recognize. After receiving it, the target device will perform a second CRC check. If there is no problem, it will proceed with the subsequent data parsing operation. If there is a problem, it will send a data packet retransmission request to the multi-protocol gateway.

[0072] In one embodiment, such as Figure 2 As shown, in step S10, which involves receiving and reading the data packet to be parsed and determining the source device type of the data packet, the specific steps include:

[0073] S11: Read the protocol identifier field in the data packet to be parsed and perform feature recognition to obtain the protocol identifier feature information.

[0074] Specifically, the packet header is parsed from the beginning of the parsed data packet, feature segments that can be used for differentiation are extracted and pattern matching or range verification is performed, and the matched key byte sequences, length features and positional relationships are combined into protocol identification feature information.

[0075] S12: Determine the source device type of the data packet to be parsed based on the protocol identifier feature information.

[0076] Specifically, the obtained protocol identifier feature information is compared with the existing set of protocol features to determine the matching source device type, i.e., the communication protocol of the source device.

[0077] In one embodiment, such as Figure 3 As shown, in step S20, the corresponding protocol parsing rule is selected according to the source device type, and the data packet to be parsed is parsed to obtain the parsed fields, specifically including:

[0078] S21: Select the appropriate protocol parsing rule based on the source device type.

[0079] Specifically, the appropriate protocol parsing rule is selected according to the communication protocol of the source device. For example, if the communication protocol of the source device is CC-Link, then the data packets with parsing sent by the source device should also be CC-Link protocol data packets. Therefore, the parsing method of CC-Link protocol is used for parsing.

[0080] S22: According to the protocol parsing rules, the data packet to be parsed is parsed into parsing fields of the corresponding format. The parsing fields include the original data packet header, the original data field, and the original CRC check bit.

[0081] Specifically, for example, if the source device's communication protocol is CC-Link, the parsed data packet will be parsed using the CC-Link protocol's parsing method to obtain the original data packet header, original data field, and original CRC check bit.

[0082] In one embodiment, such as Figure 4 As shown, after step S22, that is, after parsing the data packet to be parsed into parsing fields of the corresponding format, the method further includes:

[0083] S23: Perform CRC check on the data packet to be parsed based on the original CRC check bits to obtain the check result.

[0084] Specifically, the calculation is performed byte by byte from the beginning of the packet header to the check bit according to the calculation method of the source protocol to obtain the local calculated value, which is then compared with the original CRC check bit.

[0085] S24: If the verification result is a verification failure, the source device address is obtained from the original data packet header according to the protocol parsing rules, and a data packet retransmission request is sent to the source device address.

[0086] Specifically, when the verification result is that the locally calculated value is inconsistent with the original CRC check bit, it is recorded as a verification failure. The address field indicating the source is read from the original data packet header to construct a short retransmission request payload, which is packaged according to the encapsulation method of the source protocol and sent to the corresponding transmission channel. An appropriate waiting time is set to receive the retransmitted data, and the number of retransmissions and timestamps are recorded for subsequent statistics.

[0087] In one embodiment, such as Figure 5 As shown, in step S30, address mapping and communication protocol selection are performed based on the parsed fields to determine the final device address and target communication protocol of the target device. Specifically, this includes:

[0088] S31: Obtain the target device address by parsing the original data packet header using protocol parsing rules.

[0089] Specifically, the target address-related fields are located from the original data packet header, the target identifier is extracted according to the field definition, and if there is an offset or bit segment encoding, shift and masking operations are performed first to obtain the standardized target device address.

[0090] S32: Obtain the pre-built device address lookup table, and find the target device type and final device address corresponding to the target device address in the device address lookup table.

[0091] Specifically, the target device address is used as the key to query the lookup table and retrieve the corresponding target device type and its valid address in the target network.

[0092] S33: Match the target communication protocol corresponding to the target device based on the target device type.

[0093] Specifically, the set of available protocols associated with the target device type is read. If there is only one protocol in the set, that protocol is used directly. If there are multiple protocols, one is selected as the target communication protocol based on the preset priority or load adaptation strategy.

[0094] In one embodiment, such as Figure 6 As shown, in step S40, the data packet format is converted according to the target communication protocol and parsed fields to obtain the data packet to be forwarded, specifically including:

[0095] S41: Generate the header of the data packet to be forwarded according to the target communication protocol and recalculate the CRC check value to obtain the CRC to be forwarded.

[0096] Specifically, the start marker, length, control and target address and other information required for the frame header are filled according to the field definition of the target communication protocol. The length of the service data in the parsed field is included in the length field. Then, the CRC to be forwarded is obtained by local calculation of "frame header + service data" and stored in the temporary area.

[0097] S42: Encapsulate the header, CRC, and original data fields of the data packet to be forwarded into a data packet to be forwarded according to the target communication protocol.

[0098] Specifically, the generated data packet header and the original data fields are concatenated in the order specified by the target communication protocol, and finally the CRC to be forwarded is appended. If necessary, the byte order is adjusted and padded according to the protocol requirements, and the complete data packet to be forwarded is output for the next step of transmission.

[0099] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0100] In one embodiment, a multi-protocol conversion gateway data interaction system is provided, which corresponds one-to-one with the multi-protocol conversion gateway data interaction method described in the above embodiments. For example... Figure 7 As shown, this multi-protocol conversion gateway data interaction system includes a data receiving module, a data parsing module, a mapping and protocol selection module, a format conversion module, and a data forwarding module. Detailed descriptions of each functional module are as follows:

[0101] The data receiving module is used to receive and read data packets to be parsed, and to determine the source device type of the data packets to be parsed.

[0102] The data parsing module is used to select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields;

[0103] The mapping and protocol selection module is used to perform address mapping and communication protocol selection based on the parsed fields, and to determine the final device address and target communication protocol of the target device.

[0104] The format conversion module is used to convert the data packet format according to the target communication protocol and parsed fields to obtain the data packet to be forwarded.

[0105] The data forwarding module is used to forward data packets to the final device address according to the target communication protocol and send them to the target device.

[0106] Optionally, the data receiving module includes:

[0107] The protocol identification submodule is used to read the protocol identifier field in the data packet to be parsed and perform feature recognition to obtain the protocol identifier feature information.

[0108] The source type determination submodule is used to determine the source device type of the data packet to be parsed based on the protocol identifier feature information.

[0109] Optionally, the data parsing module includes:

[0110] The rule selection submodule is used to select the appropriate protocol parsing rule based on the source device type;

[0111] The field parsing submodule is used to parse the data packet to be parsed into parsed fields of the corresponding format according to the protocol parsing rules. The parsed fields include the original data packet header, the original data field, and the original CRC check bit.

[0112] Optionally, the field parsing submodule includes:

[0113] The verification execution unit is used to perform CRC verification on the data packet to be parsed based on the original CRC check bits and obtain the verification result.

[0114] The retransmission request unit is used to parse the source device address from the original data packet header according to the protocol parsing rules when the verification result is a verification failure, and then send a data packet retransmission request to the source device address.

[0115] Optionally, the mapping and protocol selection module includes:

[0116] The target parsing submodule is used to parse the original data packet header according to the protocol parsing rules to obtain the target device address;

[0117] The address mapping submodule is used to obtain a pre-built device address lookup table and look up the target device type and final device address corresponding to the target device address in the device address lookup table.

[0118] The protocol matching submodule is used to match the target communication protocol corresponding to the target device based on the target device type.

[0119] Optional, the format conversion module includes:

[0120] The frame header generation submodule is used to generate the header of the data packet to be forwarded according to the target communication protocol and recalculate the CRC check value to obtain the CRC to be forwarded.

[0121] The encapsulation and construction submodule is used to encapsulate the header, CRC, and original data fields of the data packet to be forwarded into a data packet to be forwarded according to the target communication protocol.

[0122] Specific limitations regarding the multi-protocol conversion gateway data interaction system can be found in the limitations of the multi-protocol conversion gateway data interaction method described above, and will not be repeated here. Each module in the aforementioned multi-protocol conversion gateway data interaction system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0123] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a multi-protocol conversion gateway data interaction method.

[0124] In one embodiment, a computer device is provided, 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 perform the following steps:

[0125] Receive and read the data packet to be parsed, and determine the source device type of the data packet to be parsed;

[0126] Select the corresponding protocol parsing rule based on the source device type and parse the data packet to be parsed to obtain the parsed fields;

[0127] Based on the parsed fields, address mapping and communication protocol selection are performed to determine the final device address and target communication protocol of the target device.

[0128] The data packet format is converted according to the target communication protocol and parsed fields to obtain the data packet to be forwarded;

[0129] According to the target communication protocol, the data packets to be forwarded are forwarded to the final device address and sent to the target device.

[0130] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0131] Receive and read the data packet to be parsed, and determine the source device type of the data packet to be parsed;

[0132] Select the corresponding protocol parsing rule based on the source device type and parse the data packet to be parsed to obtain the parsed fields;

[0133] Based on the parsed fields, address mapping and communication protocol selection are performed to determine the final device address and target communication protocol of the target device.

[0134] The data packet format is converted according to the target communication protocol and parsed fields to obtain the data packet to be forwarded;

[0135] According to the target communication protocol, the data packets to be forwarded are forwarded to the final device address and sent to the target device.

[0136] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0137] Those skilled in the art will understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0138] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for data interaction in a multi-protocol conversion gateway, characterized in that, The multi-protocol conversion gateway data interaction method includes: Receive and read the data packet to be parsed, and determine the source device type of the data packet to be parsed; Select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields; Based on the parsed fields, address mapping and communication protocol selection are performed to determine the final device address and target communication protocol of the target device. The data packet format is converted according to the target communication protocol and the parsed fields to obtain the data packet to be forwarded; According to the target communication protocol, the data packet to be forwarded is forwarded to the final device address and sent to the target device; The step of selecting the corresponding protocol parsing rule based on the source device type and parsing the data packet to be parsed to obtain the parsed fields specifically includes: Select the appropriate protocol parsing rule based on the source device type; According to the protocol parsing rules, the data packet to be parsed is parsed into parsing fields of the corresponding format. The parsing fields include the original data packet header, the original data field, and the original CRC check bit. After parsing the data packet to be parsed into parsed fields of the corresponding format, the method further includes: Based on the original CRC check bits, the data packet to be parsed is subjected to CRC check to obtain the check result; If the verification result is a verification failure, the source device address is obtained from the original data packet header according to the protocol parsing rules, and a data packet retransmission request is sent to the source device address; The step of performing address mapping and communication protocol selection based on the parsed fields to determine the final device address and target communication protocol of the target device specifically includes: The target device address is obtained by parsing the original data packet header using the aforementioned protocol parsing rules; Obtain a pre-built device address lookup table, and look up the target device type and final device address corresponding to the target device address in the device address lookup table; Match the target communication protocol corresponding to the target device based on the target device type.

2. The multi-protocol conversion gateway data interaction method according to claim 1, characterized in that, The process of receiving and reading the data packet to be parsed, and determining the source device type of the data packet to be parsed, specifically includes: Read the protocol identifier field from the data packet to be parsed and perform feature recognition to obtain the protocol identifier feature information; The source device type of the data packet to be parsed is determined based on the protocol identifier feature information.

3. The multi-protocol conversion gateway data interaction method according to claim 1, characterized in that, The step of converting the data packet format according to the target communication protocol and the parsed field to obtain the data packet to be forwarded specifically includes: Generate the header of the data packet to be forwarded according to the target communication protocol and recalculate the CRC check value to obtain the CRC to be forwarded. The header, CRC, and original data fields of the data packet to be forwarded are encapsulated into a data packet to be forwarded according to the target communication protocol.

4. A multi-protocol conversion gateway data interaction system, characterized in that, The multi-protocol conversion gateway data interaction system includes: The data receiving module is used to receive and read the data packet to be parsed, and to determine the source device type of the data packet to be parsed; The data parsing module is used to select the corresponding protocol parsing rule according to the source device type and parse the data packet to be parsed to obtain the parsed fields; The mapping and protocol selection module is used to perform address mapping and communication protocol selection based on the parsed fields, and to determine the final device address and target communication protocol of the target device. The format conversion module is used to convert the data packet format according to the target communication protocol and the parsed field to obtain the data packet to be forwarded; The data forwarding module is used to forward the data packet to be forwarded to the final device address according to the target communication protocol, and send it to the target device; The data parsing module includes: The rule selection submodule is used to select the appropriate protocol parsing rule based on the source device type; The field parsing submodule is used to parse the data packet to be parsed into parsing fields of the corresponding format according to the protocol parsing rules. The parsing fields include the original data packet header, the original data field, and the original CRC check bit. The field parsing submodule includes: The verification execution unit is used to perform CRC verification on the data packet to be parsed based on the original CRC check bits and obtain the verification result. The retransmission request unit is used to parse the source device address from the original data packet header according to the protocol parsing rules when the verification result is a verification failure, and send a data packet retransmission request to the source device address; The mapping and protocol selection module includes: The target parsing submodule is used to parse the original data packet header according to the protocol parsing rules to obtain the target device address; The address mapping submodule is used to obtain a pre-built device address lookup table and look up the target device type and final device address corresponding to the target device address in the device address lookup table. The protocol matching submodule is used to match the target communication protocol corresponding to the target device based on the target device type.

5. The multi-protocol conversion gateway data interaction system according to claim 4, characterized in that, The data receiving module specifically includes: The protocol identification submodule is used to read the protocol identifier field in the data packet to be parsed and perform feature recognition to obtain the protocol identifier feature information. The source type determination submodule is used to determine the source device type of the data packet to be parsed based on the protocol identifier feature information.

6. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multiprotocol conversion gateway data interaction method as described in any one of claims 1 to 3.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multiprotocol conversion gateway data interaction method as described in any one of claims 1 to 3.

Images