Protocol conversion method and AUTBUS chip applied to AUTBUS control node and terminal node

Abstract

The embodiment of the present application provides a protocol conversion method and AUTBUS chip applied to AUTBUS control nodes and terminal nodes, which receives Modbus-TCP messages sent by Modbus-TCP devices of the module bus transmission control protocol; parses and unpacks the Modbus-TCP messages, reassembles the unpacked data, and encapsulates them into AUTBUS messages and sends them to the AUTBUS terminal nodes. Thus, the Modbus-TCP messages sent by the Modbus-TCP devices are unpacked and reassembled through the AUTBUS bus protocol network to obtain AUTBUS messages, and protocol conversion between devices based on different communication protocols based on the AUTBUS bus protocol network is realized, without the need to use an additional protocol conversion gateway, reducing the complexity of protocol conversion and improving the efficiency of protocol conversion.

Description

Technical Field

[0001] The present application belongs to the field of industrial communications, and specifically relates to a protocol conversion method and an AUTBUS chip applied to an AUTBUS control node and a terminal node. Background Art

[0002] In the field of modern industrial communications, data communication is required between different devices on the industrial site. Some devices follow the communication protocol of the Modbus Remote Terminal Unit (Modbus-RTU), and some devices follow the communication protocol of the Modbus Transmission Control Protocol (Modbus-TCP). Communication between Modbus-TCP devices and Modbus-RTU devices requires data information conversion.

[0003] In the prior art, protocol conversion between devices based on different communication protocols can be performed through an industrial bus and a protocol conversion gateway, where the protocol conversion gateway is part of the industrial bus, such as the Controller Area Network (CAN) bus, and the data of two different protocols are converted and forwarded through a gateway that supports the Modbus-TCP communication protocol and the Modbus-RTU communication protocol.

[0004] However, in the prior art, the efficiency of protocol conversion is not high. Summary of the invention

[0005] The embodiment of the present application provides a protocol conversion method and an AUTBUS chip applied to an AUTBUS control node and a terminal node, so as to realize information exchange between a Modbus-TCP device and multiple Modbus-RTU devices using an AUTBUS bus protocol network.

[0006] In a first aspect, an embodiment of the present application provides a protocol conversion method applied to an AUTBUS control node, comprising:

[0007] Receive Modbus-TCP messages sent by Modbus-TCP devices;

[0008] Parse and unpack the Modbus-TCP message, reassemble the unpacked data and encapsulate it into an AUTBUS message and send it to the AUTBUS terminal node.

[0009] Optionally, the step of reassembling the unpacked data and encapsulating the data into an AUTBUS message and sending the message to the AUTBUS terminal node includes:

[0010] After unpacking, obtain the unit identifier, function code and message data in the Modbus-TCP message;

[0011] The unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message, and sent to the AUTBUS terminal node.

[0012] Optionally, the method further includes:

[0013] Receive AUTBUS messages sent by AUTBUS terminal nodes;

[0014] Unpack the AUTBUS message, encapsulate it into a Modbus-TCP message, and then send it to the Modbus-TCP device.

[0015] In a second aspect, an embodiment of the present application provides a protocol conversion method applied to an AUTBUS terminal node, comprising:

[0016] Receive AUTBUS messages sent by AUTBUS control nodes;

[0017] The AUTBUS message is parsed and unpacked, and the unpacked data is encapsulated into a module bus remote control unit Modbus-RTU message and sent to the Modbus-RTU device.

[0018] Optionally, after parsing and unpacking the AUTBUS message, the method further includes:

[0019] When it is determined that the destination address of the AUTBUS message is the address of the local node according to the device identifier in the AUTBUS message, the device identifier, function code and message data in the AUTBUS message are separated;

[0020] The step of encapsulating the unpacked data into a Modbus-RTU message and sending it to the Modbus-RTU device includes:

[0021] The separated device identifier, function code and message data are reassembled into a Modbus-RTU message and sent to the Modbus-RTU device.

[0022] Optional, including:

[0023] Receive Modbus-RTU messages;

[0024] Parse and unpack the Modbus-RTU message, reassemble the unpacked data and encapsulate it into an AUTBUS message and send it to the AUTBUS control node.

[0025] In a third aspect, an embodiment of the present application provides an AUTBUS chip applied to a control node, including:

[0026] The conversion module is used to receive the Modbus-TCP message sent by the module bus transmission control protocol Modbus-TCP device; parse and unpack the Modbus-TCP message, reassemble the unpacked data and encapsulate it into an AUTBUS message;

[0027] AUTBUS module, used to send AUTBUS messages to AUTBUS terminal nodes; receive AUTBUS messages sent by AUTBUS terminal nodes;

[0028] The conversion module is also used to unpack the AUTBUS message, encapsulate it into a Modbus-TCP message and send it to the Modbus-TCP device.

[0029] Optionally, the conversion module is further used to obtain the unit identifier, function code and message data in the Modbus-TCP message after unpacking, and reassemble the unit identifier, function code and message data into an AUTBUS message.

[0030] In a fourth aspect, an embodiment of the present application provides an AUTBUS chip applied to a terminal node, including:

[0031] AUTBUS module, used to receive AUTBUS messages sent by AUTBUS control nodes;

[0032] The conversion module is used to parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device;

[0033] Optionally, the conversion module is also used to split out the device identifier, function code and message data in the AUTBUS message when it is determined that the destination address of the AUTBUS message is the address of the current node based on the device identifier in the AUTBUS message; and reassemble the split device identifier, function code and message data into a Modbus-RTU message.

[0034] In a fifth aspect, an embodiment of the present application provides a Modbus-TCP device and Modbus-RTU device communication system based on an AUTBUS bus, comprising: an AUTBUS control node communicating with a module bus transmission control protocol Modbus-TCP device and an AUTBUS terminal node communicating with a module bus remote control unit Modbus-RTU device, wherein a plurality of AUTBUS terminal nodes are connected to the AUTBUS control node via the AUTBUS bus, and each AUTBUS terminal node is respectively connected to a Modbus-RTU device;

[0035] AUTBUS control node, used to receive Modbus-TCP messages sent by Modbus-TCP devices; parse and unpack Modbus-TCP messages, reassemble the unpacked data, encapsulate them into AUTBUS messages and send them to AUTBUS terminal nodes;

[0036] The AUTBUS terminal node is used to receive the AUTBUS message sent by the AUTBUS control node; parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device.

[0037] Optionally, the AUTBUS control node is further used for:

[0038] After unpacking, the unit identifier, function code and message data in the Modbus-TCP message are obtained; the unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message.

[0039] Optionally, the AUTBUS terminal node is also used to: when it is determined that the destination address of the AUTBUS message is the address of this node based on the device identifier in the AUTBUS message, split out the device identifier, function code and message data in the AUTBUS message; and reassemble the split device identifier, function code and message data into a Modbus-RTU message.

[0040] The protocol conversion method and AUTBUS chip applied to AUTBUS control nodes and terminal nodes provided in the embodiment of the present application receive Modbus-TCP messages sent by Modbus-TCP devices of the module bus transmission control protocol; parse and unpack Modbus-TCP messages, reassemble the unpacked data and encapsulate them into AUTBUS messages and send them to AUTBUS terminal nodes. Thus, the Modbus-TCP messages sent by the Modbus-TCP devices are unpacked and reassembled through the AUTBUS bus protocol network to obtain AUTBUS messages, and protocol conversion based on the AUTBUS bus protocol network between devices based on different communication protocols is realized, without the need to use additional protocol conversion gateways, reducing the complexity of protocol conversion and improving the efficiency of protocol conversion. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1A A schematic diagram of the structure of a Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus provided in an embodiment of the present application;

[0042] Figure 1B A schematic diagram of the structure of another Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus provided in an embodiment of the present application;

[0043] Figure 2A A schematic diagram of the structure of an AUTBUS control node provided in an embodiment of the present application;

[0044] Figure 2B A schematic diagram of the structure of an AUTBUS terminal node provided in an embodiment of the present application;

[0045] Figure 3A A schematic diagram of the structure of a Modbus-TCP device and a Modbus-RTU device communication system based on an AUTBUS bus provided in an embodiment of the present application;

[0046] Figure 3B A schematic diagram of the structure of another Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus provided in an embodiment of the present application;

[0047] Figure 4 A flowchart of a protocol conversion method applied to an AUTBUS control node provided in an embodiment of the present application;

[0048] Figure 5 A flowchart of another protocol conversion method applied to an AUTBUS control node provided in an embodiment of the present application;

[0049] Figure 6 A flowchart of another protocol conversion method applied to an AUTBUS control node provided in an embodiment of the present application;

[0050] Figure 7 A flowchart of a protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application;

[0051] Figure 8 A flowchart of another protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application;

[0052] Fig. 9 A flowchart of another protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application;

[0053] Fig.10 A schematic diagram of the structure of an AUTBUS chip applied to a control node provided in an embodiment of the present application;

[0054] Fig.11 A schematic diagram of the structure of an AUTBUS chip applied to a terminal node provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] The technical solutions in the embodiments of the present application will be clearly described below in conjunction with the drawings in the embodiments of the present application. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of the present application.

[0056] The terms "first", "second", etc. of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same type, and the number of objects is not limited.

[0057] In order to solve the problem that the communication protocols between Modbus-TCP devices and Modbus-RTU devices are different and cannot exchange information, the prior art uses industrial buses such as CAN to perform protocol conversion and data communication between Modbus-TCP devices and Modbus-RTU devices. However, the existing industrial buses usually have low bandwidth, limited transmission distance and number of nodes, and the protocol conversion requires additional gateway configuration, which makes the protocol conversion complex, and thus leads to the problem of low efficiency of protocol conversion. The present application uses an AUTBUS protocol network to realize the conversion communication of Modbus-TCP messages to AUTBUS messages and then to Modbus-RTU messages, or the conversion communication of Modbus-RTU messages to AUTBUS messages and then to Modbus-TCP messages. The AUTBUS two-wire broadband bus is an industrial field bus with simple wiring that uses two wires and is based on time-sensitive technology to achieve multi-topology, multi-node, high bandwidth, and long-distance transmission. It can be widely compatible with multiple application layer protocols and does not require additional protocol conversion gateways, thereby improving the protocol conversion efficiency between different communication protocol devices in the industrial field, and at the same time improving the reliability of the overall communication process. AUTBUS national standard: GB / T42019-2022 will be officially released in October 2022. AUTBUS international standards: IEC61158-Type 28, IEC61784-CPF22 will be officially released in March 2023.

[0058] The following embodiments of the present application may be executed by a communication system. Figure 1A A schematic diagram of the structure of a Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus provided in an embodiment of the present application is shown in FIG. Figure 1AAs shown, the system of this embodiment includes: an AUTBUS control node communicating with a Modbus-TCP device and an AUTBUS terminal node communicating with a Modbus-RTU device, the AUTBUS terminal node and the AUTBUS control node are connected via an AUTBUS bus, the AUTBUS control node and the Modbus-TCP device are connected via Ethernet, wherein Ethernet is a basic network facility that can provide a high-speed data transmission channel, and the AUTBUS terminal node and the Modbus-RTU device are connected via Recommended Standard 485 (RS-485), wherein RS-485 is a serial communication interface standard that can provide a longer communication distance and higher anti-interference capability. In the process of data transmission from the Modbus-TCP device to the Modbus-RTU device, the AUTBUS control node is used to receive the Modbus-TCP message sent by the Modbus-TCP device; parse and unpack the Modbus-TCP message, reassemble the unpacked data, encapsulate it into an AUTBUS message and send it to the AUTBUS terminal node; the AUTBUS terminal node is used to receive the AUTBUS message sent by the AUTBUS control node; parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device. The AUTBUS control node is also used to obtain the unit identifier, function code and message data in the Modbus-TCP message after unpacking; and reassemble the unit identifier, function code and message data into an AUTBUS message; the AUTBUS terminal node is also used to split out the device identifier, function code and message data in the AUTBUS message when judging that the destination address of the AUTBUS message is the address of this node according to the device identifier in the AUTBUS message; and reassemble the split device identifier, function code and message data into a Modbus-RTU message.

[0059] The embodiment of the present application can realize information exchange between a Modbus-TCP device and multiple Modbus-RTU devices by using the AUTBUS bus protocol network. Figure 1B A schematic diagram of the structure of another Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus provided in an embodiment of the present application is shown in FIG. Figure 1BAs shown, the following embodiments of the present application can also be executed by the communication system. The system of this embodiment includes: at least one AUTBUS terminal node and one AUTBUS control node. Multiple AUTBUS terminal nodes are connected to the AUTBUS control node through the AUTBUS bus. Taking two AUTBUS terminal nodes as an example, each AUTBUS terminal node is connected to a Modbus-RTU device. In the process of transmitting data from the Modbus-TCP device to the Modbus-RTU device, the role and Figure 1A The same as shown, no further description is given here.

[0060] Specifically, Figure 2A A schematic diagram of the structure of an AUTBUS control node provided in an embodiment of the present application is shown in FIG. Figure 2A As shown, the AUTBUS control node includes: an Ethernet interface, an AUTBUS control node processing module and an AUTBUS bus interface. Figure 2B A schematic diagram of the structure of an AUTBUS terminal node provided in an embodiment of the present application is shown in FIG. Figure 2B As shown, the AUTBUS terminal node includes: an AUTBUS bus interface, an AUTBUS terminal node processing module and an RS-485 interface. The Ethernet interface is used to receive the Modbus-TCP message sent by the Modbus-TCP device and send it to the AUTBUS control node processing module; the AUTBUS control node processing module is used to parse and unpack the Modbus-TCP message based on the Modbus-TCP communication protocol, and reassemble and encapsulate it based on the AUTBUS communication protocol to obtain the AUTBUS message and send it to the AUTBUS bus interface; the AUTBUS bus interface is used to receive the AUTBUS message sent by the AUTBUS control node processing module and send it to the AUTBUS terminal node processing module; the AUTBUS terminal node processing module is used to parse and unpack the AUTBUS message based on the AUTBUS communication protocol, and reassemble and encapsulate it based on the Modbus-RTU communication protocol to obtain the Modbus-RTU message, and finally forward it to the Modbus-RTU device through the RS-485 interface.

[0061] It can be understood that the protocol conversion between the Modbus-TCP device and the Modbus-RTU device includes two-directional communication, wherein one direction is that the Modbus-TCP device initiates communication to the Modbus-RTU device, see Figure 3A ; The other direction is that the Modbus-RTU device initiates communication with the Modbus-TCP device, see Figure 3B .

[0062] In the embodiment of the present application, the module bus (MODular BUS, Modbus) is a widely used industrial standard communication protocol, which is mainly used to realize data exchange between different devices. The Modbus-TCP communication protocol is a variant of the Modbus protocol, which uses standard Ethernet as the transmission medium and is based on the TCP / IP protocol stack transmission. The Modbus-TCP communication protocol encapsulates traditional Modbus data in standard TCP messages, so that Modbus can run efficiently on Ethernet; the Modbus-RTU communication protocol is a Modbus version protocol used on a serial communication link, which uses a serial communication line as the transmission medium, such as an RS-232 or RS-485 interface, and is based on a simple serial communication protocol stack transmission. The Modbus-TCP communication protocol encapsulates traditional Modbus data in standard RTU messages, so that Modbus can run on a serial communication interface. The Modbus-TCP communication protocol and the Modbus-RTU communication protocol are specifically used for device communication in an industrial automation environment, so that devices from different manufacturers can communicate with each other.

[0063] Among them, both the Modbus-TCP communication protocol and the Modbus-RTU communication protocol are a master-slave communication mode, so the host (Master) and the slave (Slave) must be specified before the communication is initiated. The host is the party that initiates the communication and is responsible for sending requests to other devices in the network. The slave is the party that responds to the host's request and will perform corresponding operations and return results. In this embodiment, in the Modbus-TCP communication protocol, the Modbus-TCP device is set as the host and the AUTBUS control node is the slave. In the Modbus-RTU communication protocol, the AUTBUS terminal node is the host and the Modbus-RTU device is the slave. Specifically, Modbus-TCP devices and Modbus-RTU devices may include but are not limited to the following devices:

[0064] Programmable Logic Controller (PLC): PLC is an automation component used to control machinery or production processes. It usually acts as a host and plays a core role in the control system. It actively sends requests to other devices (such as sensors, actuators, or inverters) and receives responses. For example, in an automated assembly line in a manufacturing plant, the PLC will regularly read the data from the temperature sensor and process and analyze the data, and then make decisions based on the results. If the temperature reported by the temperature sensor exceeds the preset threshold, the PLC will send an opening instruction to the cooling system. PLC devices can exchange data and send control commands through the Modbus-TCP communication protocol or the Modbus-RTU communication protocol.

[0065] Sensors: such as temperature sensors, pressure sensors, and motor sensors, usually act as slaves, perform corresponding read or write operations according to the received commands, and return the results to the host. For example, temperature sensors act as slaves to measure the temperature of the environment or inside the equipment, and regularly report the ambient temperature to the host to help the control system adjust the temperature in the workshop. They can act as Modbus-TCP slaves, sending data to the host for monitoring and control through the Modbus-TCP communication protocol, or as Modbus-RTU slaves, sending data to the host for monitoring and control through the Modbus-RTU communication protocol.

[0066] Human-Machine Interface (HMI): HMI devices are used to display and control industrial processes and can act as slaves, receiving commands or data updates from the host. For example, the HIM receives data from the PLC of the production line in the operation room and displays it to the operator. The HIM can read and write data from the PLC or other controllers through the Modbus-TCP communication protocol or the Modbus-RTU communication protocol.

[0067] The communication method of the present application is described below by taking several embodiments as examples.

[0068] Figure 4 A flowchart of a protocol conversion method for an AUTBUS control node provided in an embodiment of the present application is provided. The method of this embodiment is applied to Figure 3A The communication system shown in Figure 4 As shown, the process of the method in this embodiment is as follows:

[0069] S41: receiving a Modbus-TCP message sent by a Modbus-TCP device.

[0070] Among them, Figure 3A As shown, in the process of a Modbus-TCP device initiating communication with a Modbus-RTU device, the AUTBUS bus protocol network must include an AUTBUS control node and at least one AUTBUS terminal node. Each AUTBUS terminal node is connected to a Modbus-RTU device. The AUTBUS control node is responsible for connecting the Modbus-TCP device and the AUTBUS bus, and is used to receive the Modbus-TCP message sent by the Modbus-TCP device, and convert the Modbus-TCP message into an AUTBUS message and send it to the AUTBUS terminal node. The AUTBUS terminal node is responsible for connecting the AUTBUS bus and the Modbus-RTU device, and is used to receive the AUTBUS message sent by the AUTBUS control node, and convert the AUTBUS message into a Modbus-RTU message and send it to the Modbus-RTU device. Therefore, in this scenario, the AUTBUS control node receives the Modbus-TCP message sent by the Modbus-TCP device.

[0071] S42: Parse and unpack the Modbus-TCP message, reassemble the unpacked data, encapsulate it into an AUTBUS message and send it to the AUTBUS terminal node.

[0072] Among them, Figure 3A As shown, in the scenario where the Modbus-TCP device initiates communication to the Modbus-RTU device, the AUTBUS control node parses and unpacks the received Modbus-TCP message based on the Modbus-TCP communication protocol, and reassembles and encapsulates the unpacked data based on the AUTBUS communication protocol to obtain an AUTBUS message and sends it to the AUTBUS terminal node.

[0073] In this embodiment, the Modbus-TCP message sent by the Modbus-TCP device of the module bus transmission control protocol is received; the Modbus-TCP message is parsed and unpacked, and the unpacked data is reassembled and encapsulated into an AUTBUS message and sent to the AUTBUS terminal node. Thus, the Modbus-TCP message sent by the Modbus-TCP device is unpacked and reassembled through the AUTBUS bus protocol network to obtain the AUTBUS message, realizing the protocol conversion between devices based on different communication protocols based on the AUTBUS bus protocol network, without the need to use an additional protocol conversion gateway, reducing the complexity of the protocol conversion, and improving the efficiency of the protocol conversion.

[0074] In the above embodiment, the format of the Modbus-TCP message is shown in Table 1, the format of the AUTBUS message is shown in Table 2, and the format of the Modbus-RTU message is shown in Table 3.

[0075] Table 1 Modbus-TCP message format

[0076]

[0077] As shown in Table 1, the structure of the Modbus-TCP message includes two parts: the application layer protocol (Modbus Application Protocol, MBAP) header and the protocol data unit (Modbus Protocol Data Unit, Modbus PDU). The MBAP header includes header information: transaction identifier, protocol identifier, length field and unit identifier field, and the Modbus PDU includes data information: function code and data field. The transaction identifier occupies 2 bytes and is used to identify a request-response pair. Each request is assigned a unique transaction identifier to help the client identify which responses match which requests. If the client does not receive the expected response or receives an incorrect response, the transaction identifier can also help diagnose the problem. The protocol identifier occupies 2 bytes and is used to identify the protocol version. It is usually set to 0, indicating the Modbus-TCP protocol itself. The length field occupies 2 bytes and indicates the total length of the data in the Modbus-TCP message excluding the header information. The unit identifier occupies 1 byte and is used to identify the terminal device address receiving the Modbus-TCP message to ensure that the Modbus-TCP message is correctly routed to the correct device. The function code occupies 1 byte and defines the operation type of the request or response. It is used to specify the function of the Modbus-TCP message, such as reading coil status, reading holding registers, and reading input registers. The data field occupies N bytes and contains the specific data of the Modbus-TCP message, such as the register address and data value to be read or written. It is a variable-length data field, depending on the specific function code, and contains N bytes of starting address and N bytes of register quantity.

[0078] Table 2 AUTBUS message format

[0079]

[0080] As shown in Table 2, the format of the AUTBUS message includes two parts: header information and data information. The header information includes: identifier (ID), packet sequence number (Count) field, length (Length) field, and the data information includes: device identifier (Device Identifier, DevID), function code (Function Code) and data (Data) field. Among them, ID occupies 1 byte, indicating the data type, which is used to indicate whether the message is a request, a response or a certain type of message, for example, 0x01 indicates a read request; Count occupies 1 byte, indicating the packet sequence number, which is used to identify the order of the message and help the receiving end detect data loss or duplication; Length occupies 2 bytes, indicating the total length of the function code and data field in the AUTBUS message except the header information; DevID occupies 1 byte, indicating the device identifier, that is, the unit identifier derived from the Modbus-TCP communication protocol, which is used to identify the terminal device address receiving the AUTBUS message; Function Code occupies 1 byte, indicating the function code, which defines the operation type of the request or response, and is used to specify the function of the AUTBUS message, such as reading coil status, reading holding registers, and reading input registers; Data occupies N bytes, indicating data, including specific data of the AUTBUS message, such as the register address and data value to be read or written, which is a variable length data field, depending on the specific function code, including N bytes of starting address and N bytes of register quantity.

[0081] Table 3 Modbus-RTU message format

[0082]

[0083] As shown in Table 3, the structure of the Modbus-RTU message includes: slave address, function code, data field and cyclic redundancy check code (Cyclic Redundancy Check, CRC). Among them, the slave address occupies 1 byte, which corresponds to the unit identifier in the Modbus-TCP message, that is, the terminal device address to which the Modbus-RTU message is to be sent; the function code occupies 1 byte, which defines the operation type of the request or response, and is used to specify the function of the Modbus-RTU message, such as reading coil status, reading holding registers, and reading input registers; the data field occupies N bytes, containing the specific data of the Modbus-RTU message, such as the register address and data value to be read or written, which is a variable-length data field, depending on the specific function code, including N bytes of the starting address and N bytes of the number of registers; CRC occupies 2 bytes, indicating that the checksum is used to detect errors in the transmission process of the Modbus-RTU message. The CRC is calculated once when the Modbus-RTU message is sent, and the CRC is calculated again when the Modbus-RTU message is received. If the CRC of the sent Modbus-RTU message is inconsistent with the CRC of the received Modbus-RTU message, it means that an error occurred during the transmission of the Modbus-RTU message.

[0084] Figure 5 A flowchart of another protocol conversion method applied to an AUTBUS control node provided in an embodiment of the present application is provided. Figure 5 is Figure 4 Based on the embodiment shown, a possible implementation of S42 is further described. The method of this embodiment is applied to Figure 3A The communication system shown in Figure 5 As shown, the process of the method in this embodiment is as follows:

[0085] S421: After unpacking, obtain the unit identifier, function code and message data in the Modbus-TCP message.

[0086] The AUTBUS control node processing module of the AUTBUS control node unpacks the Modbus-TCP message to obtain the unit identifier, function code and message data in the Modbus-TCP message.

[0087] Specifically, Figure 2A and Figure 3AAs shown, in the scenario where the Modbus-TCP device initiates communication to the Modbus-RTU device, the Ethernet interface of the AUTBUS control node receives the Modbus-TCP message sent by the Modbus-TCP device, and the AUTBUS control node processing module parses and unpacks the Modbus-TCP message based on the Modbus-TCP communication protocol, that is, as shown in Table 1, the unit identifier, function code and message data part in the Modbus-TCP message are removed to obtain the parsing result of the Modbus-TCP message.

[0088] S422: The unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message, and sent to the AUTBUS terminal node.

[0089] The AUTBUS control node processing module of the AUTBUS control node reassembles the unit identifier, function code and message data disassembled from the Modbus-TCP message, encapsulates them into an AUTBUS message, and sends them to the AUTBUS terminal node.

[0090] Specifically, Figure 2A and Figure 3A As shown in FIG. 2 , in the scenario where the Modbus-TCP device initiates communication with the Modbus-RTU device, the AUTBUS control node processing module reassembles and encapsulates the parsing result of the Modbus-TCP message based on the AUTBUS communication protocol, that is, as shown in Table 2, the unit identifier, function code and data part removed from the Modbus-TCP message are added to the AUTBUS message header: ID, Count and Length part to obtain the AUTBUS message, and then the AUTBUS message is sent to the AUTBUS terminal node.

[0091] In this embodiment, the unit identifier, function code and message data in the Modbus-TCP message are obtained by unpacking, and the unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message, and sent to the AUTBUS terminal node. Thus, a protocol conversion is achieved through the AUTBUS bus protocol network, and the AUTBUS message is obtained.

[0092] Figure 6 A flowchart of another protocol conversion method applied to an AUTBUS control node provided in an embodiment of the present application is provided. Figure 6 is Figure 4 Based on the embodiment shown, further, it also includes a description of a possible implementation method for the scenario in which the Modbus-RTU device initiates communication with the Modbus-TCP device. The method of this embodiment is applied to Figure 3BThe communication system shown in Figure 6 As shown, the process of the method in this embodiment is as follows:

[0093] S61: receiving an AUTBUS message sent by an AUTBUS terminal node.

[0094] Among them, Figure 3B As shown, in the process of the Modbus-RTU device initiating communication with the Modbus-TCP device, the AUTBUS bus protocol network must also include at least one AUTBUS terminal node and one AUTBUS control node. Each Modbus-RTU device is connected to an AUTBUS terminal node. The AUTBUS terminal node is responsible for connecting the Modbus-RTU device and the AUTBUS bus, and is used to receive the Modbus-RTU message sent by the Modbus-RTU device, and convert the Modbus-RTU message into an AUTBUS message and send it to the AUTBUS control node. The AUTBUS control node is responsible for connecting the AUTBUS bus and the Modbus-TCP device, and is used to receive the AUTBUS message sent by the AUTBUS terminal node, and convert the AUTBUS message into a Modbus-TCP message and send it to the Modbus-TCP device. Therefore, in this scenario, the AUTBUS control node receives the AUTBUS message sent by the AUTBUS terminal node.

[0095] S62: unpack the AUTBUS message, encapsulate it into a Modbus-TCP message, and then send it to the Modbus-TCP device.

[0096] Among them, Figure 3B As shown, in the scenario where the Modbus-RTU device initiates communication with the Modbus-TCP device, the AUTBUS control node unpacks the AUTBUS message sent by the AUTBUS terminal node based on the AUTBUS communication protocol, and encapsulates it into a Modbus-TCP message based on the Modbus-TCP communication protocol and sends it to the Modbus-TCP device.

[0097] In this embodiment, the AUTBUS message sent by the AUTBUS terminal node is received; the AUTBUS message is unpacked, encapsulated into a Modbus-TCP message, and then sent to the Modbus-TCP device. Thus, the AUTBUS message sent by the AUTBUS terminal node is converted into a Modbus-TCP message by the AUTBUS control node, and the Modbus-TCP message is obtained, thereby realizing the protocol conversion based on the AUTBUS bus protocol network between devices based on different communication protocols, and improving the efficiency of the protocol conversion.

[0098] In the above embodiment, Figure 6 The steps and Figure 4 The sequence of the steps in the illustrated embodiment is not limited.

[0099] In the above embodiment, specifically, Figure 2A and Figure 3B As shown in the figure, in the scenario where the Modbus-RTU device initiates communication with the Modbus-TCP device, the AUTBUS control node processing module of the AUTBUS control node unpacks the AUTBUS message based on the AUTBUS communication protocol, that is, as shown in Table 2, the DevID, Function Code and Data parts in the AUTBUS message are unpacked to obtain the parsing result of the AUTBUS message. The AUTBUS control node processing module encapsulates the parsing result of the AUTBUS message into a Modbus-TCP message based on the Modbus-TCP communication protocol, that is, as shown in Table 1, the DevID, Function Code and Data parts unpacked from the AUTBUS message are added to the Modbus-TCP message header: transaction identifier, protocol identifier and length part to obtain a Modbus-TCP message.

[0100] Figure 7 A flowchart of a protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application is provided. The method of this embodiment is applied to Figure 3A The communication system shown in Figure 7 As shown, the process of the method in this embodiment is as follows:

[0101] S71: Receive the AUTBUS message sent by the AUTBUS control node.

[0102] Among them, Figure 3A As shown in the figure, in the scenario where the Modbus-TCP device initiates communication with the Modbus-RTU device, the AUTBUS terminal node is responsible for connecting the AUTBUS bus and the Modbus-RTU device, receiving the AUTBUS message sent by the AUTBUS control node, and converting the AUTBUS message into a Modbus-RTU message and sending it to the Modbus-RTU device. Therefore, in this scenario, the AUTBUS terminal node receives the AUTBUS message sent by the AUTBUS control node.

[0103] S72: Parse and unpack the AUTBUS message, encapsulate the unpacked data into a module bus remote control unit Modbus-RTU message and send it to the Modbus-RTU device.

[0104] Among them, Figure 3A As shown, in the scenario where the Modbus-TCP device initiates communication with the Modbus-RTU device, the AUTBUS terminal node parses and unpacks the AUTBUS message based on the AUTBUS communication protocol, and re-encapsulates the parsing result obtained by unpacking into a Modbus-RTU message based on the Modbus-RTU communication protocol and sends it to the Modbus-RTU device.

[0105] In this embodiment, the AUTBUS message sent by the AUTBUS control node is received; the AUTBUS message is parsed and unpacked, and the unpacked data is encapsulated into a Modbus-RTU message of the module bus remote control unit and sent to the Modbus-RTU device. Thus, the AUTBUS message sent by the AUTBUS control node is converted into a Modbus-RTU message by the AUTBUS terminal node, and the protocol conversion based on the AUTBUS bus protocol network between devices based on different communication protocols is realized, and the efficiency of the protocol conversion is improved.

[0106] Figure 8 A flowchart of another protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application is provided. Figure 8 is Figure 7 Based on the embodiment shown, a possible implementation of S72 is further described. The method of this embodiment is applied to Figure 3A The communication system shown in Figure 8 As shown, the process of the method in this embodiment is as follows:

[0107] S721: When it is determined according to the device identifier in the AUTBUS message that the destination address of the AUTBUS message is the address of the current node, the device identifier, function code and message data in the AUTBUS message are separated.

[0108] Among them, Figure 2B and Figure 3A As shown in the figure, in the scenario where the Modbus-TCP device initiates communication with the Modbus-RTU device, the AUTBUS bus interface of the AUTBUS terminal node receives the AUTBUS message sent by the AUTBUS control node, and the AUTBUS terminal node processing module parses and unpacks the AUTBUS message based on the AUTBUS communication protocol. That is, as shown in Table 2, the AUTBUS terminal node first verifies the DevID of the AUTBUS message, that is, the device identifier to determine whether the AUTBUS message is a message sent to the AUTBUS terminal node, and then removes the DevID, Function Code and Data parts in the AUTBUS message to obtain the parsing result of the AUTBUS message.

[0109] S722: Reassemble the separated device identifier, function code and message data into a Modbus-RTU message, and send it to the Modbus-RTU device.

[0110] The AUTBUS terminal node processing module of the AUTBUS terminal node reassembles the unit identifier and function code separated from the AUTBUS message and the message data part, encapsulates them into a Modbus-RTU message, and sends them to the Modbus-RTU device.

[0111] Specifically, Figure 2B and Figure 3A As shown in the figure, in the scenario where the Modbus-TCP device initiates communication to the Modbus-RTU device, the AUTBUS terminal node processing module reassembles and encapsulates the parsing result of the AUTBUS message based on the Modbus-RTU communication protocol, that is, as shown in Table 3, the DevID, Function Code and Data parts removed from the AUTBUS message are added with the slave address and CRC parts to be reassembled into a Modbus-RTU message, and then the Modbus-RTU message is sent to the Modbus-RTU message device.

[0112] In this embodiment, when the destination address of the AUTBUS message is determined to be the address of the node according to the device identifier in the AUTBUS message, the device identifier, function code and message data in the AUTBUS message are separated; the separated device identifier, function code and message data are reassembled into a Modbus-RTU message, and sent to the Modbus-RTU device. Thus, another protocol conversion is realized through the AUTBUS bus protocol network, and a Modbus-RTU message is obtained.

[0113] Fig. 9 A flowchart of another protocol conversion method applied to an AUTBUS terminal node provided in an embodiment of the present application is provided. Fig. 9 is Figure 7 Based on the embodiment shown, further, it also includes a description of another possible implementation method for the scenario in which the Modbus-RTU device initiates communication with the Modbus-TCP device. The method of this embodiment is applied to Figure 3B The communication system shown in Fig. 9 As shown, the process of the method in this embodiment is as follows:

[0114] S91: Receive Modbus-RTU message.

[0115] Among them, Figure 3BAs shown in the figure, in the scenario where the Modbus-RTU device initiates communication with the Modbus-TCP device, the AUTBUS terminal node is responsible for connecting the Modbus-RTU device and the AUTBUS bus, receiving the Modbus-RTU message sent by the Modbus-RTU device, and converting the Modbus-RTU message into an AUTBUS message and sending it to the AUTBUS control node. Therefore, in this scenario, the AUTBUS terminal node receives the Modbus-RTU message sent by the Modbus-RTU device.

[0116] S92: Parse and unpack the Modbus-RTU message, reassemble the unpacked data, encapsulate it into an AUTBUS message and send it to the AUTBUS control node.

[0117] Among them, Figure 3B As shown, in the scenario where the Modbus-RTU device initiates communication with the Modbus-TCP device, the AUTBUS terminal node parses and unpacks the Modbus-RTU message based on the Modbus-RTU communication protocol, and re-encapsulates the parsing result obtained by unpacking into an AUTBUS message based on the AUTBUS communication protocol and sends it to the AUTBUS control node.

[0118] In this embodiment, Modbus-RTU messages are received; Modbus-RTU messages are parsed and unpacked, and the unpacked data is reassembled and encapsulated into AUTBUS messages and sent to the AUTBUS control node. Thus, the Modbus-RTU messages sent by the Modbus-RTU device are converted into AUTBUS messages through the AUTBUS terminal node, and protocol conversion based on the AUTBUS bus protocol network is achieved between devices based on different communication protocols, while the efficiency of protocol conversion is improved.

[0119] In the above embodiment, Fig. 9 The steps and Figure 7 The sequence of the steps in the illustrated embodiment is not limited.

[0120] In the above embodiment, specifically, Figure 2B and Figure 3BAs shown in Table 3, in the scenario where the Modbus-RTU device initiates communication with the Modbus-TCP device, the RS-485 interface of the AUTBUS terminal node receives the Modbus-RTU message sent by the Modbus-RTU device, and the AUTBUS terminal node processing module of the AUTBUS terminal node parses and unpacks the Modbus-RTU message based on the Modbus-RTU communication protocol, that is, as shown in Table 3, the slave address, function code and data part of the Modbus-RTU message are removed to obtain the parsing result of the Modbus-RTU message. The AUTBUS terminal node processing module reassembles and encapsulates the parsing result of the Modbus-RTU message based on the AUTBUS communication protocol, that is, as shown in Table 2, the slave address, function code and data part removed from the Modbus-RTU message are added to the AUTBUS message header: ID, Count and Length part to obtain the AUTBUS message.

[0121] In the above embodiment, optionally, Figure 3A As shown, the communication method and communication system provided in the embodiments of the present application can support interactive communication between a Modbus-TCP device and multiple Modbus-RTU devices. For example, if a computer is used as a Modbus-TCP device to initiate communication, the AUTBUS control node is connected with a network cable, the AUTBUS control node and several AUTBUS terminal nodes form an AUTBUS bus protocol network, and another computer is used as a Modbus-RTU device, each AUTBUS terminal node is connected to each Modbus-RTU device via an RS-485 serial port line. The IP address of the computer as a Modbus-TCP device is 192.168.1.5, and the IP address of the AUTBUS control node connected to the AUTBUS bus protocol network is 192.168.1.6. The computer sends a Modbus-TCP message to the AUTBUS control node, and the AUTBUS control node parses the Modbus-TCP message and sends it to the AUTBUS terminal node to be sent. The AUTBUS terminal node then assembles the message into a Modbus-RTU message and sends it to the Modbus-RTU device, that is, the received data can be seen on the upper computer software of the computer as a Modbus-RTU device. Similarly, the Modbus-RTU device also sends response data to the Modbus-TCP device through the communication method and communication system provided in the embodiment of the present application to complete data exchange and control, etc.

[0122] In the above embodiment, further, for example, in an industrial automation production line, there is a PLC that monitors and controls the status of some mechanical equipment through the AUTBUS industrial bus. In the Modbus protocol, data is usually stored in a holding register. It is assumed that this PLC is connected to an industrial Ethernet that supports the Modbus-TCP communication protocol, and a temperature sensor is connected to an RS-485 serial interface that supports the Modbus-RTU communication protocol. It is assumed that the PLC needs to read the temperature information of the temperature sensor, that is, the register value containing the temperature information on the temperature sensor. In order to achieve this goal, the PLC will construct a Modbus-TCP request and send it to the IP address and port number of the temperature sensor through the AUTBUS industrial bus. Therefore, the PLC is used as a Modbus-TCP device, the temperature sensor is used as a Modbus-RTU device, the industrial Ethernet interface, the processor and the AUTBUS bus interface constitute the AUTBUS control node, and the AUTBUS bus interface, the processor and the RS-485 serial interface constitute the AUTBUS terminal node. Assuming that the PLC wants to read the values ​​of the two registers starting from register address 100 on the temperature sensor, and the address of the temperature sensor is 1, the content of the Modbus-TCP message that the PLC needs to construct is shown in Table 4:

[0123] Table 4 Example of Modbus-TCP message content sent by PLC to read temperature sensor information

[0124]

[0125] As shown in Table 4, the Modbus-TCP message sent by the PLC to read the temperature sensor information occupies a total of 12 bytes, of which the transaction identifier occupies 2 bytes and can be expressed as 0x0001, which is used to match requests and responses. Generally, a continuously increasing counter or a randomly generated number is used to ensure that the transaction identifier of each request is unique and can be set to any non-zero value; the protocol identifier occupies 2 bytes and is fixed to 0x0000, because in the Modbus-TCP communication protocol, Modbus-TCP indicates that the following data follows the original Modbus-TCP communication protocol, and there is no need to distinguish between multiple protocol types; the length occupies 2 bytes , which can be expressed as 0x0005, because the length indicates the length of the data part of the Modbus-TCP message excluding the header information, and the function code occupies 1 byte, and the data field is 5 bytes in length because the register address and the number of registers to be read by the PLC occupy a total of 4 bytes; the unit identifier occupies 1 byte, expressed as 0x01, because the unit identifier is the address of the terminal device, and the terminal device is a temperature sensor, and its address is 1; the function code occupies 1 byte, expressed as 0x03, because the function code specifies the operation type, the PLC is to read the register, and the function code for reading the holding register is 0x03; the data field occupies 4 bytes, expressed as 0x0064 0x0002, because the data field includes the address and number of registers, the register address 100 is expressed as 0x0064 in hexadecimal, and the number of registers is 2, expressed as 0x0002.

[0126] Furthermore, after the PLC sends the Modbus-TCP message to the AUTBUS control node through the industrial Ethernet interface, the AUTBUS control node unpacks and reassembles the Modbus-TCP message based on the Modbus-TCP communication protocol, removes the unit identifier, function code and data part shown in Table 4, and adds the AUTBUS message header to obtain the AUTBUS message and send it to the AUTBUS bus. The content of the AUTBUS message is shown in Table 5:

[0127] Table 5 Example of AUTBUS message content reassembled by AUTBUS control node

[0128]

[0129] As can be seen from Table 5, the AUTBUS message reassembled by the AUTBUS control node occupies a total of 10 bytes, of which ID occupies 1 byte, expressed as 0x01, because the PLC requests to read the data of the temperature sensor, and the message is a request type; Count occupies 1 byte, which can be expressed as 0x01, because Count is used to track the order of packets and can be randomly generated or incremented; Length occupies 2 bytes, expressed as 0x0006, because Length indicates the length of the data part of the AUTBUS message that does not include the header information, the device identifier occupies 1 byte, the function code occupies 1 byte, and the data field is 6 bytes in length because the register address and the number of registers to be read by the PLC occupy a total of 4 bytes; DevID occupies 1 byte, expressed as 0x01, because DevID and the unit identifier in the Modbus-TCP message have the same meaning, indicating the address 1 of the terminal device temperature sensor; Function Code occupies 1 byte, expressed as 0x03, because the purpose of the PLC indicates reading the holding register; The data field occupies 4 bytes, expressed as 0x0064 0x0002, because the data field includes the address and number of registers, the register address 100 is represented as 0x0064 in hexadecimal, and the number of registers is 2, which is represented as 0x0002.

[0130] Furthermore, after the AUTBUS control node reassembles the Modbus-TCP message sent by the PLC into an AUTBUS message and sends it to the AUTBUS industrial bus, the AUTBUS terminal node reassembles the AUTBUS message, adds the slave address and cyclic redundancy check code to the function code and data part shown in Table 5, and obtains a Modbus-RTU message to send to the temperature sensor. The content of the Modbus-RTU message is shown in Table 6:

[0131] Table 6 Example of Modbus-RTU message content reassembled by AUTBUS terminal node

[0132]

[0133] As shown in Table 6, the Modbus-RTU message reassembled by the AUTBUS terminal node occupies a total of 8 bytes, of which the slave address occupies 1 byte, expressed as 0x01, because the slave address and the DevID in the AUTBUS message have the same meaning, indicating the address 1 of the terminal device temperature sensor; the function code occupies 1 byte, expressed as 0x03, because the purpose of the PLC indicates reading the holding register; the data field occupies 4 bytes, expressed as 0x0064 0x0002, because the data field includes the address and number of registers, the register address 100 is expressed as 0x0064 in hexadecimal, and the number of registers is 2, expressed as 0x0002; CRC occupies 2 bytes, assuming it is 0x1234, and the CRC value is usually calculated using the CRC-16 algorithm, and the CRC value will be appended to the end of the Modbus-RTU message. After receiving the Modbus-RTU message, the temperature sensor will recalculate the CRC value and compare it with the received CRC value. If the two match, the message is considered to be error-free; if they do not match, it is considered that an error occurred during the transmission of the message and may need to be retransmitted. The AUTBUS terminal node reassembles the AUTBUS message sent by the AUTBUS control node into a Modbus-RTU message and then sends it to the temperature sensor.

[0134] Fig.10 An AUTBUS chip applied to a control node provided in an embodiment of the present application includes: a conversion module 1001 and an AUTBUS module 1002, wherein:

[0135] The conversion module 1001 is used to receive a Modbus-TCP message sent by a Modbus-TCP device of the module bus transmission control protocol; parse and unpack the Modbus-TCP message, reassemble the unpacked data and encapsulate it into an AUTBUS message;

[0136] AUTBUS module 1002, used to send AUTBUS messages to AUTBUS terminal nodes; receive AUTBUS messages sent by AUTBUS terminal nodes;

[0137] The conversion module 1001 is further used to unpack the AUTBUS message, encapsulate it into a Modbus-TCP message and send it to the Modbus-TCP device.

[0138] Optionally, the conversion module 1001 is further used to obtain the unit identifier, function code and message data in the Modbus-TCP message after unpacking, and reassemble the unit identifier, function code and message data into an AUTBUS message.

[0139] Fig.11An AUTBUS chip applied to a terminal node provided in an embodiment of the present application includes: an AUTBUS module 1101 and a conversion module 1102, wherein:

[0140] AUTBUS module 1101, used for receiving AUTBUS messages sent by AUTBUS control nodes;

[0141] The conversion module 1102 is used to parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device.

[0142] Optionally, the conversion module 1102 is also used to split out the device identifier, function code and message data in the AUTBUS message when it is determined that the destination address of the AUTBUS message is the address of the current node based on the device identifier in the AUTBUS message; and reassemble the split device identifier, function code and message data into a Modbus-RTU message.

[0143] The chip of this embodiment can be used to execute the steps executed by the AUTBUS control node and the AUTBUS terminal node in the above-mentioned method embodiments. The implementation principle and technical effect are similar and will not be described in detail here.

[0144] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.

[0145] In addition, although each operation is described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or to be performed in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the application. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0146] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

Claims

1. A protocol conversion method applied to an AUTBUS control node, characterized in that: include: Receive Modbus-TCP messages sent by Modbus-TCP devices; Parse and unpack the Modbus-TCP message, reassemble the unpacked data and encapsulate it into an AUTBUS message and send it to the AUTBUS terminal node.

2. The method according to claim 1, characterized in that The step of reassembling the unpacked data and encapsulating the data into an AUTBUS message and sending the message to the AUTBUS terminal node comprises: After unpacking, obtain the unit identifier, function code and message data in the Modbus-TCP message; The unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message, and sent to the AUTBUS terminal node.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Receive AUTBUS messages sent by AUTBUS terminal nodes; Unpack the AUTBUS message, encapsulate it into a Modbus-TCP message, and then send it to the Modbus-TCP device.

4. A protocol conversion method applied to an AUTBUS terminal node, characterized in that: include: Receive AUTBUS messages sent by AUTBUS control nodes; The AUTBUS message is parsed and unpacked, and the unpacked data is encapsulated into a module bus remote control unit Modbus-RTU message and sent to the Modbus-RTU device.

5. The method according to claim 4, characterized in that After parsing and unpacking the AUTBUS message, the method further includes: When it is determined that the destination address of the AUTBUS message is the address of the local node according to the device identifier in the AUTBUS message, the device identifier, function code and message data in the AUTBUS message are separated; The step of encapsulating the unpacked data into a Modbus-RTU message and sending it to the Modbus-RTU device includes: The separated device identifier, function code and message data are reassembled into a Modbus-RTU message and sent to the Modbus-RTU device.

6. The method according to claim 4 or 5, characterized in that: include: Receive Modbus-RTU messages; Parse and unpack the Modbus-RTU message, reassemble the unpacked data and encapsulate it into an AUTBUS message and send it to the AUTBUS control node.

7. An AUTBUS chip applied to a control node, characterized in that: include: The conversion module is used to receive the Modbus-TCP message sent by the module bus transmission control protocol Modbus-TCP device; parse and unpack the Modbus-TCP message, reassemble the unpacked data and encapsulate it into an AUTBUS message; AUTBUS module, used to send AUTBUS messages to AUTBUS terminal nodes; receive AUTBUS messages sent by AUTBUS terminal nodes; The conversion module is also used to unpack the AUTBUS message, encapsulate it into a Modbus-TCP message and send it to the Modbus-TCP device.

8. The chip according to claim 7, characterized in that: The conversion module is also used to obtain the unit identifier, function code and message data in the Modbus-TCP message after unpacking, and reassemble the unit identifier, function code and message data into an AUTBUS message.

9. An AUTBUS chip applied to a terminal node, characterized in that: include: AUTBUS module, used to receive AUTBUS messages sent by AUTBUS control nodes; The conversion module is used to parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device.

10. The chip according to claim 9, characterized in that: The conversion module is also used to separate the device identifier, function code and message data in the AUTBUS message when judging that the destination address of the AUTBUS message is the address of the current node according to the device identifier in the AUTBUS message; and reorganize the separated device identifier, function code and message data into a Modbus-RTU message.

11. A Modbus-TCP device and Modbus-RTU device communication system based on AUTBUS bus, characterized in that: include: An AUTBUS control node communicating with a module bus transmission control protocol Modbus-TCP device and an AUTBUS terminal node communicating with a module bus remote control unit Modbus-RTU device, multiple AUTBUS terminal nodes are connected to the AUTBUS control node via the AUTBUS bus, and each AUTBUS terminal node is connected to a Modbus-RTU device respectively; AUTBUS control node, used to receive Modbus-TCP messages sent by Modbus-TCP devices; parse and unpack Modbus-TCP messages, reassemble the unpacked data, encapsulate them into AUTBUS messages and send them to AUTBUS terminal nodes; AUTBUS terminal node, used to receive AUTBUS messages sent by AUTBUS control node; Parse and unpack the AUTBUS message, encapsulate the unpacked data into a Modbus-RTU message and send it to the Modbus-RTU device.

12. The system according to claim 11, characterized in that The AUTBUS control node is also used for: After unpacking, the unit identifier, function code and message data in the Modbus-TCP message are obtained; the unit identifier, function code and message data are reassembled and encapsulated into an AUTBUS message.

13. The system according to claim 11 or 12, characterized in that The AUTBUS terminal node is also used for: When it is determined according to the device identifier in the AUTBUS message that the destination address of the AUTBUS message is the address of the local node, the device identifier, function code and message data in the AUTBUS message are separated; and the separated device identifier, function code and message data are reassembled into a Modbus-RTU message.

Images