Multi-protocol fusion transmission method and device based on AutBus protocol and storage medium

Abstract

The invention discloses a multi-protocol fusion transmission method and device based on an AutBus protocol and a storage medium, and relates to the technical field of data transmission, and the method comprises the steps that when a first AutBus protocol converter receives an original protocol message sent by a source terminal device hung on the first AutBus protocol converter, the first AutBus protocol converter sends the original protocol message to the source terminal device; packaging the original protocol message according to a preset multi-protocol bearing frame format to obtain a corresponding AutBus bearing frame, and sending the AutBus bearing frame to an AutBus control node; the AutBus bearing frame is analyzed by the AutBus control node, target terminal equipment corresponding to the original protocol message and a second AutBus protocol converter for mounting the target terminal equipment are determined, and the AutBus bearing frame is broadcasted; after the second AutBus protocol converter receives the AutBus bearing frame, the original protocol message packaged in the AutBus bearing frame is sent to the target terminal device, the technical problem that an existing AutBus protocol network cannot directly bear and forward various heterogeneous bus protocol data is solved, and interconnection and intercommunication of different terminal devices are achieved.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to a multi-protocol converged transmission method, device, and storage medium based on the AutBus protocol. Background Technology

[0002] The Autonomous Bus (AutBus) protocol is a domestically developed industrial communication international standard that is independently controllable in my country. It integrates time-sensitive technology and Internet Protocol version 6 (IPv6) technology, realizing the full IP-based information technology (IT) / operational technology (OT) protocol and synchronous broadband transmission of big data at the control layer. Dedicated chips have been developed to support it, and it is widely used in intelligent manufacturing-related fields such as robotics, automobiles, ships, and aviation, providing key technical support for the development of intelligent manufacturing in my country. In the current field of industrial automation, the domestically developed industrial bus protocol AutBus has high bandwidth, high real-time performance, and unified addressing capability based on IPv6, which can effectively support the big data synchronous transmission needs in smart manufacturing scenarios. However, the existing AutBus protocol can only support data transmission of its own protocol and lacks the ability to carry other mainstream industrial bus protocols such as Modbus communication protocol, Controller Area Network (CAN), Process Field Network (Profinet), and Control & Communication Link (CC-Link). Industrial terminal devices of different bus protocol types cannot be connected to the same AutBus protocol network to achieve interconnection, which limits the networking flexibility of the AutBus protocol and makes it difficult to meet the actual needs of multi-protocol device collaboration in smart manufacturing scenarios, thus restricting the large-scale promotion and application of the AutBus protocol.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a multi-protocol converged transmission method, device and storage medium based on the AutBus protocol, which aims to solve the technical problem that existing AutBus protocol networks cannot directly carry and forward data of multiple heterogeneous industrial bus protocols.

[0005] To achieve the above objectives, this application proposes a multi-protocol fusion transmission method based on the AutBus protocol, applied to a multi-protocol fusion transmission system based on the AutBus protocol, consisting of an AutBus control node and multiple AutBus protocol converters. The multi-protocol fusion transmission method based on the AutBus protocol includes: When the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to the preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame, and sends the AutBus bearer frame to the AutBus control node. The AutBus control node parses the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter that is attached to the destination terminal device, and broadcasts the AutBus bearer frame. After receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device.

[0006] In one embodiment, the step of the AutBus control node parsing the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter mounted on the destination terminal device includes: The AutBus control node parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The AutBus control node parses the destination terminal device address from the original protocol message; The AutBus control node queries the first device address mapping table based on the destination terminal device address to determine the target converter identifier of the AutBus protocol converter corresponding to the destination terminal device address. The first device address mapping table records the correspondence between the address of each terminal device and the converter identifier of the AutBus protocol converter attached to it. The AutBus control node identifies the AutBus protocol converter corresponding to the target converter identifier as the second AutBus protocol converter, and identifies the terminal device corresponding to the destination terminal device address as the destination terminal device corresponding to the original protocol message.

[0007] In one embodiment, before the step of the AutBus control node querying the first device address mapping table based on the destination terminal device address, the method further includes: The AutBus control node receives device registration information reported by each of the AutBus protocol converters. The device registration information includes the converter identifier of the AutBus protocol converter and the address of at least one terminal device connected to the AutBus protocol converter. The AutBus control node constructs the first device address mapping table based on all the device registration information it has received.

[0008] In one embodiment, the multi-protocol fusion transmission method based on the AutBus protocol further includes: The AutBus control node queries the second device address mapping table based on the destination terminal device address to determine the target bus protocol type of the terminal device corresponding to the destination terminal device address. The second device address mapping table records the correspondence between the address of each terminal device and the corresponding bus protocol type supported by the terminal device. The AutBus control node determines whether the destination terminal device is connected to the second AutBus protocol converter based on the target bus protocol type of the destination terminal device, the target converter identifier of the second AutBus protocol converter, and a pre-configured global mapping table. If so, perform the step of broadcasting the AutBus bearer frame; The global mapping table records a many-to-many mapping relationship between the converter identifier of each AutBus protocol converter and the bus protocol type supported by at least one terminal device attached to the AutBus protocol converter.

[0009] In one embodiment, before the step of the AutBus control node determining whether the destination terminal device is connected to the second AutBus protocol converter based on the target bus protocol type of the destination terminal device, the target converter identifier of the second AutBus protocol converter, and a pre-configured global mapping table, the method further includes: The AutBus control node receives device access information reported by each of the AutBus protocol converters. The device access information includes the converter identifier of the AutBus protocol converter and the bus protocol type supported by at least one of the terminal devices connected to the AutBus protocol converter. The AutBus control node constructs the global mapping table based on all the device access information it has received.

[0010] In one embodiment, the step of the second AutBus protocol converter sending the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device after receiving the AutBus bearer frame includes: The second AutBus protocol converter receives the AutBus bearer frame; The second AutBus protocol converter parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The second AutBus protocol converter parses the destination terminal device address from the original protocol message and determines whether the destination terminal device address is the terminal device address connected to the second AutBus protocol converter. If so, the second AutBus protocol converter sends the original protocol message to the destination terminal device.

[0011] In one embodiment, the step of reading the data field content from the protocol packet entity to obtain the original protocol message includes: The second AutBus protocol converter parses the protocol packet entity, extracts the data field content to obtain encrypted protocol data, and extracts the encryption mode field content to obtain an encryption mode identifier indicating the encryption mode of the original protocol message; The second AutBus protocol converter determines the encryption mode of the encryption protocol data based on the encryption mode identifier, and obtains the decryption key corresponding to the encryption mode; The second AutBus protocol converter uses the decryption key to decrypt the encrypted protocol data to obtain the plaintext original protocol message.

[0012] In one embodiment, the step of encapsulating the original protocol message according to a preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame includes: The first AutBus protocol converter determines the corresponding encryption mode and encryption key, as well as the corresponding protocol type identifier, based on the bus protocol type supported by the source terminal device. The first AutBus protocol converter uses the encryption key and the encryption mode to encrypt the original protocol message and generate encrypted protocol data; The first AutBus protocol converter constructs a protocol packet entity containing the encrypted protocol data. The protocol packet entity includes the protocol type identifier, a data length field indicating the length of the encrypted protocol data, an encryption mode identifier indicating the encryption mode of the original protocol message, and the encrypted protocol data. The first AutBus protocol converter constructs the payload field of the AutBus bearer frame. The payload field includes a protocol packet entity number field indicating the number of protocol packet entities, a protocol packet entity total length field indicating the total length of the protocol packet entities, and the protocol packet entities themselves. The first AutBus protocol converter sets the frame header of the AutBus bearer frame and updates the value of the type field in the frame header to a preset multi-protocol bearer value; The first AutBus protocol converter forms the complete AutBus bearer frame based on the updated frame header and the payload field.

[0013] Furthermore, to achieve the above objectives, this application also proposes a multi-protocol converged transmission device based on the AutBus protocol, the multi-protocol converged transmission device based on the AutBus protocol comprising: The multi-protocol encapsulation module is used to encapsulate the original protocol message according to a preset multi-protocol bearer frame format when the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, to obtain the corresponding AutBus bearer frame, and to send the AutBus bearer frame to the AutBus control node. The parsing module is used by the AutBus control node to parse the AutBus bearer frame, determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter that is attached to the destination terminal device, and broadcast the AutBus bearer frame. The data transmission module is used to send the original protocol message encapsulated in the AutBus bearer frame to the destination terminal device after the second AutBus protocol converter receives the AutBus bearer frame.

[0014] Furthermore, to achieve the above objectives, this application also proposes a multi-protocol converged transmission device based on the AutBus protocol. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the multi-protocol converged transmission method based on the AutBus protocol as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-protocol fusion transmission method based on the AutBus protocol as described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-protocol fusion transmission method based on the AutBus protocol as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: When the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to a preset multi-protocol bearer frame format, adds an AutBus protocol adaptation shell to the heterogeneous protocol data (i.e., the original protocol message), and obtains the corresponding AutBus bearer frame, thus standardizing the heterogeneous protocol messages of various categories into data units that can be transmitted by the AutBus network. Then, the AutBus bearer frame is sent to the AutBus control node, which parses the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter connected to the destination terminal device, thus clarifying the target path for heterogeneous protocol data transmission. The AutBus control node broadcasts the AutBus bearer frame to each AutBus protocol converter. Each AutBus protocol converter parses the AutBus bearer frame and determines whether it is the target receiver of the original protocol message encapsulated within the AutBus bearer frame (the second AutBus protocol converter). If so, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device, completing the closed-loop transmission of heterogeneous protocol data (i.e., the original protocol message) within the AutBus network. This solves the technical problem that existing AutBus protocol networks cannot directly carry and forward multiple heterogeneous bus protocol data, enabling interconnection and interoperability between different terminal devices. The multi-protocol fusion transmission method based on the AutBus protocol provided in this application involves a first AutBus protocol converter encapsulating heterogeneous original protocol messages into AutBus bearer frames. This assigns a frame format recognizable by the AutBus protocol to non-AutBus heterogeneous protocol data (i.e., the original protocol messages), enabling heterogeneous protocol data (original protocol messages) that would otherwise be unable to access the AutBus network to be transmitted within it, thus solving the problem that the AutBus protocol cannot directly carry heterogeneous protocol data. The AutBus bearer frame is then sent to the AutBus control node, which performs a parsing operation on the AutBus bearer frame. The node extracts the destination terminal device of the original protocol message from the encapsulated AutBus bearer frame and matches it with the corresponding second AutBus protocol converter, thus defining the target path for the transmission of the heterogeneous protocol data (original protocol messages). Finally, the AutBus control node broadcasts the AutBus bearer frame to each AutBus protocol converter. Only the matched second AutBus protocol converter sends the original protocol message to the destination terminal device, realizing the directional forwarding of heterogeneous protocol data in the AutBus network. This enables different terminal devices to interconnect through AutBus networking, solving the problem that the AutBus protocol network cannot directly forward heterogeneous industrial bus protocol data. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This application provides a schematic diagram of the structure of an AutBus data frame; Figure 2 This is a flowchart illustrating an embodiment of the multi-protocol fusion transmission method based on the AutBus protocol in this application. Figure 3 A schematic diagram of the architecture of a multi-protocol converged transmission system based on the AutBus protocol provided in this application; Figure 4 A schematic diagram of the structure of an AutBus bearer frame with a preset multi-protocol bearer frame format provided in this application; Figure 5 This application provides a global mapping representation intent; Figure 6 A schematic diagram illustrating the processing flow of the AutBus protocol carrying multiple bus protocols provided in this application; Figure 7 This is a schematic diagram of the module structure of a multi-protocol converged transmission device based on the AutBus protocol according to an embodiment of this application; Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-protocol fusion transmission method based on the AutBus protocol in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The AutBus series of standards, developed by a leading team organized by the National Technical Committee for Standardization of Industrial Process Measurement, Control and Automation under the overall support of the Ministry of Industry and Information Technology, is currently the only international two-wire broadband bus standard based on Time-Sensitive Technology and Internet Protocol version 6 (IPv6) technology. This series of standards solves the problems of unified addressing and deterministic communication in IPv6, achieving full IP-based integration of information technology (IT) and operational technology (OT) protocols. It supports the interconnection, interoperability, and interoperability of multiple protocols in industrial communication, as well as the synchronous broadband transmission of large amounts of data such as control data, video, and images at the control layer, effectively meeting the high-bandwidth and high-real-time communication requirements of intelligent manufacturing. Currently, chips based on this series of standards have been successfully developed and can be widely used in intelligent manufacturing-related fields such as robotics, automobiles, ships, and aviation.

[0025] refer to Figure 1 , Figure 1 A schematic diagram of the structure of an existing AutBus data frame is provided. An AutBus data frame consists of an AutBus frame header, an AutBus payload, and a Cyclic Redundancy Check (CRC) field. The AutBus frame header includes a type field (TYPE), a fragment number field, and a length field (LENGTH). The type field (TYPE) is 1 byte long and serves as an identifier for the data frame, distinguishing different AutBus data frame types. The fragment number field (Fragment_no) is 4 bits long and is used to identify the fragmentation order when large application data requires fragmented transmission. The length field (LENGTH) is 12 bits long and precisely indicates the actual byte length of the payload field that follows, defining data boundaries. The payload field (PAYLOAD), as the main body of the AutBus data frame, carries the actual user data or control information to be transmitted; its length is dynamically defined by the length field (LENGTH). The CRC field is 2 bytes long; the sender calculates a checksum based on the data from all the aforementioned fields, and the receiver verifies the integrity and accuracy of the data during transmission by comparing the checksum. Referring to Table 1, the data format of an AutBus data frame in the prior art can be as shown in Table 1.

[0026] Table 1 shows a data format of an AutBus data frame in the prior art.

[0027] Referring to Table 2, the TYPE values ​​and their meanings in the AutBus data frame are shown in Table 2.

[0028] Table 2. TYPE values ​​and meanings in AutBus data frames

[0029] In the current field of industrial automation, the domestically developed industrial bus protocol AutBus has high bandwidth, high real-time performance, and unified addressing capability based on IPv6, which can effectively support the big data synchronous transmission needs in smart manufacturing scenarios. However, the existing AutBus protocol can only support data transmission of its own protocol and lacks the ability to support other mainstream industrial bus protocols such as Modbus, CAN, Profinet, and CC-Link. Industrial terminal devices of different bus protocol types cannot be connected to the same AutBus protocol network to achieve interconnection, which limits the networking flexibility of the AutBus protocol and makes it difficult to meet the actual needs of multi-protocol devices working together in smart manufacturing scenarios, thus restricting the large-scale promotion and application of the AutBus protocol.

[0030] To address the aforementioned issues, the main solution of this application embodiment is as follows: When the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to a preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame, and sends the AutBus bearer frame to the AutBus control node; the AutBus control node parses the AutBus bearer frame, determines the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter connected to the destination terminal device, and broadcasts the AutBus bearer frame; after receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated in the AutBus bearer frame to the destination terminal device.

[0031] In this embodiment, for ease of description, the following description will focus on a multi-protocol converged transmission system based on the AutBus protocol.

[0032] This application provides a solution that encapsulates heterogeneous raw protocol messages into AutBus bearer frames using a first AutBus protocol converter. This assigns a frame format recognizable by the AutBus protocol to non-AutBus heterogeneous protocol data (i.e., raw protocol messages), enabling heterogeneous protocol data (raw protocol messages) that would otherwise be unable to access the AutBus network to be transmitted within it, thus solving the problem that the AutBus protocol cannot directly carry heterogeneous protocol data. The AutBus bearer frame is then sent to the AutBus control node, which performs a parsing operation on the AutBus bearer frame. The node extracts the destination terminal device of the raw protocol message from the encapsulated AutBus bearer frame and matches it with the corresponding second AutBus protocol converter, thus defining a clear target path for the transmission of the heterogeneous protocol data (raw protocol messages). Finally, the AutBus control node broadcasts the AutBus bearer frame to each AutBus protocol converter. Only the matched second AutBus protocol converter sends the original protocol message to the destination terminal device, realizing the directional forwarding of heterogeneous protocol data in the AutBus network. This enables different terminal devices to interconnect through AutBus networking, solving the problem that the AutBus protocol network cannot directly forward heterogeneous industrial bus protocol data.

[0033] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a multi-protocol converged transmission device based on the AutBus protocol capable of achieving the above functions. The following description uses a multi-protocol converged transmission system based on the AutBus protocol as an example to illustrate this embodiment and the subsequent embodiments.

[0034] Based on this, the embodiments of this application provide a multi-protocol fusion transmission method based on the AutBus protocol, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the multi-protocol fusion transmission method based on the AutBus protocol in this application.

[0035] This application presents a multi-protocol converged transmission method based on the AutBus protocol, applied to a multi-protocol converged transmission system based on the AutBus protocol. The system consists of an AutBus control node and multiple AutBus protocol converters. The AutBus control node communicates with each AutBus protocol converter via the AutBus bus. (Reference) Figure 3 , Figure 3This paper demonstrates a multi-protocol converged transmission system architecture based on the AutBus protocol. Using the AutBus bus as a unified communication backbone, it enables interconnection and interoperability among various heterogeneous industrial bus protocol devices (terminal devices). The core of the multi-protocol converged transmission system consists of an AutBus control node and multiple AutBus protocol converters. The AutBus control node is responsible for global management and routing decisions. Each AutBus protocol converter is connected to the AutBus bus and connects to terminal devices of different bus protocol types, including Modbus devices, Profinet devices, CAN devices, and other protocol devices, through dedicated interfaces. Each AutBus protocol converter in the multi-protocol converged transmission system has protocol parsing and encapsulation capabilities. It can encapsulate the raw protocol messages sent by its connected terminal devices, such as Modbus protocol data, Profinet protocol data, or CAN protocol data, according to a preset multi-protocol bearer frame format, generating a standard AutBus bearer frame, which is then sent to the AutBus control node. Multiple raw protocol messages can be encapsulated within an AutBus bearer frame. After receiving an AutBus bearer frame, the AutBus control node can parse the destination terminal device address of the original protocol message according to its built-in device address mapping table, determine the second AutBus protocol converter used to forward the original protocol message, and broadcast the AutBus bearer frame to all AutBus protocol converters in the multi-protocol converged transmission system based on the AutBus protocol. Each AutBus protocol converter, upon receiving an AutBus bearer frame containing the original protocol message, parses the frame, extracts the destination terminal device address, and determines whether it is the second AutBus protocol converter used to forward the original protocol message through local address comparison. Only the second AutBus protocol converter forwards the original protocol message to the target device. This architecture enables the transparent and secure carrying and transmission of various heterogeneous industrial bus protocol data through the AutBus network without changing the existing terminal device's bus protocol, thereby solving the protocol silo problem in traditional industrial networks and significantly improving the flexibility, scalability, and integration efficiency of the multi-protocol converged transmission system based on the AutBus protocol.

[0036] The multi-protocol converged transmission system architecture based on the AutBus protocol achieves transparent carrying, centralized control, and converged transmission of multiple heterogeneous industrial protocol data on a single AutBus network through a three-layer design of AutBus control node - AutBus bus - AutBus protocol converter. This effectively simplifies the complex topology of traditional multi-network coexistence and enables converged transmission and collaborative work of multi-protocol devices (terminal devices supporting various bus protocols) under the same AutBus network, thereby improving the flexibility of AutBus networking and data transmission efficiency in smart manufacturing scenarios.

[0037] In this embodiment, the multi-protocol fusion transmission method based on the AutBus protocol includes steps 201-203: Step 201: When the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to the preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame, and sends the AutBus bearer frame to the AutBus control node.

[0038] Specifically, the first AutBus protocol converter is an AutBus protocol conversion device that is directly connected to the sending terminal device (i.e., the source terminal device). It is responsible for encapsulating the heterogeneous protocol messages (original protocol messages) of the source terminal device into bearer frames that can be recognized by AutBus. The source terminal device is an industrial field device that uses a non-AutBus protocol (such as Modbus, CAN, etc.), and the data it sends is the original protocol message.

[0039] In this application, the number of source terminal devices is greater than or equal to one, and the bus protocol type supported by the source terminal devices may include at least one of Modbus, CAN, CC-Link, Profibus-DP, I2C, HART, Profinet, TSN, or Ethernet. The number of corresponding original protocol messages is greater than or equal to one, and the original protocol messages may be at least one of Modbus protocol data, CAN protocol data, CC-Link protocol data, Profibus-DP protocol data, I2C protocol data, HART protocol data, Profinet protocol data, TSN protocol data, or Ethernet protocol data.

[0040] The original protocol message is a complete communication frame generated by the source terminal device according to the protocol specification of the bus protocol type it supports. For example, the Modbus RTU frame is

[01]

[03]

[00] [6B]

[00]

[01] [CRC]. The content and format of the original protocol message are not modified in this application.

[0041] The preset multi-protocol bearer frame format is an extended AutBus frame structure defined in this application, which consists of an outer AutBus frame header (including the TYPE field, Fragment_no field, LENGTH field, and CRC field) and an inner payload (PAYLOAD) field. The inner payload (PAYLOAD) field contains at least one protocol packet entity (PROTOCOL_ENTRY) for uniformly encapsulating heterogeneous protocol data.

[0042] To address the current issue that the AutBus protocol cannot carry multiple bus protocols, this application designs an improved AutBus bearer frame, namely the AutBus bearer frame with the aforementioned preset multi-protocol bearer frame format, which can carry protocol data of multiple bus protocol types through the AutBus bearer frame.

[0043] refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of the AutBus bearer frame in the preset multi-protocol bearer frame format provided in this application. The AutBus bearer frame structure adopts a layered nested design to achieve unified encapsulation and transmission of heterogeneous bus protocol data. Specifically, the AutBus bearer frame is divided into three logical levels from top to bottom. The outermost layer is the frame header and frame trailer of the standard AutBus frame. The frame header includes a type (TYPE, 1 byte) field, a fragment number (Fragment_no, 4 bits) field, and a length (LENGTH, 12 bits) field. The type (TYPE) field is fixed to a specific value in this preset format, namely the preset multi-protocol bearer value 0x00, used to uniquely identify this frame as a multi-protocol bearer frame. The fragment number (Fragment_no) field and the length (LENGTH) field work together for data fragmentation management and payload field length indication. The frame trailer includes a cyclic redundancy check (CRC, 2 bytes) field to ensure the integrity of the entire frame during transmission.

[0044] The core of the AutBus bearer frame lies in the payload (PAYLOAD) field of the intermediate layer. The payload (PAYLOAD) field contains, in sequence, the number of protocol packet entities (PROTOCOL_ENTRY_NUM, 1 byte), the total length of protocol packet entities (PROTOCOL_LENGTH, 2 bytes), and at least one protocol packet entity (PROTOCOL_ENTRY, n bytes). The PROTOCOL_ENTRY_NUM field indicates the number of protocol packet entities carried in the current AutBus bearer frame, supporting the encapsulation of multiple heterogeneous protocol data (i.e., the aforementioned multiple original protocol frames) within a single frame (AutBus bearer frame); the PROTOCOL_LENGTH field defines the total byte length of all protocol packet entities; each protocol packet entity (PROTOCOL_ENTRY) is an independent protocol encapsulation unit, containing four sub-fields: protocol type identifier (PRO_TYPE, 1 byte), instance length (LENGTH, 12 bytes), encryption mode (MODE, 4 bytes), and data (DATA, y bytes). The protocol type identifier (PRO_TYPE) field indicates the heterogeneous protocol type of the bus protocol data (i.e., the original protocol frame) carried within the protocol packet entity; the instance length (LENGTH) field defines the length of the DATA field; the encryption mode (MODE) field defines the encryption mode of the data (DATA) field (such as SM4, AES, etc.); and the data (DATA field) carries the specific heterogeneous protocol message content (i.e., the original protocol frame). The AutBus bearer frame structure, through its layered and nested design, enables the unified encapsulation and transmission of various heterogeneous industrial protocol data within the same AutBus message. This provides a standardized technical foundation for the AutBus network to carry multiple types of bus protocol data, thereby solving the problem that existing technologies cannot directly support multiple industrial bus protocols.

[0045] Referring to Table 3, the data format of the payload field (PAYLOAD) in the AutBus bearer frame provided in this application can be as shown in Table 3.

[0046] Table 3. Data format of the payload field (PAYLOAD) in the AutBus bearer frame.

[0047] Referring to Table 4, the data format of the protocol packet entity (PROTOCOL_ENTRY) in the payload field (PAYLOAD) of the AutBus bearer frame provided in this application can be as shown in Table 4.

[0048] Data format of the protocol packet entity (PROTOCOL_ENTRY) in the payload field (PAYLOAD) of Table 4

[0049] In some embodiments, when the first AutBus protocol converter receives the original protocol message sent by its subordinate source terminal device (such as a Modbus device or a CAN device), it encapsulates the original protocol message according to a preset multi-protocol bearer frame format. Specifically, the first AutBus protocol converter can determine the corresponding protocol type identifier (PRO_TYPE) field according to the bus protocol type used by the source terminal device, and embed the original protocol message as a data (DATA) field into a protocol packet entity (PROTOCOL_ENTRY). The protocol packet entity also includes metadata such as the protocol type identifier (PRO_TYPE) field and the data length (LENGTH) field. Subsequently, the protocol packet entity is organized into the payload (PAYLOAD) field of the AutBus frame, and the number of protocol packet entities (PROTOCOL_ENTRY_NUM) field and the total length of the protocol packet entities (PROTOCOL_LENGTH) field are set to indicate the number and total length of the protocol packet entities. Finally, the TYPE field in the frame header is set to a preset multi-protocol bearer value (e.g., 0x00), generating an AutBus bearer frame conforming to the AutBus specification. The AutBus protocol converter maps heterogeneous protocol data (the original protocol messages of various bus protocol types) into a standard format recognizable and transmittable by the AutBus network—the multi-protocol bearer frame format. This provides a foundation for subsequent control node parsing and forwarding, enabling unified bearer of multiple industrial protocols in AutBus networking and achieving transparent and converged transmission of multiple protocols on the AutBus network.

[0050] Step 202: The AutBus control node parses the AutBus bearer frame, determines the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter that is attached to the destination terminal device, and broadcasts the AutBus bearer frame.

[0051] Specifically, the AutBus control node is the core scheduling unit of the entire multi-protocol converged transmission system based on the AutBus protocol. It is responsible for network management, data parsing, route matching, and broadcast forwarding, serving as the central hub for multi-protocol converged transmission. The destination terminal device is the device to which the original protocol message ultimately needs to be delivered. The bus protocol type supported by the destination terminal device is the same as that supported by the source terminal device. The destination terminal device is connected to the second AutBus protocol converter. The second AutBus protocol converter is the protocol adaptation node connected to the destination terminal device. It is responsible for decapsulating the original protocol message within the AutBus bearer frame and sending it to the destination terminal device. It is the exit point for the AutBus network to deliver data to the target device.

[0052] In some embodiments, after receiving an AutBus bearer frame from the first converter, the AutBus control node first verifies the integrity of the AutBus bearer frame and confirms that its type is a multi-protocol bearer frame. Then, the AutBus control node parses the payload field of the AutBus bearer frame, and from the data field of the protocol packet entity contained in the payload field, locates and extracts the destination terminal device address contained in the original protocol message. Next, using this destination terminal device address as a key index, the AutBus control node queries its internally dynamically maintained device address mapping table. By looking up the table, the AutBus control node determines the destination terminal device corresponding to the destination terminal device address, and the second AutBus protocol converter that mounts the destination terminal device, thereby completing an accurate routing decision and providing a basis for subsequent data forwarding.

[0053] Step 203: After receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated in the AutBus bearer frame to the destination terminal device.

[0054] Specifically, the second AutBus protocol converter is the AutBus protocol converter responsible for final forwarding, determined based on the address of the destination terminal device; the destination terminal device is the receiving device (terminal device) to which the original protocol message is to be received; the original protocol message is heterogeneous protocol data sent by the source terminal device and encapsulated in an AutBus bearer frame.

[0055] In some embodiments, the AutBus control node broadcasts the AutBus bearer frame to all AutBus protocol converters. Upon receiving the AutBus bearer frame, each AutBus converter independently parses the encapsulated destination terminal device address and compares it with its own list of connected terminal device addresses. Only when a match is found is the AutBus converter identified as the second AutBus protocol converter. It then extracts the original protocol message from the AutBus bearer frame (decrypting it if necessary) and sends the original protocol message to the connected destination terminal device through the corresponding physical interface. Other non-target AutBus protocol converters discard the original protocol message. By combining broadcast distribution with local filtering, accurate forwarding of heterogeneous protocol data (original protocol messages) in the AutBus network is achieved, ultimately completing the final delivery of protocol data (original protocol messages) for various bus protocol types. This enables different types of terminal devices to interconnect within the same AutBus network. Simultaneously, the destination terminal device can receive its native protocol message without any modification, supporting converged communication of multi-protocol data.

[0056] The multi-protocol fusion transmission method based on the AutBus protocol provided in this application, when the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, encapsulates the original protocol message according to a preset multi-protocol bearer frame format, adds an AutBus protocol adaptation shell to the heterogeneous protocol data (i.e., the original protocol message), and obtains the corresponding AutBus bearer frame, thus standardizing various types of heterogeneous protocol messages into data units that can be transmitted over the AutBus network. Next, the AutBus bearer frame is sent to the AutBus control node, which parses the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter connected to the destination terminal device, thus clarifying the target path for heterogeneous protocol data transmission. The AutBus control node broadcasts the AutBus bearer frame to each AutBus protocol converter. Each AutBus protocol converter parses the AutBus bearer frame and determines whether it is the target receiver of the original protocol message encapsulated within the AutBus bearer frame (the second AutBus protocol converter). If so, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device, completing the closed-loop transmission of heterogeneous protocol data (i.e., the original protocol message) within the AutBus network. This solves the technical problem that existing AutBus protocol networks cannot directly carry and forward multiple heterogeneous bus protocol data, enabling interconnection and interoperability between different terminal devices.

[0057] In some embodiments, the steps of the AutBus control node parsing the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter mounted on the destination terminal device include: The AutBus control node parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The AutBus control node parses the destination terminal device address from the original protocol message; The AutBus control node queries the first device address mapping table based on the destination terminal device address to determine the target converter identifier of the AutBus protocol converter corresponding to the destination terminal device address. The first device address mapping table records the correspondence between the address of each terminal device and the converter identifier of the AutBus protocol converter attached to it. The AutBus control node identifies the target converter as the corresponding AutBus protocol converter and determines it as the second AutBus protocol converter. It also identifies the terminal device corresponding to the destination terminal device address as the destination terminal device corresponding to the original protocol message.

[0058] Specifically, the payload (PAYLOAD) field is the portion of the AutBus frame that carries the actual data. In this application, the payload (PAYLOAD) field may contain one or more protocol packet entities (PROTOCOL_ENTRY). The protocol packet entity (PROTOCOL_ENTRY) is a structured data unit within the PAYLOAD field, containing subfields such as protocol type identifier (PRO_TYPE), total protocol packet length (LENGTH), encryption mode (MODE), and DATA. The DATA field encapsulates the original protocol message (which can be ciphertext). The destination terminal device address is the address of the final terminal device to which the message is intended, parsed from the original protocol message, such as a Modbus slave address or CAN node ID. The first device address mapping table is a global table dynamically generated and maintained by the AutBus control node during system initialization by collecting information reported by each AutBus protocol converter (which converter is connected to which terminal device address). It records the static correspondence between the address of each terminal device in the AutBus network and the converter identifier of the AutBus protocol converter directly connected to it. The target converter is identified by the number of the AutBus protocol converter that mounts the destination terminal device.

[0059] As an example, in the multi-protocol converged transmission system based on the AutBus protocol of this application, the AutBus control node is responsible for centralized routing management of heterogeneous protocol communication. After receiving an AutBus bearer frame from the first AutBus protocol converter, the AutBus control node first performs a frame structure integrity check. If the check passes, the AutBus control node parses the frame header of the AutBus bearer frame, confirming that the type field of the AutBus bearer frame is a preset multi-protocol bearer identifier, thus determining that its payload field needs to be processed according to the preset multi-protocol bearer format. The AutBus control node performs structured parsing of the AutBus bearer frame, extracting the payload field (i.e., the PAYLOAD field). The payload field encapsulates a complete protocol packet entity (PROTOCOL_ENTRY). The AutBus control node further reads the original content of the data field (DATA field) from the protocol packet entity to obtain the original protocol message sent by the source terminal device, ensuring the integrity and originality of the message content. Subsequently, the AutBus control node, based on the protocol type of the original protocol message (pre-identified by the PRO_TYPE field of the protocol packet entity), parses the destination terminal device address from the original protocol message according to the format specifications of the corresponding heterogeneous industrial protocol. This destination terminal device address is the native protocol address of the destination terminal device, such as the Modbus slave address, CAN node ID, Profinet device name, etc., and is a unique identifier for the destination terminal device. Next, the AutBus control node calls the first device address mapping table pre-configured and maintained locally. Using the parsed destination terminal device address as the query keyword, the AutBus control node quickly searches for the converter identifier of the AutBus protocol converter corresponding to the destination terminal device address, i.e., the target converter identifier. Finally, the AutBus control node identifies the AutBus protocol converter corresponding to the target converter identifier as the second AutBus protocol converter that mounts the destination terminal device, and simultaneously identifies the terminal device corresponding to the destination terminal device address as the final recipient of the original protocol message (the destination terminal device). Through a closed-loop operation of frame parsing, address extraction, and mapping query, destination addressing and routing of heterogeneous protocol messages are achieved, providing accurate target direction for subsequent data broadcasting and forwarding, so as to ensure that terminal devices of different protocol types can achieve precise point-to-point communication in AutBus networking.

[0060] In some embodiments, before the step of the AutBus control node querying the first device address mapping table based on the destination terminal device address, the method further includes: The AutBus control node receives device registration information reported by each AutBus protocol converter. The device registration information includes the converter identifier of the AutBus protocol converter and the address of at least one terminal device connected to the AutBus protocol converter. The AutBus control node constructs the first device address mapping table based on all received device registration information.

[0061] Specifically, the device registration information is the configuration data reported by the AutBus protocol converter to the AutBus control node. It consists of two parts: the converter identifier (e.g., ID="TN_03") and the address of at least one terminal device connected to the AutBus protocol converter (e.g., [0x01, 0x02]). The address of the terminal device is the communication address of the terminal device.

[0062] As an example, during system initialization, each AutBus protocol converter proactively reports its device registration information to the AutBus control node. This registration information includes the converter's unique identifier and the addresses of one or more connected terminal devices, such as Modbus slave addresses and CAN node IDs. After receiving the device registration information from all AutBus protocol converters, the AutBus control node summarizes and structures this information, establishing a one-to-one correspondence between each terminal device's address and its corresponding AutBus protocol converter identifier. This establishes a first device address mapping table, which uses the terminal device address as the index key and the corresponding converter identifier as the value, forming a routing index covering the entire network. Furthermore, the first device address mapping table supports dynamic updates. When a terminal device is added / removed or a converter changes, the AutBus control node adjusts the table entries in real time by receiving updated registration information, ensuring accurate and effective mapping relationships and providing a reliable data foundation for quickly querying the converter to which a destination terminal belongs.

[0063] In some embodiments, the multi-protocol fusion transmission method based on the AutBus protocol further includes: The AutBus control node queries the second device address mapping table based on the destination terminal device address to determine the target bus protocol type of the terminal device corresponding to the destination terminal device address. The second device address mapping table records the correspondence between the address of each terminal device and the corresponding bus protocol type supported by the terminal device. The AutBus control node determines whether the destination terminal device is connected to the second AutBus protocol converter based on the target bus protocol type of the destination terminal device, the target converter identifier of the second AutBus protocol converter, and the pre-configured global mapping table. If so, execute the step of broadcasting the AutBus bearer frame; The global mapping table records a many-to-many mapping relationship between the converter identifier of each AutBus protocol converter and the bus protocol type supported by at least one terminal device connected to the AutBus protocol converter.

[0064] Specifically, bus protocol types can include Modbus, CAN, CC-Link, Profibus-DP, I2C, HART, Profinet, TSN, or Ethernet, etc. The global mapping table is a pre-configured association table in the AutBus control node, recording the many-to-many relationship between the converter identifier of each AutBus protocol converter and the bus protocol types supported by the connected terminal devices (one AutBus protocol converter can connect to multiple protocol devices, and one bus protocol can correspond to multiple AutBus protocol converters). (See reference...) Figure 5 , Figure 5 This application provides a global mapping representation intent.

[0065] As an example, after resolving the destination terminal device address, the AutBus control node queries the second device address mapping table maintained by the AutBus control node. This second device address mapping table is a pre-configured or dynamically updated association table that explicitly records the one-to-one correspondence between the native protocol address of each terminal device in the AutBus network and its supported bus protocol type (such as Modbus, CAN, Profinet, etc.). The AutBus control node uses the destination terminal device address as the search keyword to quickly match and determine the target bus protocol type corresponding to the destination terminal device address, providing a core basis for subsequent compatibility judgment. Subsequently, the AutBus control node retrieves the pre-configured global mapping table. This global mapping table has a many-to-many association structure and completely records the correspondence between the converter identifier of each AutBus protocol converter and the bus protocol type supported by the connected terminal device (one converter can connect to terminal devices of multiple protocol types, and one protocol type can correspond to multiple converters). The AutBus control node uses the determined target bus protocol type and the target converter identifier of the second AutBus protocol converter as query conditions to search and match in the global mapping table. It determines whether the AutBus protocol converter corresponding to the target converter identifier supports connecting terminal devices of the target bus protocol type, indirectly verifying whether the destination terminal device is actually connected to the second AutBus protocol converter. If the search result is a successful match (i.e., the destination terminal device is indeed connected to the second AutBus protocol converter), the AutBus control node determines the route is valid and proceeds to broadcast the AutBus bearer frame to each AutBus protocol converter. If the search result is a mismatch (i.e., the destination terminal device and the second AutBus protocol converter have no affiliation, resulting in a routing error), the AutBus control node determines the original protocol message as invalid data, discards it, and terminates the subsequent transmission process. By employing a dual verification mechanism of protocol type matching and converter adaptation, a filtering barrier is constructed before data forwarding. This avoids invalid forwarding issues caused by address mapping table errors, device access changes, or protocol incompatibility, enhances the reliability of multi-protocol converged transmission, filters invalid routing data, prevents erroneous forwarding from consuming network resources, and ensures the accuracy and efficiency of data transmission.

[0066] In some embodiments, before the step of the AutBus control node determining whether the destination terminal device is connected to the second AutBus protocol converter based on the destination terminal device's target bus protocol type, the target converter identifier of the second AutBus protocol converter, and a pre-configured global mapping table, the method further includes: The AutBus control node receives device access information reported by each AutBus protocol converter. The device access information includes the converter identifier of the AutBus protocol converter and the bus protocol type supported by at least one terminal device connected to the AutBus protocol converter. The AutBus control node constructs a global mapping table based on all received device access information.

[0067] Specifically, the converter identifier is a unique identifier for each AutBus protocol converter within the AutBus network, such as a device ID, used to uniquely identify a physical converter entity in the global mapping table. The bus protocol types supported by the terminal devices are the industrial bus protocol standards that the various terminal devices connected to the AutBus protocol converter can communicate with, such as Modbus, CAN, CC-Link, Process Field Bus – Decentralized Peripherals (Profibus-DP), Inter-Integrated Circuit (I2C), Highway Addressable Remote Transducer Protocol (HART), Profinet, Time-Sensitive Networking (TSN), Ethernet, etc. A single AutBus protocol converter can connect terminal devices supporting multiple different bus protocols.

[0068] As an example, during the AutBus network initialization phase, when adding new AutBus protocol converters, or when terminal devices are connected / changed, each AutBus protocol converter proactively initiates a device access information reporting request to the AutBus control node. The reported device access information explicitly includes the converter's own converter identifier (ensuring unique identification within the AutBus network) and the bus protocol type supported by each terminal device connected to it. If an AutBus protocol converter connects to terminal devices with multiple protocol types, all corresponding bus protocol types are reported simultaneously. For example, if an AutBus protocol converter with converter identifier 3 connects to Modbus and CAN devices, it reports two sets of associated data: "3-Modbus" and "3-CAN". After receiving the device access information reported by each AutBus protocol converter, the AutBus control node can first perform data validity verification, such as checking whether the converter identifier of the AutBus protocol converter is duplicated, whether the bus protocol type format conforms to the network support specifications, filtering invalid or duplicate reported data to ensure the accuracy of the basic data. Subsequently, the AutBus control node constructs a global mapping table based on the access information of all verified devices, following a many-to-many association rule. This global mapping table supports dynamic updates; when an AutBus protocol converter adds / removes a terminal device or changes its bus protocol type, the corresponding AutBus protocol converter reports the updated device access information to the control node. Upon receiving this information, the AutBus control node adjusts the entries in the global mapping table in real time, ensuring the timeliness of the association relationships. By constructing the global mapping table in advance, an efficient query basis is provided for subsequently determining device affiliation based on the target bus protocol type and target converter identifier, avoiding erroneous forwarding due to protocol type mismatches, and further ensuring the reliability of multi-protocol converged transmission and the rational utilization of network resources.

[0069] In some embodiments, the step of the second AutBus protocol converter sending the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device after receiving the AutBus bearer frame includes: The second AutBus protocol converter receives AutBus bearer frames; The second AutBus protocol converter parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The second AutBus protocol converter parses the destination terminal device address from the original protocol message and determines whether the destination terminal device address is the terminal device address connected to the second AutBus protocol converter. If so, the second AutBus protocol converter will send the original protocol message to the destination terminal device.

[0070] Specifically, the protocol packet entity (PROTOCOL_ENTRY) is the basic data unit in the payload (PAYLOAD), composed of the PRO_TYPE, LENGTH, MODE, and DATA fields. The DATA field encapsulates the original protocol message. The original protocol message is the native industrial protocol command, such as a Modbus read command, issued by the source terminal device without semantic modification, and is the content to be delivered to the destination device.

[0071] As an example, see reference Figure 6 The AutBus protocol converter connects to the terminal device and can act as a forwarding device for heterogeneous protocol data, sending heterogeneous protocol data to the destination terminal device. The AutBus protocol converter integrates multiple protocol processing modules such as CAN, Modbus, and Profinet. Figure 6 The CAN processing module, Modbus processing module, Profinet processing module, etc. shown are used to adapt to terminal devices with different bus protocol types; the AutBus bearer frame is a standard AutBus frame that encapsulates heterogeneous raw protocol data. Its payload field contains multiple protocol packet entities, each corresponding to data of a bus protocol type; the raw protocol message is heterogeneous protocol data such as CAN, Modbus, or Profinet sent by the source terminal device.

[0072] When the AutBus protocol converter receives an AutBus bearer frame broadcast by the AutBus control node, it first uses its internal general-purpose receiving module to parse the payload field (PAYLOAD) of the AutBus bearer frame, extracting structured data containing multiple protocol packet entities. This PAYLOAD field contains PROTOCOL_ENTRY_NUM, PROTOCOL_LENGTH, and one or more PROTOCOL_ENTRY protocol packet entities, each corresponding to data from a different bus protocol. For example, if a protocol packet entity contains Modbus protocol data, the corresponding Modbus processing module will read from that protocol packet entity and reconstruct the original Modbus message content (original protocol message). Subsequently, the AutBus protocol converter parses the acquired original protocol message, extracting the destination terminal device address, such as the Modbus slave ID. Next, the AutBus protocol converter compares its locally maintained list of connected terminal device addresses with the destination address. If a match is found, meaning the destination terminal device address belongs to its connected terminal device, the AutBus protocol converter is identified as the second AutBus protocol converter. The original protocol message is then forwarded to the target terminal device via the corresponding protocol processing module (such as a Modbus processing module). If a mismatch occurs, such as the destination terminal device address being the address of Profinet device B, but no Profinet device B is connected to this AutBus protocol converter, the original protocol message is discarded to avoid invalid processing. This distributed address filtering mechanism ensures that only the target converter (the second AutBus protocol converter) forwards the corresponding data, guaranteeing that heterogeneous protocol data of various categories is delivered to the destination terminal device only by the correct converter. This effectively avoids invalid forwarding, reduces network load, and ensures the accuracy and security of communication.

[0073] In some embodiments, the step of reading the data field content from the protocol packet entity to obtain the original protocol message includes: The second AutBus protocol converter parses the protocol packet entity, extracts the data field content to obtain encrypted protocol data, and extracts the encryption mode field content to obtain an encryption mode identifier that indicates the encryption mode of the original protocol message; The second AutBus protocol converter determines the encryption mode of the encrypted protocol data based on the encryption mode identifier and obtains the decryption key corresponding to the encryption mode. The second AutBus protocol converter uses the decryption key to decrypt the encrypted protocol data, obtaining the original plaintext protocol message.

[0074] Specifically, the data field (DATA) is the actual payload portion of the protocol packet entity (PROTOCOL_ENTRY), storing the encrypted original protocol message (i.e., encrypted protocol data), not plaintext data. The encrypted protocol data is ciphertext generated by the source terminal device encrypting the original protocol message (such as Modbus commands) using a key, ensuring the confidentiality of the original protocol message during transmission over the AutBus backbone. The encryption mode field (MODE) is a field in the protocol packet entity (PROTOCOL_ENTRY) used to indicate the specific algorithm used to encrypt the DATA field content, such as AES-128, SM4, etc. The encryption mode is identified by the specific value of the MODE field, such as 0, 1, 2, or 3. Each value corresponds to a predefined encryption algorithm. For example, 0 indicates AES-128, 1 indicates Advanced Encryption Standard with 256-bit key (AES-256), 2 indicates SM4 Block Cipher Algorithm (SM4), and 3 indicates ZUC Stream Cipher Algorithm (ZUC), etc. The decryption key is the decryption key corresponding to the encryption mode, used to decrypt the encrypted protocol data to recover the original plaintext protocol message. The encrypted protocol data is the encrypted protocol data stored in the data field, i.e., the ciphertext form of the original protocol message.

[0075] In the multi-protocol converged transmission system based on the AutBus protocol of this application, to ensure the secure transmission of heterogeneous protocol data in the AutBus network, the original protocol message is encrypted at the source terminal device and encapsulated in the protocol packet entity of the AutBus bearer frame. When the second AutBus protocol converter receives the AutBus bearer frame, it needs to perform decryption to restore the original instructions. As an example, the AutBus protocol converter parses the protocol packet entity (PROTOCOL_ENTRY), extracts the data field content, obtains the encrypted protocol data, and reads the encryption mode (MODE) field content to obtain the encryption mode identifier, such as 1 indicating the encryption algorithm is AES-256, 2 indicating the encryption algorithm is SM4, and 3 indicating the encryption algorithm is ZUC. Subsequently, the encryption algorithm type used is determined according to the encryption mode identifier, and the decryption key corresponding to the encryption mode, which has been pre-negotiated or configured with the communication peer, is retrieved from the local secure storage area (such as a security chip or protected configuration area) of the AutBus protocol converter. Finally, the decryption key and the determined algorithm are used to perform decryption operations on the encrypted protocol data, thereby recovering the original protocol message in plaintext form. By using encryption mode identifiers, dynamic support for multiple encryption algorithms is achieved, balancing security, compliance, and system flexibility, providing end-to-end security for transparent multi-protocol converged communication. Decryption of encrypted protocol data ensures that only legitimate nodes holding the corresponding keys can obtain the original plaintext protocol messages, effectively preventing heterogeneous protocol data from being eavesdropped on or tampered with during transmission, thus enhancing the security of multi-protocol converged transmission.

[0076] In some embodiments, the step of encapsulating the original protocol message according to a preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame includes: The first AutBus protocol converter determines the corresponding encryption mode and encryption key, as well as the corresponding protocol type identifier, based on the bus protocol type supported by the source terminal device. The first AutBus protocol converter uses encryption keys and encryption modes to encrypt the original protocol messages and generate encrypted protocol data. The first AutBus protocol converter constructs a protocol packet entity containing encrypted protocol data. The protocol packet entity includes a protocol type identifier, a data length field indicating the length of the encrypted protocol data, an encryption mode identifier indicating the encryption mode of the original protocol message, and the encrypted protocol data. The first AutBus protocol converter constructs the payload field of the AutBus bearer frame. The payload field includes a protocol packet entity number field indicating the number of protocol packet entities, a protocol packet total length field indicating the total length of the protocol packet entities, and the protocol packet entities. The first AutBus protocol converter sets the frame header of the AutBus bearer frame and updates the value of the type field in the frame header to the preset multi-protocol bearer value. The first AutBus protocol converter forms a complete AutBus bearer frame based on the updated frame header and payload fields.

[0077] Specifically, the original protocol message is a complete data frame generated by the source terminal device, conforming to its own bus protocol (such as Modbus or CAN), containing all native fields such as address, function code, data, and checksum. The preset multi-protocol bearer frame format is a data frame structure specifically extended for carrying multiple protocols by the AutBus protocol proposed in this application. The TYPE field in the frame header of the AutBus bearer frame has a specific reserved value, i.e., a preset multi-protocol bearer value. In this application, the preset multi-protocol bearer value is 0x00, and the payload of the AutBus bearer frame has a specific hierarchical structure to accommodate multiple protocol packet entities. The protocol type identifier is an enumerated value used to uniquely identify different industrial bus protocols, such as 0x01 representing Modbus and 0x02 representing CAN, corresponding to the PRO_TYPE field in the protocol packet entity. The frame header of the AutBus bearer frame contains a TYPE field, which identifies the frame type. In this application, the TYPE field is set to a preset multi-protocol bearer value, such as 0x00, indicating that the frame is a multi-protocol bearer frame, distinguishing it from ordinary AutBus data frames.

[0078] In the multi-protocol converged transmission system based on the AutBus protocol of this application, to achieve secure and standardized transmission of heterogeneous bus protocols in the AutBus network, the source-end AutBus protocol converter performs structured encapsulation of the original protocol messages. As an example, when the first AutBus protocol converter receives the original protocol message sent by its downstream source terminal device (such as a Modbus device), it first determines the corresponding protocol type identifier (e.g., 0x01), encryption mode (e.g., SM4), and the encryption key pre-shared with the target communicator from its local configuration, based on the bus protocol type supported by the source terminal device (e.g., Modbus). Subsequently, the original protocol message is encrypted using this encryption key and encryption mode to generate encrypted protocol data. Next, a protocol packet entity (PROTOCOL_ENTRY) is constructed, which sequentially includes the protocol type identifier, a data length field (LENGTH) indicating the length of the encrypted protocol data bytes, an encryption mode identifier indicating the encryption algorithm used (2 represents SM4), and the encrypted protocol data. Building upon this foundation, the payload field (PAYLOAD) of the AutBus bearer frame is further constructed. This payload field includes a protocol packet entity count field (PROTOCOL_ENTRY_NUM) indicating the number of protocol packet entities, a protocol packet length field (PROTOCOL_LENGTH) indicating the total number of bytes of all protocol packet entities, and the complete protocol packet entities mentioned above. Subsequently, the frame header of the AutBus frame is set, with its TYPE field set to a preset multi-protocol bearer value, such as 0x00, to identify the frame as a multi-protocol bearer frame. Finally, the frame header and payload field are combined, and a CRC checksum is calculated to form a complete AutBus bearer frame. By converting heterogeneous, plaintext bus protocol data into unified, encrypted, and structured AutBus standard data units (AutBus bearer frames in a preset multi-protocol bearer frame format), the foundation is laid for the convergence, secure, and efficient transmission of multi-protocol data in AutBus networks.

[0079] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-protocol fusion transmission method based on the AutBus protocol in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0080] This application also provides a multi-protocol converged transmission device based on the AutBus protocol. Please refer to [link / reference]. Figure 7 The multi-protocol converged transmission device based on the AutBus protocol includes: The multi-protocol encapsulation module 701 is used to encapsulate the original protocol message according to the preset multi-protocol bearer frame format when the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, to obtain the corresponding AutBus bearer frame, and send the AutBus bearer frame to the AutBus control node. The parsing module 702 is used by the AutBus control node to parse the AutBus bearer frame, determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter that is attached to the destination terminal device, and broadcast the AutBus bearer frame. The data transmission module 703 is used to send the original protocol message encapsulated in the AutBus bearer frame to the destination terminal device after the second AutBus protocol converter receives the AutBus bearer frame.

[0081] The multi-protocol fusion transmission device based on the AutBus protocol provided in this application, employing the multi-protocol fusion transmission method based on the AutBus protocol in the above embodiments, can solve the technical problem that existing AutBus protocol networks cannot directly carry and forward data from multiple heterogeneous industrial bus protocols. Compared with the prior art, the beneficial effects of the multi-protocol fusion transmission device based on the AutBus protocol provided in this application are the same as those of the multi-protocol fusion transmission method based on the AutBus protocol provided in the above embodiments, and other technical features in the multi-protocol fusion transmission device based on the AutBus protocol are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0082] This application provides a multi-protocol converged transmission device based on the AutBus protocol. The multi-protocol converged transmission device based on the AutBus protocol includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the multi-protocol converged transmission method based on the AutBus protocol in the above embodiment 1.

[0083] The following is for reference. Figure 8 This document illustrates a structural diagram of a multi-protocol converged transmission device based on the AutBus protocol suitable for implementing embodiments of this application. The multi-protocol converged transmission device based on the AutBus protocol in these embodiments may include, but is not limited to, mobile terminals such as laptops, tablets (Portable Application Description, PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8The multi-protocol converged transmission device based on the AutBus protocol shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0084] like Figure 8 As shown, a multi-protocol converged transmission device based on the AutBus protocol may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the multi-protocol converged transmission device based on the AutBus protocol. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the AutBus-based multi-protocol converged transmission device to wirelessly or wiredly communicate with other devices to exchange data. Although the figure shows a multi-protocol converged transmission device based on the AutBus protocol with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0085] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0086] The multi-protocol fusion transmission device based on the AutBus protocol provided in this application, employing the multi-protocol fusion transmission method based on the AutBus protocol in the above embodiments, can solve the technical problem that existing AutBus protocol networks cannot directly carry and forward data from multiple heterogeneous industrial bus protocols. Compared with the prior art, the beneficial effects of the multi-protocol fusion transmission device based on the AutBus protocol provided in this application are the same as those of the multi-protocol fusion transmission method based on the AutBus protocol provided in the above embodiments, and other technical features in this multi-protocol fusion transmission device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0087] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0088] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0089] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the multi-protocol fusion transmission method based on the AutBus protocol in the above embodiments.

[0090] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0091] The aforementioned computer-readable storage medium may be included in a multi-protocol converged transmission device based on the AutBus protocol; or it may exist independently and not be assembled into a multi-protocol converged transmission device based on the AutBus protocol.

[0092] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a multi-protocol converged transmission device based on the AutBus protocol, the multi-protocol converged transmission device based on the AutBus protocol performs the following: When the first AutBus protocol converter receives an original protocol message sent by a source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to a preset multi-protocol bearer frame format to obtain a corresponding AutBus bearer frame, and sends the AutBus bearer frame to the AutBus control node; the AutBus control node parses the AutBus bearer frame, determines the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter connected to the destination terminal device, and broadcasts the AutBus bearer frame; after receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device.

[0093] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0096] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-protocol fusion transmission method based on the AutBus protocol. This solves the technical problem that existing AutBus protocol networks cannot directly carry and forward data from multiple heterogeneous industrial bus protocols. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-protocol fusion transmission method based on the AutBus protocol provided in the above embodiments, and will not be repeated here.

[0097] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-protocol fusion transmission method based on the AutBus protocol as described above.

[0098] The computer program product provided in this application can solve the technical problem that existing AutBus protocol networks cannot directly carry and forward data from multiple heterogeneous industrial bus protocols. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-protocol fusion transmission method based on the AutBus protocol provided in the above embodiments, and will not be repeated here.

[0099] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-protocol fusion transmission method based on the AutBus protocol, characterized in that, The multi-protocol fusion transmission method based on the AutBus protocol, applied to a multi-protocol fusion transmission system consisting of an AutBus control node and multiple AutBus protocol converters, includes: When the first AutBus protocol converter receives the original protocol message sent by the source terminal device connected to the first AutBus protocol converter, it encapsulates the original protocol message according to the preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame, and sends the AutBus bearer frame to the AutBus control node. The AutBus control node parses the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter that is attached to the destination terminal device, and broadcasts the AutBus bearer frame. After receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device.

2. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 1, characterized in that, The steps by which the AutBus control node parses the AutBus bearer frame to determine the destination terminal device corresponding to the original protocol message and the second AutBus protocol converter mounted on the destination terminal device include: The AutBus control node parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The AutBus control node parses the destination terminal device address from the original protocol message; The AutBus control node queries the first device address mapping table based on the destination terminal device address to determine the target converter identifier of the AutBus protocol converter corresponding to the destination terminal device address. The first device address mapping table records the correspondence between the address of each terminal device and the converter identifier of the AutBus protocol converter attached to it. The AutBus control node identifies the AutBus protocol converter corresponding to the target converter identifier as the second AutBus protocol converter, and identifies the terminal device corresponding to the destination terminal device address as the destination terminal device corresponding to the original protocol message.

3. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 2, characterized in that, Before the step of the AutBus control node querying the first device address mapping table based on the destination terminal device address, the method further includes: The AutBus control node receives device registration information reported by each of the AutBus protocol converters. The device registration information includes the converter identifier of the AutBus protocol converter and the address of at least one terminal device connected to the AutBus protocol converter. The AutBus control node constructs the first device address mapping table based on all the device registration information it has received.

4. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 2, characterized in that, The multi-protocol fusion transmission method based on the AutBus protocol also includes: The AutBus control node queries the second device address mapping table based on the destination terminal device address to determine the target bus protocol type of the terminal device corresponding to the destination terminal device address. The second device address mapping table records the correspondence between the address of each terminal device and the corresponding bus protocol type supported by the terminal device. The AutBus control node determines whether the destination terminal device is connected to the second AutBus protocol converter based on the target bus protocol type of the destination terminal device, the target converter identifier of the second AutBus protocol converter, and a pre-configured global mapping table. If so, perform the step of broadcasting the AutBus bearer frame; The global mapping table records a many-to-many mapping relationship between the converter identifier of each AutBus protocol converter and the bus protocol type supported by at least one terminal device attached to the AutBus protocol converter.

5. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 4, characterized in that, Before the step of the AutBus control node determining whether the destination terminal device is connected to the second AutBus protocol converter based on the target bus protocol type of the destination terminal device, the target converter identifier of the second AutBus protocol converter, and a pre-configured global mapping table, the method further includes: The AutBus control node receives device access information reported by each of the AutBus protocol converters. The device access information includes the converter identifier of the AutBus protocol converter and the bus protocol type supported by at least one of the terminal devices connected to the AutBus protocol converter. The AutBus control node constructs the global mapping table based on all the device access information it has received.

6. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 1, characterized in that, After receiving the AutBus bearer frame, the second AutBus protocol converter sends the original protocol message encapsulated within the AutBus bearer frame to the destination terminal device, including the following steps: The second AutBus protocol converter receives the AutBus bearer frame; The second AutBus protocol converter parses the payload field of the AutBus bearer frame, obtains the protocol packet entity contained in the payload field, and reads the data field content from the protocol packet entity to obtain the original protocol message; The second AutBus protocol converter parses the destination terminal device address from the original protocol message and determines whether the destination terminal device address is the terminal device address connected to the second AutBus protocol converter. If so, the second AutBus protocol converter sends the original protocol message to the destination terminal device.

7. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 6, characterized in that, The step of reading the data field content from the protocol packet entity to obtain the original protocol message includes: The second AutBus protocol converter parses the protocol packet entity, extracts the data field content to obtain encrypted protocol data, and extracts the encryption mode field content to obtain an encryption mode identifier indicating the encryption mode of the original protocol message; The second AutBus protocol converter determines the encryption mode of the encryption protocol data based on the encryption mode identifier, and obtains the decryption key corresponding to the encryption mode; The second AutBus protocol converter uses the decryption key to decrypt the encrypted protocol data to obtain the plaintext original protocol message.

8. The multi-protocol fusion transmission method based on the AutBus protocol as described in claim 1, characterized in that, The step of encapsulating the original protocol message according to a preset multi-protocol bearer frame format to obtain the corresponding AutBus bearer frame includes: The first AutBus protocol converter determines the corresponding encryption mode and encryption key, as well as the corresponding protocol type identifier, based on the bus protocol type supported by the source terminal device. The first AutBus protocol converter uses the encryption key and the encryption mode to encrypt the original protocol message and generate encrypted protocol data; The first AutBus protocol converter constructs a protocol packet entity containing the encrypted protocol data. The protocol packet entity includes the protocol type identifier, a data length field indicating the length of the encrypted protocol data, an encryption mode identifier indicating the encryption mode of the original protocol message, and the encrypted protocol data. The first AutBus protocol converter constructs the payload field of the AutBus bearer frame. The payload field includes a protocol packet entity number field indicating the number of protocol packet entities, a protocol packet entity total length field indicating the total length of the protocol packet entities, and the protocol packet entities themselves. The first AutBus protocol converter sets the frame header of the AutBus bearer frame and updates the value of the type field in the frame header to a preset multi-protocol bearer value; The first AutBus protocol converter forms the complete AutBus bearer frame based on the updated frame header and the payload field.

9. A multi-protocol converged transmission device based on the AutBus protocol, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-protocol converged transmission method based on the AutBus protocol as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the multi-protocol fusion transmission method based on the AutBus protocol as described in any one of claims 1 to 8.

Images