Industrial communication protocol conversion system and conversion method

Abstract

The invention discloses an industrial communication protocol conversion system and conversion method. The method comprises the following steps: acquiring data of an industrial communication source protocol; protocol conversion: converting the source protocol data into target protocol data according to a sequence of protocol analysis, standardized modeling and protocol repackaging; according to protocol analysis, original data transmitted from different hardware interfaces are analyzed according to corresponding industrial protocols; the standardized modeling parses the data into a data model in a unified format; protocol repackaging: recoding the data model into a data frame conforming to a communication specification according to a target protocol rule; and data output: pushing the obtained target protocol data to a third-party server through an MQTT protocol or directly storing the target protocol data in a database for a third-party system to access. Through three core technologies of protocol analysis, unified data modeling and protocol packaging, lossless conversion among different industrial protocols is realized, and an efficient and reliable data communication infrastructure is provided for an industrial automation system.

Description

Technical Field

[0001] The present invention relates to the field of industrial automation and communication technology, and specifically to an industrial communication protocol conversion system and method, which are particularly suitable for solving the data interoperability problem of heterogeneous protocols such as Modbus, OPC UA, IEC101, IEC104, and DL / T 645 in an industrial Internet of Things environment. Background Art

[0002] Since entering the digital age, industrial enterprises have expanded their use of industrial fieldbuses as they apply technologies such as the Internet of Things (IoT), digital twins, big data, cloud computing, and artificial intelligence. To address the challenges of multi-protocol conversion, multi-protocol fusion gateways are typically deployed to meet the interconnectivity requirements of industrial field equipment. These gateways aim to provide a unified data management solution for multi-protocol parsing, thereby providing technical support for data concurrency, collection, extraction, storage, sharing, correlation analysis, and data mining and analysis.

[0003] The coexistence of multiple communication protocols is a serious problem in the Industrial Internet of Things (IIoT) environment. Traditional industrial sites widely use protocols such as Modbus, Profibus, and CAN bus, while new IoT devices mostly adopt MQTT, OPC UA, and CoAP. Data from the Industrial Automation Association shows that over 65% of factories have three or more protocols coexisting, making protocol conversion a key bottleneck. The lifespan of industrial equipment is as long as 10 to 15 years, resulting in significant differences in protocols between different manufacturers and at different times. As industrial enterprises grow their demand for device data analysis and remote monitoring, the difficulty of connecting traditional devices to cloud platforms severely hinders data value extraction. Existing commercial protocol gateways are expensive, complex to configure, and lack scalability, making them unable to meet the customized needs of small and medium-sized enterprises.

[0004] However, due to the complexity of the industrial Internet, there are still many industrial protocols that need to be interoperable in real industrial environments, and there is still a lack of relevant equipment to comprehensively convert and interoperate these protocols. Summary of the Invention

[0005] In view of the above shortcomings and deficiencies, the present invention provides an industrial communication protocol conversion system and conversion method to achieve two-way conversion between multiple industrial communication protocols and improve the intelligence and information level of industrial field equipment.

[0006] In order to achieve the above objectives, the main technical solution adopted by the present invention is an industrial communication protocol conversion system, comprising: The data acquisition module is used to perform communication parameter configuration, link establishment, protocol handshake, send requests to field devices and receive responses. The data acquisition module includes a communication interface module and an exception handling module; Communication interface module, used to support communication connections of physical interfaces such as RS-485, TCP / IP, and CAN; Exception handling module, used to perform error recording and reconnection operations when communication is abnormal; Protocol conversion module, used to implement protocol analysis, standardized modeling, and protocol repackaging; The data output module is used to push and store data through MQTT or database.

[0007] The protocol conversion module uses Python pymodbus library, opcua library and Socket to build a parsing engine. It supports the parsing and conversion of Modbus, OPC UA, IEC101, IEC104 and DL / T645 protocols through a standardized data extraction process based on function codes.

[0008] An industrial communication protocol conversion method includes the following steps Step S1: Data collection of industrial communication source protocols; the source protocol and the conversion target protocol include at least one of Modbus, OPC UA, IEC101, IEC104, DL / T645, and MQTT, supporting bidirectional conversion; Step S101: configuring corresponding communication parameters for different protocols; Step S102, establishing a link connection: according to the physical link type, creating a TCP connection through a socket, opening a CAN channel through a driver, or opening an RS485 communication link through serial port initialization configuration; Step S103: Construct a data frame that complies with the protocol, send a read or write request to the device, and receive its response; Step S2, protocol conversion: convert the source protocol data into the target protocol data in the order of protocol parsing, standardized modeling, and protocol repackaging; wherein the protocol parsing parses the original data transmitted from different hardware interfaces according to the corresponding industrial protocol: extracts key information including address, control code, data length and data field in the message, decodes the data field according to the definition of different protocols, and finally returns the parsed structured data in the form of a dictionary or list to facilitate subsequent applications to process and analyze the collected industrial equipment data; standardized modeling parses the data into a data model in a unified format including device identification, variable name, and data type; protocol repackaging re-encodes the data model in the unified format into a data frame that conforms to the communication specification according to the target protocol rules; Step S3, data output: the obtained target protocol data is pushed to a third-party server via the MQTT protocol or directly stored in a database for access by a third-party system.

[0009] Step S1 also includes an exception handling and reconnection mechanism. When communication fails, the device does not respond, or the link is abnormal, an error log is recorded and an attempt is made to reconnect or restore the communication link.

[0010] In step S101 The Modbus protocol configuration fields include the device's IP address, port number or serial port number, baud rate, data bits, parity bit, stop bit, read timeout, whether to process local echo, number of retries on failure, and reconnection interval; The OPC UA protocol configuration fields include the URL of the OPC UA server and the connection timeout; The configuration fields of the DL / T645 protocol, IEC01 protocol, and IEC04 protocol include the device's IP address, port number, and socket timeout.

[0011] Step S102 establishes a link connection. First, it is selected whether protocol handshake or link activation is required according to the source protocol type. Specifically, handshake or link activation is performed for OPC UA, IEC101, and IEC104 protocols, and stateless or lightweight handshake is performed for Modbus and DL / T645 protocols.

[0012] In step S103, the Modbus protocol is based on the pymodbus library to achieve connection with the Modbus PLC device and data read and write operations; the OPC UA protocol is based on the opcua library to achieve connection with the OPC UA PLC device and data read and write operations; the IEC101, IEC104 and DL / T645 protocols achieve connection with the device and data read and write operations through Socket communication.

[0013] The data model of the standardized modeling in step S2 is a structure including device identification, variable name, data type, actual value, timestamp, quality code and protocol field, which uniformly shields protocol differences.

[0014] The protocol repackaging in step S2 includes data format conversion, byte order adjustment, and frame structure assembly, so as to facilitate transmission of the data to a third-party server or system through the target protocol.

[0015] In step S3, the data pushed via MQTT is encapsulated in JSON format and pushed to a third-party server; the data stored in the database supports database types such as MySQL and InfluxDB, and provides a REST API for third-party system calls.

[0016] The present invention has the following beneficial effects and advantages: The present invention simultaneously supports TCP / IP Ethernet communication, RS-485 serial communication and CAN communication, realizing seamless switching across physical layer protocols; through the three core technologies of protocol analysis, unified data modeling and protocol encapsulation, it realizes lossless conversion between different industrial protocols, providing an efficient and reliable data communication infrastructure for industrial automation systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of the industrial communication protocol conversion method of the present invention. DETAILED DESCRIPTION

[0018] The present invention will be further described below in conjunction with the accompanying drawings. Figure 1 As shown, the present invention is an industrial communication protocol conversion system, comprising: The data acquisition module is used to perform communication parameter configuration, link establishment, protocol handshake, and send requests to field devices (PLC or sensors, etc.) and receive responses. The data acquisition module includes a communication interface module and an exception handling module. Communication interface module, used to support communication connections of physical interfaces such as RS-485, TCP / IP, and CAN; Exception handling module, used to perform error recording and reconnection operations when communication is abnormal; The protocol conversion module uses the Python pymodbus library, opcua library, and Socket to build a parsing engine. Through a standardized data extraction process based on function codes, it supports parsing and conversion of Modbus, OPC UA, IEC101, IEC104, and DL / T645 protocols. It is used to implement protocol parsing, standardized modeling, and protocol repackaging. The data output module is used to push and store data through MQTT or database.

[0019] Based on the above industrial communication protocol conversion method, the following steps are included: Step S1: Data collection from industrial communication source protocols. The source and target protocols include at least one of Modbus, OPC UA, IEC101, IEC104, DL / T645, and MQTT, supporting bidirectional conversion. The exception handling module implements exception handling and reconnection mechanisms. When communication fails, the device becomes unresponsive, or a link anomaly occurs, the system logs the error and attempts to reconnect or restore the communication link. Depending on application requirements, the system can choose to maintain a persistent connection or periodically disconnect. Communication resources are released and the socket / serial port is closed to prevent resource leaks.

[0020] Step S101: Configure corresponding communication parameters for different protocols; specifically, The Modbus protocol configuration fields include the device's IP address, port number or serial port number, baud rate, data bits, parity bit, stop bit, read timeout, whether to process local echo, number of retries on failure, and reconnection interval; The OPC UA protocol configuration fields include the URL of the OPC UA server and the connection timeout; The configuration fields of the DL / T645 protocol, IEC01 protocol, and IEC04 protocol include the device's IP address, port number, and socket timeout.

[0021] Step S102: Establishing a Link Connection: To establish a link connection, first determine whether a protocol handshake or link activation is required based on the source protocol type. Specifically, a handshake or link activation is performed for OPC UA, IEC101, and IEC104 protocols, and a stateless or lightweight handshake is performed for Modbus and DL / T645 protocols. Then, depending on the physical link type, a TCP connection is created via a socket, a CAN channel is opened via a driver, or an RS485 communication link is opened via serial port initialization configuration. Step S103: Construct a data frame that complies with the protocol, send a read or write request to the device, and receive its response. Specifically, the Modbus protocol is based on the pymodbus library to implement connection with Modbus PLC devices and data read and write operations. The OPCUA protocol is based on the opcua library to implement connection with OPC UA PLC devices and data read and write operations. The IEC101, IEC104, and DL / T645 protocols implement connection with devices and data read and write operations through Socket communication.

[0022] Step S2, Protocol Conversion: Convert source protocol data to target protocol data in the order of protocol parsing, standardized modeling, and protocol repackaging. Leveraging a unified data model, this overcomes language barriers between multi-protocol devices, ultimately enabling interoperability between devices from different manufacturers and with different standards, providing efficient data support for industrial automation, monitoring systems, and cloud platforms. Protocol conversion is accomplished via a protocol conversion gateway.

[0023] Protocol parsing parses raw data transmitted from different hardware interfaces (RS-485, TCP / IP, CAN) according to the corresponding industrial protocols (Modbus, OPC UA, DL / T 645, IEC101, IEC04): it performs format check and decomposition on the received raw protocol message, extracts key information such as the address, control code, data length and data field in the message, and decodes the data field according to the definition of different protocols. For example, it converts BCD code to decimal, parses telemetry values ​​according to type identifiers, decodes Modbus register data, or converts OPC UA node values ​​according to data type. Finally, the parsed structured data is returned in the form of a dictionary or list, which facilitates subsequent applications to process and analyze the collected industrial equipment data.

[0024] Standardized modeling is a core bridge in protocol conversion, aiming to parse raw data from diverse industrial protocols (Modbus, OPC UA, DL / T 645, IEC101, and IEC04) into a unified data model format. This model abstracts the structure, including device identification, variable name (tag), data type, actual value, timestamp, quality code, and protocol fields, masking underlying protocol differences. This process ensures that subsequent data storage, analysis, forwarding, and business logic processing can utilize consistent interfaces, regardless of the protocol details of the data source.

[0025] Protocol repackaging involves re-encoding standardized data models into data frames that conform to the target protocol's communication specifications, based on the rules of the target protocol. This process includes data format conversion (e.g., floating-point to register, integer to BCD), byte order adjustment, and frame structure assembly (e.g., header, function code, check digit, etc.). This ensures that data can be reliably transmitted to the target device or system via the target protocol (e.g., OPC UA write node, Modbus message delivery, DL / T 645 reply frame, etc.), thus enabling data "land execution" or "write-back control."

[0026] Step S3, data output: The target protocol data obtained is encapsulated into JSON format and pushed to a third-party server through MQTT. The data stored in the database supports MySQL and InfluxDB database types, and provides REST API for third-party system calls.

[0027] Taking the conversion of Modbus protocol to OPC UA protocol as an example, the overall process of industrial protocol data collection and protocol conversion is as follows: The Modbus protocol can be used for data acquisition via serial communication (Modbus RTU) through the RS-485 interface, or via Ethernet communication (Modbus TCP) through the TCP / IP network.

[0028] The communication process for implementing Modbus communication over a TCP / IP network using the Python pymodbus library is as follows: First, the data acquisition module configures its IP address and port number. Then, a communication interface module (such as ModbusTcpClient, a Modbus TCP client class for connecting to field devices) connects to the field device's IP address and port (default is 502). Once connected, the communication interface module can send read or write requests, such as reading register data or controlling the on / off state of a coil. The field device operates as a Modbus TCP server, continuously listening for requests from the communication interface module. Upon receiving a request, it parses the request content, performs the corresponding operation (such as reading a register or writing a coil), and then packages the results and returns them to the data acquisition module over the network. The entire data exchange process follows the Modbus TCP protocol. The data format is encapsulated according to the Modbus Application Protocol (MBAP) and transmitted over the TCP / IP network, enabling stable and efficient communication between the master and slave devices.

[0029] The communication process for implementing Modbus communication over the RS-485 bus using the Python pymodbus library is as follows: First, the data acquisition module connects to the RS-485 network via a serial interface (such as / dev / ttyS0 in Linux or COM1 in Windows). Then, using the communication interface module (a client utility class such as ModbusSerialClient, which communicates with field devices via the serial port), communication parameters such as the serial port number, baud rate, data bits, parity, stop bits, read timeout, whether to process local echo, number of retries upon failure, and reconnection interval are configured. Once connected, the communication interface module can send Modbus requests to the field device, such as reading register data or controlling coil status. The communication interface module listens for requests on the bus, interprets the instructions, and performs the corresponding operations (such as read and write operations) before returning the results to the data acquisition module via the RS-485 bus. This communication is based on the Modbus protocol and uses a half-duplex serial mode, meaning data can only be transmitted in one direction at any given time. This enables reliable and efficient data exchange in an environment where multiple devices share the bus.

[0030] When communication fails, the device does not respond, or the link is abnormal, the exception handling module records the error log and attempts to reconnect or restore the communication link.

[0031] The protocol conversion module maps and associates the register addresses and data in the Modbus protocol with the nodes in the OPC UA protocol, realizing the conversion of data semantics and structures between the two protocols.

[0032] Parsing Modbus data: After reading raw register data via Modbus, the parsing process is divided into four steps: 1) Determine the data type (such as INT16 / FLOAT32) and byte order (big endian / little endian) according to the device protocol; 2) Combine the 16-bit registers into a byte string of the required length; 3) Use struct.unpack or bitwise operations to convert to the actual value; 4) Apply a scaling factor (such as 0.1) or a formula to obtain the final engineering value.

[0033] Standardized modeling: Encapsulate the parsed data into a unified intermediate model, including device identification, variable name (Tag), data type, actual value, timestamp, quality code, and protocol field, providing standardized input for OPC UA nodes.

[0034] Protocol repackaging: Map standardized data to OPC UA nodes, define namespaces, node IDs, and data types, and publish the nodes through an OPC UA server (such as the asyncua library). This ultimately generates a hierarchical node tree that conforms to the OPC UA information model, allowing clients to access the data through URLs.

[0035] The data output module encapsulates the converted OPC UA data into JSON format and pushes it to the cloud or edge server through the MQTT Broker.

Claims

1. A method for converting an industrial communication protocol, characterized in that: The following steps are involved: Step S1: Data collection of industrial communication source protocols; the source protocol and the conversion target protocol include at least one of Modbus, OPC UA, IEC101, IEC104, DL / T645, and MQTT, supporting bidirectional conversion; Step S101: configuring corresponding communication parameters for different protocols; Step S102, establishing a link connection: according to the physical link type, creating a TCP connection through a socket, opening a CAN channel through a driver, or opening an RS485 communication link through serial port initialization configuration; Step S103: Construct a data frame that complies with the protocol, send a read or write request to the device, and receive its response; Step S2, protocol conversion: convert the source protocol data into the target protocol data in the order of protocol parsing, standardized modeling, and protocol repackaging; wherein the protocol parsing parses the original data transmitted from different hardware interfaces according to the corresponding industrial protocol: extracts key information including address, control code, data length and data field in the message, decodes the data field according to the definition of different protocols, and finally returns the parsed structured data in the form of a dictionary or list to facilitate subsequent applications to process and analyze the collected industrial equipment data; standardized modeling parses the data into a data model in a unified format including device identification, variable name, and data type; protocol repackaging re-encodes the data model in the unified format into a data frame that conforms to the communication specification according to the target protocol rules; Step S3, data output: the obtained target protocol data is pushed to a third-party server via the MQTT protocol or directly stored in a database for access by a third-party system.

2. The industrial communication protocol conversion method according to claim 1, characterized in that: Step S1 also includes an exception handling and reconnection mechanism. When communication fails, the device does not respond, or the link is abnormal, an error log is recorded and an attempt is made to reconnect or restore the communication link.

3. The industrial communication protocol conversion method according to claim 1, characterized in that: In step S101 The Modbus protocol configuration fields include the device's IP address, port number or serial port number, baud rate, data bits, parity bit, stop bit, read timeout, whether to process local echo, number of retries on failure, and reconnection interval; The OPC UA protocol configuration fields include the URL of the OPC UA server and the connection timeout; The configuration fields of the DL / T645 protocol, IEC01 protocol, and IEC04 protocol include the device's IP address, port number, and socket timeout.

4. The industrial communication protocol conversion method according to claim 1, characterized in that: Step S102 establishes a link connection. First, it is selected whether protocol handshake or link activation is required according to the source protocol type. Specifically, handshake or link activation is performed for OPC UA, IEC101, and IEC104 protocols, and stateless or lightweight handshake is performed for Modbus and DL / T645 protocols.

5. The industrial communication protocol conversion method according to claim 1, characterized in that: In step S103, the Modbus protocol is based on the pymodbus library to achieve connection with the Modbus PLC device and data read and write operations; the OPC UA protocol is based on the opcua library to achieve connection with the OPC UA PLC device and data read and write operations; the IEC101, IEC104 and DL / T645 protocols achieve connection with the device and data read and write operations through Socket communication.

6. The industrial communication protocol conversion method according to claim 1, characterized in that: The data model of the standardized modeling in step S2 is a structure including device identification, variable name, data type, actual value, timestamp, quality code and protocol field, which uniformly shields protocol differences.

7. The industrial communication protocol conversion method according to claim 1, characterized in that: The protocol repackaging in step S2 includes data format conversion, byte order adjustment, and frame structure assembly, so as to facilitate transmission of the data to a third-party server or system through the target protocol.

8. The industrial communication protocol conversion method according to claim 1, characterized in that: In step S3, the data pushed via MQTT is encapsulated in JSON format and pushed to a third-party server; the data stored in the database supports database types such as MySQL and InfluxDB, and provides a REST API for third-party system calls.

9. An industrial communication protocol conversion system, characterized in that: include: The data acquisition module is used to perform communication parameter configuration, link establishment, protocol handshake, send requests to field devices and receive responses. The data acquisition module includes a communication interface module and an exception handling module; Communication interface module, used to support communication connections of physical interfaces such as RS-485, TCP / IP, and CAN; Exception handling module, used to perform error recording and reconnection operations when communication is abnormal; Protocol conversion module, used to implement protocol analysis, standardized modeling, and protocol repackaging; The data output module is used to push and store data through MQTT or database.

10. The industrial communication protocol conversion system according to claim 9, characterized in that: The protocol conversion module uses Python pymodbus library, opcua library and Socket to build a parsing engine. It supports the parsing and conversion of Modbus, OPC UA, IEC101, IEC104 and DL / T645 protocols through a standardized data extraction process based on function codes.

Images