Cross-platform equipment communication protocol conversion method based on gateway

Abstract

The invention discloses a gateway-based cross-platform equipment communication protocol conversion method. The method comprises the following steps: (1) a hardware layer comprises a processing unit, a storage module, a communication interface module and a security unit; (2) the software layer comprises a multi-modal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module and a security enhancement module; (3) equipment access and protocol feature identification; (4) loading the dynamic protocol plug-in; (5) requesting and transmitting the plug-in; (6) performing plug-in security authentication; (7) data analysis and semantic conversion; (8) according to a networking scene, local data processing or multi-gateway protocol collaboration is carried out through an edge collaborative computing module; and (9) after security verification and encryption are carried out by a security enhancement module, data forwarding and cross-domain communication are completed. According to the method, the protocol adaptation staticizing limitation can be broken through, the semantic interoperation precision of heterogeneous data is improved, the edge calculation and cooperation capability is enhanced, and a multi-layer security protection system is constructed.

Description

Technical Field

[0001] The present invention relates to the technical field of integration of industrial Internet and Internet of Things, and in particular to a gateway-based cross-platform device communication protocol conversion method. Background Art

[0002] In scenarios where the Industrial Internet and the Internet of Things converge, devices often use heterogeneous communication protocols such as Modbus, OPC UA, MQTT, BACnet, CAN, and Modbus TCP, leading to significant challenges in interoperability across cross-platform devices. Traditional protocol conversion gateways, as core components connecting heterogeneous devices with upper-layer systems, have the following significant technical flaws: (1) The protocol adaptation capability is rigid and dynamic expansion is insufficient Existing gateways generally use a static protocol library architecture, supporting only pre-integrated fixed protocols. Adding new protocols requires an offline firmware upgrade or a gateway restart, and there's no way to dynamically load protocol plug-ins at runtime. The fundamental flaw lies in the tight coupling of the protocol parsing module with the core gateway logic, relying on hard-coded protocol parsing, and failing to meet the flexible adaptation requirements of multi-protocol hybrid access scenarios.

[0003] (2) Lack of semantic parsing of heterogeneous data and insufficient conversion accuracy Traditional gateways only implement syntactic conversion of data formats (e.g., converting Modbus register addresses to JSON fields) and lack an understanding of data semantics. This leads to the following problems: First, semantic ambiguity and data distortion. Different protocols define the same physical quantity differently (for example, temperature data in the Modbus protocol may be stored as an integer with a unit of 0.1°C, while the OPC UA protocol directly represents °C as a floating-point value). Traditional gateways, when performing conversions through fixed mapping tables, tend to ignore semantic information such as units and precision, leading to data errors. For example, a Modbus register value of 256 is directly mapped to 256°C in OPC UA, when the actual value should be 25.6°C, resulting in a high error rate. Second, traditional gateways have limited ability to handle complex data structures. For structured data with contextual relationships (such as a collection of device status parameters), traditional solutions rely on hard-coded rules for field-by-field mapping. This fails to identify semantic relationships between data (e.g., the correlation between voltage and current), making it difficult to meet the data integrity and accuracy requirements of industrial scenarios.

[0004] (3) Lack of edge computing capabilities, insufficient real-time and collaborative capabilities Traditional gateways lack local data processing capabilities and require all raw data to be uploaded to the cloud for protocol conversion and business logic processing, resulting in: High transmission latency: Industrial control scenarios require data processing latency of less than 50ms. However, traditional solutions require round-trip data transmission from the gateway to the cloud and then to the application system, resulting in latency exceeding 200ms. This cannot meet real-time control requirements (such as robot motion control and production line linkage). Strong network dependence: When the network fluctuates or is disconnected, the communication between the device and the cloud is interrupted, causing the entire system to crash; Poor collaboration: Multiple gateways cannot share protocol resources or device status information, repeatedly loading the same protocol plug-in, wasting computing resources (for example, multiple gateways in the same factory each load a Modbus plug-in, resulting in redundant memory usage).

[0005] (4) Weak security protection mechanism, risk of protocol layer attacks Existing gateways lack effective security measures during protocol parsing and data transmission: (4-1) Lack of security for protocol plug-ins: Third-party protocol plug-ins may be maliciously tampered with (e.g., by inserting virus code), but traditional gateways do not perform signature authentication on plug-ins, causing malicious code to be loaded into the system along with the plug-in, resulting in device control anomalies or data leakage; (4-2) Data transmission and storage are not encrypted: Communication data between devices and gateways (such as Modbus RTU serial port data) and data between gateways and the cloud (such as MQTT messages) are often transmitted in plain text and are easily intercepted and tampered with. Stored protocol configuration files and mapping rules are also not encrypted, posing a risk of sensitive information leakage. (4-3) Lack of access control: Access devices are not authenticated (such as MAC address whitelisting and digital certificate verification). Illegal devices can forge protocol data to launch attacks, causing gateway resource exhaustion or incorrect conversion. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a gateway-based cross-platform device communication protocol conversion method. This gateway-based cross-platform device communication protocol conversion method can break through the static limitations of protocol adaptation, improve the accuracy of semantic interoperability of heterogeneous data, enhance edge computing and collaboration capabilities, and build a multi-layer security protection system.

[0007] In order to solve the above technical problems, the technical solutions adopted by the present invention are as follows: A gateway-based cross-platform device communication protocol conversion method, characterized by comprising the following steps: (1) Hardware layer construction: The hardware layer includes processing unit, storage module, communication interface module and security unit; (2) Software layer configuration: The software layer includes a multimodal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module, and a security enhancement module; (3) Device access and protocol feature identification: After the device is connected, the device's protocol type is identified through the multimodal protocol dynamic loading module, and the protocol feature library is matched: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered; (4) Dynamic protocol plug-in loading: Dynamically load the module through the multimodal protocol to query the matching protocol plug-in: If a matching protocol plug-in exists, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in, proceed to step (5); (5) Plug-in request and transmission: Request plug-ins from the cloud server or adjacent gateway through the edge collaborative computing module; (6) Plug-in security authentication: The plug-in is authenticated by the security enhancement module. After passing the authentication, it is loaded into the memory and proceeds to step (7); (7) Data parsing and semantic conversion: calling plug-ins to parse data and complete data conversion through the semantic data mapping engine; (8) Edge data processing and collaboration: Based on the networking scenario, local data processing or multi-gateway protocol collaboration is performed through the edge collaborative computing module; (9) After security verification and data encryption by the security enhancement module, data forwarding and cross-domain communication are completed.

[0008] The hardware layer of the above step (1) is the physical foundation of the system. It is dominated by a high-performance, low-power processing unit (such as a central processing unit CPU, ARM Cortex-A series or X86 architecture processor) to control the operation. It is equipped with a large-capacity storage module (such as 1GB and above DDR4) to support dynamic loading and temporary storage, supplemented by flash memory or solid-state drives (8GB-128GB) to store key system data. Device connection is achieved through an integrated communication interface module, and data security is guaranteed by a security unit, providing a solid physical support for software operation and data processing. The above storage module includes memory and storage devices. The above security unit includes a security encryption chip; the security encryption chip is a national secret SM4 chip or AES chip. The above central processing unit (CPU) provides computing resources for software modules (such as semantic mapping algorithms), memory (RAM) provides temporary storage space for plug-ins and data processing, and storage devices (ROM) persistently store protocol plug-ins, semantic ontology models and system configurations; the communication interface module serves as the physical connection channel between the software layer and external devices / systems, and the security encryption chip provides hardware-level encryption acceleration (such as SM4 algorithm hardware implementation) for the security module of the software layer.

[0009] The present invention creates an architecture that deeply integrates hardware security support and software intelligent processing: the hardware layer integrates security encryption chips and high-performance processing units to jointly ensure data security and processing efficiency; the software layer relies on multi-modal protocol dynamic loading modules to realize flexible parsing and management of heterogeneous protocols, and uses a semantic data mapping engine to complete the semantic unification and conversion of heterogeneous data based on the ontology model, and realizes local fast processing and multi-gateway distributed collaboration through the edge collaborative computing module. The security enhancement module runs through the entire process to ensure system security, and realizes efficient, secure and flexible cross-platform device communication protocol conversion as a whole, effectively overcoming the difficulties of multi-protocol device interconnection and data interaction in industrial scenarios, and providing innovative solutions for industrial Internet applications.

[0010] In a preferred embodiment, in step (1), the communication interface module includes multiple wired communication interfaces, multiple wireless communication interfaces, and multiple peripheral modules; the wired communication interface is an Ethernet interface, an RS-485 interface, an RS-232 interface, or a CAN interface; the wireless communication interface is a Wi-Fi interface or a Bluetooth interface; and the peripheral module is a power management interface or a USB debugging port. The Ethernet interface may be an RJ45 interface.

[0011] In the preferred embodiment, in step (2), the multimodal protocol dynamic loading module is provided with a protocol feature identification unit and a plug-in management unit; the semantic data mapping engine is provided with a mapping algorithm module; the edge collaborative computing module is provided with a collaborative communication interface and a local processing engine; and the security enhancement module is provided with a plug-in signature verification unit and an access control unit. The above software layer is the core of the system. The multimodal protocol dynamic loading module is dynamically managed by the protocol feature identification unit to realize heterogeneous protocol parsing; the semantic data mapping engine relies on the ontology model library and mapping algorithm to complete the unified data semantic conversion; the edge collaborative computing module optimizes data with the help of the local processing engine and realizes multi-gateway collaboration through the collaborative communication interface; the security enhancement module comprehensively ensures system security from plug-in verification, data encryption to access control, and each module collaboratively realizes key functions such as protocol conversion, semantic mapping and security processing. The software layer controls the start and stop of the hardware interface (such as turning on the RS-485 port to monitor device access) through the driver, configures communication parameters (such as baud rate, data bits), and calls the security encryption chip interface to realize data encryption / decryption.

[0012] In a further preferred embodiment, the device access and protocol feature identification in step (3) includes the following steps: (3.1) Hardware connection and data monitoring: The device connects to the gateway through the communication interface module of the hardware layer, initializes the hardware layer and monitors the data port; (3.2) Protocol feature recognition: The protocol feature recognition unit in the multimodal protocol dynamic loading module of the software layer extracts data frame features; (3.3) Protocol type determination: Determine whether the protocol type used by the device matches the protocol signature library through the preset protocol signature library: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered.

[0013] In a further preferred embodiment, extracting data frame features in step (3.2) includes parsing a handshake packet, identifying a port number, and matching a data frame format. The handshake packet may be a Modbus RTU slave address, a Modbus RTU function code, or an MQTT CONNECT message. The port number may be Modbus TCP default port 502 or MQTT default port 1883. The data frame format may be a 29-bit identifier of the CAN protocol or a Modbus CRC checksum. The data frame features may be a Modbus function code 0x03 or an MQTT fixed header 0x10.

[0014] In a further preferred embodiment, the protocol feature library in step (3.3) is the read holding register of Modbus function code 0x03 or the NPDU message header of BACnet; and the protocol type is Modbus RTU protocol or MQTT protocol.

[0015] In a further preferred embodiment, in step (4), the local plug-in library is queried by the plug-in management unit in the multimodal protocol dynamic loading module to determine whether there is a matching protocol plug-in in the local plug-in library: If a matching protocol plug-in exists in the local plug-in library, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in in the local plug-in library, proceed to step (5).

[0016] In step (4), if the local plug-in library does not contain a matching protocol plug-in, the plug-in request and transmission in step (5) is performed. That is, a plug-in acquisition request is initiated to the cloud server or adjacent gateway through the collaborative communication interface of the edge collaborative computing module to ensure that the protocol parsing capability can still be supplemented through the collaborative mechanism when there is no local plug-in. The cloud server can be the Docker Hub industrial protocol plug-in library. The gateway can be a gateway that has already loaded the target plug-in.

[0017] In a further preferred embodiment, in step (5), requesting a plug-in from a cloud server or an adjacent gateway through the collaborative communication interface of the edge collaborative computing module includes the following steps: (5-1) Cloud scenario: Download from the preset plug-in repository; (5-2) Edge Collaboration Scenario: Request the plugin file from the gateway that has loaded the plugin via the DHT network. The plugin repository can be the Docker Hub Industrial Protocol Plugin Library. The plugin file can be a .so / .dll file or a Docker image file. The request format can be: {protocol:"Modbus RTU",version:"1.0"}.

[0018] In a further preferred embodiment, the step (6) is performed by the plug-in signature verification unit of the security enhancement module to perform the following steps: (6.1) extracting the digital signature file of the plug-in and verifying the signature hash value using the CA public key to ensure that the plug-in has not been tampered with; (6.2) Check if the plugin metadata matches the current device: If the plugin metadata matches the current device, it is loaded into memory and proceeds to step (7); If the plugin metadata does not match the current device, reject and log it.

[0019] In a further preferred embodiment, the data parsing and semantic conversion in step (7) includes: (7.1) Syntax-level data parsing: calling the parsing function of the loaded protocol plug-in to convert the original binary data into an intermediate format; (7.2) Semantic ontology mapping: The mapping algorithm module of the semantic data mapping engine performs bidirectional conversion based on the semantic ontology model library.

[0020] In the above step (7), the loaded protocol plug-in is called to parse the original data into an intermediate format (such as JSON). The semantic data mapping engine maps the intermediate format into a unified semantic entity (such as {"entity":"TemperatureData","value":25.6,"unit":"℃"}) based on the semantic ontology model library and encapsulates it according to the target protocol (such as OPC UA).

[0021] The parsing function of the loaded protocol plug-in can be parse(data) of the Modbus plug-in; the intermediate format can be a JSON object, for example: { "protocol":"Modbus RTU", "device_id":"01", "register_address":"0x0100", "raw_value":256 } In a further preferred embodiment, in step (7.1), protocol plug-ins are constructed by developing each protocol parsing plug-in using C++ / Python, encapsulating the protocol parsing function, and digitally signing it. The plug-in and signature file are then stored in a local plug-in library or a cloud server. The protocol parsing plug-in includes a Modbus RTU plug-in, an MQTT plug-in, or a BACnet plug-in. The protocol parsing function can use parse_modbus(data). The digital signature is generated by calling the secure encryption chip API to generate an RSA signature.

[0022] In a further preferred embodiment, in step (7.2), the semantic ontology model library is imported by constructing an industrial domain ontology model based on the OWL language, defining entity classes, attributes, and relationships, and importing the semantic ontology model library into the gateway storage module via USB or a network. The industrial domain ontology model can be a temperature data ontology or a pressure data ontology. The entity class can be a device class or a data class. The attributes can be values, units, or precision. The relationships can be belongs to or contains relationships. The semantic ontology model library is a .owl file.

[0023] In a further preferred embodiment, in step (7.2), the bidirectional conversion of semantic ontology mapping includes: (7.2.1) Source protocol to ontology model: Identify corresponding ontology entities, apply transformation rules, extract semantic metadata, and generate ontology instances; (7.2.2) Ontology model to target protocol: Convert the ontology instance into the target data structure according to the format requirements of the target protocol.

[0024] The target protocol may be MQTT or OPC UA. For example, the target data structure may have a payload of 25.6 bytes for MQTT and a JSON metadata description unit.

[0025] The source protocol in the above step (7.2.1) is converted to the ontology model: identify the ontology entity "TemperatureData" corresponding to raw_value (through the mapping rules between register addresses and ontology models), apply the conversion rules (such as value = raw_value / 10), extract the semantic metadata (unit "℃", precision 0.1, function "device temperature monitoring"), and generate the ontology instance: { "entity":"TemperatureData", "value":25.6, "unit":"℃", "precision":0.1, "description":"Device temperature monitoring"} In a further preferred embodiment, the step (8) edge data processing and collaboration includes: (8.1) Network scenario judgment: Use static configuration judgment and dynamic automatic identification methods to determine whether the gateway is a multi-gateway network scenario: If the gateway is not a multi-gateway networking scenario, it is determined to be a single gateway and proceed to step (8.2); If the gateway is a multi-gateway networking scenario, it is determined to be a multi-gateway networking and step (8.3) is performed; (8.2) Localized preprocessing: Data filtering, aggregation calculation, and protocol preprocessing are performed by the local processing engine of the edge collaborative computing module, and step (9) is performed. (8.3) Multi-gateway protocol sharing: Implement multi-gateway protocol plug-in sharing and data synchronization through the collaborative communication interface of the edge collaborative computing module, and proceed to step (9).

[0026] In the above step (8.2), the edge collaborative computing module performs filtering (such as discarding outliers), aggregation (such as calculating the 5-minute average value), and protocol preprocessing (such as splitting into small packets suitable for MQTT transmission) on the semantic data to reduce data redundancy.

[0027] In the above step (8.3), protocol plug-ins not stored locally (such as newly acquired BACnet plug-ins) are shared with adjacent gateways through the DHT network or MQTT protocol to synchronize device status data (such as device online / offline status), thus achieving distributed sharing of gateway plug-ins and data within the region.

[0028] In a further preferred embodiment, the method of static configuration determination and dynamic automatic identification in step (8.1) includes: (8.1.1) Static configuration determination method: Read the configuration file during the initialization phase. If the configuration file displays network_mode: "cluster", it is determined to be a multi-gateway network and skip step (8.1.2). If the configuration file displays network_mode: "local", it is determined to be a single gateway network. (8.1.2) Dynamic automatic identification method: If static parameters are not configured, the gateway will be started and executed through the edge collaborative computing module: -Send a response message to the edge collaborative computing module to try to discover adjacent gateways; - If a response is received from another gateway within 30 seconds, it is determined to be a multi-gateway network, and the plug-in sharing and data synchronization process will be activated; -If there is no response after the timeout, it is determined to be a single gateway and only the localization preprocessing of step (8.2) is performed.

[0029] The above configuration file can be a config.json file.

[0030] In a further preferred embodiment, in step (8.2), data filtering involves threshold detection. If semantic data is greater than or less than the threshold, the semantic data is marked as an outlier and discarded. Aggregation calculation involves downsampling high-frequency data or calculating cumulative values. Protocol preprocessing involves splitting long data frames into short frames supported by the target protocol. For example, this involves converting long BACnet messages into multi-packet Modbus transmission.

[0031] In a further preferred embodiment, in step (8.3), plug-in sharing is to broadcast the newly loaded protocol plug-in metadata to all gateways in the subnet, and other gateways update the local plug-in index; and data synchronization is to send the processed key data to adjacent gateways through the collaborative communication interface to support distributed decision-making.

[0032] In a further preferred embodiment, step (9) includes the following steps: (9.1) Device identity authentication: The device identity is verified by the access control unit in the security enhancement module; (9.2) Data encryption processing: transmission encryption and storage encryption; (9.3) Target data forwarding; (9.4) Protocol encapsulation and transmission.

[0033] In the above step (9), the security enhancement module performs SM4 encryption on the processed data (calling the encryption interface of the security encryption chip) and sends it to the cloud server or target device through the TLS / SSL channel, while recording the data transmission log (time, source address, target address, data type).

[0034] In a further preferred embodiment, in step (9.1), when verifying the device's identity through the access control unit in the security enhancement module, it is necessary to check whether the device's MAC address is on the whitelist. SSL two-way authentication is also performed on devices that support digital certificates, and the connection is disconnected if authentication fails. The device connects to the gateway via an interface such as RS-485 / Ethernet. The security enhancement module verifies the device's MAC address / digital certificate (e.g., SSL two-way authentication) and matches it to the device whitelist. If successful, the data channel is opened. This SSL authentication refers to the device sending a certificate or the gateway using the CA public key for verification.

[0035] In a further preferred embodiment, in step (9.2), the transmission encryption method is selected based on the target protocol, using the national secret SM4 algorithm or AES-256 algorithm to encrypt the data payload and generate ciphertext. When the data is temporarily stored in the gateway storage module, the storage encryption method uses AES-256 encryption on sensitive files such as semantic models and plug-in configurations, with the key generated and managed by the secure encryption chip. These encryption methods can use MQTT over TLS or Modbus TCP with SSL.

[0036] In a further preferred embodiment, the target data in step (9.3) is forwarded by selecting the following different communication interfaces according to the configuration rules: Device-side forwarding: sending control instructions to other devices via RS-485 interface or CAN interface; Cloud forwarding: Send data to the cloud server via Ethernet interface or 4G interface; Local system forwarding: transmits data to the local system through the LAN interface.

[0037] The above configuration rules can use a user-preset "Modbus device → MQTT cloud" mapping. The above control instructions can be parsed Modbus write instructions. The above cloud server can be Alibaba Cloud IoT or Siemens MindSphere. The above local system can be a local SCADA system.

[0038] In a further preferred embodiment, the protocol encapsulation and transmission in step (9.4) is to encapsulate the processed semantic data into a target protocol format and send it through the communication layer interface to achieve cross-platform communication. The target protocol format can be an MQTT message or an OPC UA service request.

[0039] The preferred solution also includes step (10) system monitoring and maintenance: (10.1) Real-time monitoring: View the operating status of each module in real time through the gateway management interface and receive abnormal alarms; (10.2) Remote Upgrade: The cloud server pushes the protocol plug-in update package or ontology model patch. After the gateway downloads it through a secure channel, it triggers the plug-in hot update mechanism to ensure continuous optimization of system compatibility and security.

[0040] The gateway management interface can be a web UI. The operating status of each module can include CPU utilization, memory usage, or plugin loading. The exception can include plugin authentication failure or data encryption errors. The plugin hot update mechanism loads the new plugin first, then uninstalls the old one.

[0041] Compared with the prior art, the present invention has the following advantages: (1) Breaking through the static limitations of protocol adaptation: Flexible expansion of runtime protocol plug-ins is achieved through dynamic loading technology, which supports the access of new and private protocols without offline upgrades or restarting the gateway, solving the problems of solidified protocol libraries and low adaptation efficiency in traditional gateways.

[0042] (2) Improving the accuracy of semantic interoperability of heterogeneous data: Building a domain ontology model and an intelligent mapping engine to achieve accurate conversion of data at the semantic level, such as units, precision, and functional meaning, avoiding information distortion and ambiguity caused by syntax-level conversion, and meeting the requirements of industrial scenarios for data integrity and accuracy; (3) Enhance edge computing and collaboration capabilities: Through localized data processing and multi-gateway networking mechanisms, reduce cloud dependence, reduce data transmission latency (target <50ms), improve system real-time performance and reliability, and achieve distributed sharing of protocol resources and device status, optimizing edge node computing power utilization efficiency; (4) Build a multi-layer security protection system: Through mechanisms such as protocol plug-in signature authentication, data encryption transmission and device access control, it can resist security threats such as malicious code injection, data tampering and illegal access, and ensure the security and stability of communication between industrial Internet and Internet of Things devices.

[0043] (5) This invention builds a complete technical system for cross-platform protocol conversion through the integration of "dynamic loading + semantic mapping + edge collaboration + security enhancement". Through the full-process collaboration of "device access → dynamic protocol identification → semantic conversion → edge processing → secure transmission", cross-platform communication of heterogeneous devices is achieved. Its core principles are: dynamic adaptation of protocols through plug-in architecture, semantic unification of heterogeneous data based on domain ontology models, local processing and collaboration using edge computing capabilities, and finally reliable operation of the system through multi-layer security mechanisms.

[0044] (6) The hardware layer of the present invention relies on high-performance CPU, large-capacity storage, rich communication interfaces and secure encryption chips to provide strong physical support and data security protection; the software layer realizes flexible parsing of heterogeneous protocols through dynamic loading modules of multi-modal protocols, unifies data semantics through semantic data mapping engines, improves processing real-time performance and multi-gateway collaboration capabilities through edge collaborative computing modules, and ensures full-process security through security enhancement modules; the communication method supports multiple communications between devices, cloud and gateways, and has efficient protocol conversion, accurate semantic mapping, flexible collaboration and high security as a whole, effectively solving the cross-platform communication problems of industrial equipment, improving system compatibility, real-time performance and reliability, and adapting to the needs of complex industrial scenarios.

[0045] (7) The communication of the present invention, on the one hand, interacts with the device in real time through various communication interface modules, collects data and issues instructions; on the other hand, it communicates with the cloud server with the help of the network (Ethernet, 4G / 5G), uploads data for analysis and decision-making, and receives the configuration and instructions of the cloud server; at the same time, it supports communication between multiple gateways, uses distributed networks or message queues to share plug-ins, models and device status, improves the overall performance and reliability of the system, and ensures efficient transmission and collaboration of data between devices, gateways and the cloud. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 is a hardware architecture diagram of a specific embodiment of the present invention; Figure 2 It is a software module architecture diagram of a specific embodiment of the present invention; Figure 3 is a data conversion flow chart of a specific embodiment of the present invention; Figure 4 This is a schematic diagram of edge collaborative networking according to a specific embodiment of the present invention; Figure 5 It is a schematic diagram of a semantic ontology model of a specific embodiment of the present invention.

[0047] Remark: Figure 1 It shows the connection between the central processing unit (CPU), memory (RAM), storage devices (Flash / SSD), wired / wireless communication interfaces and security encryption chips, providing physical support for the software layer; Figure 2 The interactive relationship between the multimodal protocol dynamic loading module, semantic data mapping engine, edge collaborative computing module, and security enhancement module was demonstrated, embodying the software processing logic from protocol parsing to secure transmission. Figure 3 It demonstrates the complete process from device access to protocol feature recognition, dynamic plug-in loading, syntax and semantic analysis, edge processing, security verification, and data forwarding, demonstrating the processing logic and flow of heterogeneous data within the gateway. Figure 4 The demonstration demonstrates a networking architecture where multiple edge gateways (such as gateways A, B, and C) are connected via a DHT network or MQTT protocol to enable protocol plug-ins (such as Modbus plug-ins) to share and synchronize device status data, demonstrating the distributed collaborative nature of edge computing. Figure 5 Taking temperature data as an example, the hierarchical structure of "semantic ontology model library → data class → temperature data" and the attributes of temperature data (value, unit, precision, description) are displayed, reflecting the supporting role of the semantic ontology model in the semantic unification of heterogeneous data. DETAILED DESCRIPTION

[0048] The following is a further description of the preferred embodiments of the present invention in conjunction with the accompanying drawings.

[0049] like Figure 1-5 As shown, the gateway-based cross-platform device communication protocol conversion method in this embodiment includes the following steps: (1) Hardware layer construction: The hardware layer includes processing unit, storage module, communication interface module and security unit; (2) Software layer configuration: The software layer includes a multimodal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module, and a security enhancement module; (3) Device access and protocol feature identification: After the device is connected, the device's protocol type is identified through the multimodal protocol dynamic loading module, and the protocol feature library is matched: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered; (4) Dynamic protocol plug-in loading: Dynamically load the module through the multimodal protocol to query the matching protocol plug-in: If a matching protocol plug-in exists, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in, proceed to step (5); (5) Plug-in request and transmission: Request plug-ins from the cloud server or adjacent gateway through the edge collaborative computing module; (6) Plug-in security authentication: The plug-in is authenticated by the security enhancement module. After passing the authentication, it is loaded into the memory and proceeds to step (7); (7) Data parsing and semantic conversion: calling plug-ins to parse data and complete data conversion through the semantic data mapping engine; (8) Edge data processing and collaboration: Based on the networking scenario, local data processing or multi-gateway protocol collaboration is performed through the edge collaborative computing module; (9) After security verification and data encryption by the security enhancement module, data forwarding and cross-domain communication are completed.

[0050] The hardware layer of the above step (1) is the physical foundation of the system. It is dominated by a high-performance, low-power processing unit (such as a central processing unit CPU, ARM Cortex-A series or X86 architecture processor) to control the operation. It is equipped with a large-capacity storage module (such as 1GB and above DDR4) to support dynamic loading and temporary storage, supplemented by flash memory or solid-state drives (8GB-128GB) to store key system data. Device connection is achieved through an integrated communication interface module, and data security is guaranteed by a security unit, providing a solid physical support for software operation and data processing. The above storage module includes memory and storage devices. The above security unit includes a security encryption chip; the security encryption chip is a national secret SM4 chip or AES chip. The above central processing unit (CPU) provides computing resources for software modules (such as semantic mapping algorithms), memory (RAM) provides temporary storage space for plug-ins and data processing, and storage devices (ROM) persistently store protocol plug-ins, semantic ontology models and system configurations; the communication interface module serves as the physical connection channel between the software layer and external devices / systems, and the security encryption chip provides hardware-level encryption acceleration (such as SM4 algorithm hardware implementation) for the security module of the software layer.

[0051] In step (1), the communication interface module includes multiple wired communication interfaces, multiple wireless communication interfaces, and multiple peripheral modules; the wired communication interface is an Ethernet interface, an RS-485 interface, an RS-232 interface, or a CAN interface; the wireless communication interface is a Wi-Fi interface or a Bluetooth interface; and the peripheral module is a power management interface or a USB debugging port. The Ethernet interface may be an RJ45 interface.

[0052] In step (2), the multimodal protocol dynamic loading module is provided with a protocol feature identification unit and a plug-in management unit; the semantic data mapping engine is provided with a mapping algorithm module; the edge collaborative computing module is provided with a collaborative communication interface and a local processing engine; and the security enhancement module is provided with a plug-in signature verification unit and an access control unit. The above software layer is the core of the system. The multimodal protocol dynamic loading module dynamically manages through the protocol feature identification unit to achieve heterogeneous protocol parsing; the semantic data mapping engine relies on the ontology model library and mapping algorithm to complete the unified data semantic conversion; the edge collaborative computing module optimizes data with the help of the local processing engine and realizes multi-gateway collaboration through the collaborative communication interface; the security enhancement module comprehensively ensures system security from plug-in verification, data encryption to access control, and each module collaboratively realizes key functions such as protocol conversion, semantic mapping and security processing. The software layer controls the start and stop of the hardware interface (such as turning on the RS-485 port to listen for device access), configures communication parameters (such as baud rate, data bits), and calls the security encryption chip interface to realize data encryption / decryption through the driver.

[0053] The device access and protocol feature identification in step (3) includes the following steps: (3.1) Hardware connection and data monitoring: The device connects to the gateway through the communication interface module of the hardware layer, initializes the hardware layer and monitors the data port; (3.2) Protocol feature recognition: The protocol feature recognition unit in the multimodal protocol dynamic loading module of the software layer extracts data frame features; (3.3) Protocol type determination: Determine whether the protocol type used by the device matches the protocol signature library through the preset protocol signature library: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered.

[0054] Extracting data frame features in step (3.2) includes parsing the handshake packet, identifying the port number, and matching the data frame format. The handshake packet can be a Modbus RTU slave address, a Modbus RTU function code, or an MQTT CONNECT message. The port number can be the Modbus TCP default port 502 or the MQTT default port 1883. The data frame format can be the CAN protocol's 29-bit identifier or the Modbus CRC checksum. The data frame features can be the Modbus function code 0x03 or the MQTT fixed header 0x10.

[0055] In step (3.3), the protocol signature library is the read holding register of Modbus function code 0x03 or the NPDU message header of BACnet; the protocol type is Modbus RTU protocol or MQTT protocol.

[0056] In step (4), the local plug-in library is queried through the plug-in management unit in the multimodal protocol dynamic loading module to determine whether there is a matching protocol plug-in in the local plug-in library: If a matching protocol plug-in exists in the local plug-in library, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in in the local plug-in library, proceed to step (5).

[0057] In step (4), if the local plug-in library does not contain a matching protocol plug-in, the plug-in request and transmission in step (5) is performed. That is, a plug-in acquisition request is initiated to the cloud server or adjacent gateway through the collaborative communication interface of the edge collaborative computing module to ensure that the protocol parsing capability can still be supplemented through the collaborative mechanism when there is no local plug-in. The cloud server can be the Docker Hub industrial protocol plug-in library. The gateway can be a gateway that has already loaded the target plug-in.

[0058] In step (5), requesting a plug-in from a cloud server or an adjacent gateway through the collaborative communication interface of the edge collaborative computing module includes the following steps: (5-1) Cloud scenario: Download from the preset plug-in repository; (5-2) Edge Collaboration Scenario: Request the plugin file from the gateway that has loaded the plugin via the DHT network. The plugin repository can be the Docker Hub Industrial Protocol Plugin Library. The plugin file can be a .so / .dll file or a Docker image file. The request format can be: {protocol:"Modbus RTU",version:"1.0"}.

[0059] Step (6) The plug-in signature verification unit of the security enhancement module performs the following steps: (6.1) extracting the digital signature file of the plug-in and verifying the signature hash value using the CA public key to ensure that the plug-in has not been tampered with; (6.2) Check if the plugin metadata matches the current device: If the plugin metadata matches the current device, it is loaded into memory and proceeds to step (7); If the plugin metadata does not match the current device, reject and log it.

[0060] Step (7) Data parsing and semantic conversion includes: (7.1) Syntax-level data parsing: calling the parsing function of the loaded protocol plug-in to convert the original binary data into an intermediate format; (7.2) Semantic ontology mapping: The mapping algorithm module of the semantic data mapping engine performs bidirectional conversion based on the semantic ontology model library.

[0061] In the above step (7), the loaded protocol plug-in is called to parse the original data into an intermediate format (such as JSON). The semantic data mapping engine maps the intermediate format into a unified semantic entity (such as {"entity":"TemperatureData","value":25.6,"unit":"℃"}) based on the semantic ontology model library and encapsulates it according to the target protocol (such as OPC UA).

[0062] The parsing function of the loaded protocol plug-in can be parse(data) of the Modbus plug-in; the intermediate format can be a JSON object, for example: { "protocol":"Modbus RTU", "device_id":"01", "register_address":"0x0100", "raw_value":256 } In step (7.1), protocol plugin construction involves developing each protocol parser plugin using C++ / Python, encapsulating the protocol parsing function, and digitally signing it. The plugin and signature file are stored in a local plugin repository or on a cloud server. These protocol parsing plugins include Modbus RTU, MQTT, or BACnet. The protocol parsing function can use parse_modbus(data). The digital signature is generated by calling the secure encryption chip API to generate an RSA signature.

[0063] In step (7.2), import the semantic ontology model library: Build an industrial domain ontology model based on the OWL language, define entity classes, attributes, and relationships, and import the semantic ontology model library into the gateway storage module via USB or a network. The industrial domain ontology model can be a temperature data ontology or a pressure data ontology. The entity class can be a device class or a data class. The attributes can be values, units, or precision. The relationships can be belongs to or contains. The semantic ontology model library is a .owl file.

[0064] In step (7.2), the bidirectional conversion of semantic ontology mapping includes: (7.2.1) Source protocol to ontology model: Identify corresponding ontology entities, apply transformation rules, extract semantic metadata, and generate ontology instances; (7.2.2) Ontology model to target protocol: Convert the ontology instance into the target data structure according to the format requirements of the target protocol.

[0065] The target protocol may be MQTT or OPC UA. For example, the target data structure may have a payload of 25.6 bytes for MQTT and a JSON metadata description unit.

[0066] The source protocol in the above step (7.2.1) is converted to the ontology model: identify the ontology entity "TemperatureData" corresponding to raw_value (through the mapping rules between register addresses and ontology models), apply the conversion rules (such as value = raw_value / 10), extract the semantic metadata (unit "℃", precision 0.1, function "device temperature monitoring"), and generate the ontology instance: { "entity":"TemperatureData", "value":25.6, "unit":"℃", "precision":0.1, "description":"Device temperature monitoring" } Step (8) Edge data processing and collaboration includes: (8.1) Network scenario judgment: Use static configuration judgment and dynamic automatic identification methods to determine whether the gateway is a multi-gateway network scenario: If the gateway is not a multi-gateway networking scenario, it is determined to be a single gateway and proceed to step (8.2); If the gateway is a multi-gateway networking scenario, it is determined to be a multi-gateway networking and step (8.3) is performed; (8.2) Localized preprocessing: Data filtering, aggregation calculation, and protocol preprocessing are performed by the local processing engine of the edge collaborative computing module, and step (9) is performed. (8.3) Multi-gateway protocol sharing: Implement multi-gateway protocol plug-in sharing and data synchronization through the collaborative communication interface of the edge collaborative computing module, and proceed to step (9).

[0067] In the above step (8.2), the edge collaborative computing module performs filtering (such as discarding outliers), aggregation (such as calculating the 5-minute average value), and protocol preprocessing (such as splitting into small packets suitable for MQTT transmission) on the semantic data to reduce data redundancy.

[0068] In the above step (8.3), protocol plug-ins not stored locally (such as newly acquired BACnet plug-ins) are shared with adjacent gateways through the DHT network or MQTT protocol to synchronize device status data (such as device online / offline status), thus achieving distributed sharing of gateway plug-ins and data within the region.

[0069] The static configuration determination and dynamic automatic identification methods in step (8.1) include: (8.1.1) Static configuration determination method: Read the configuration file during the initialization phase. If the configuration file displays network_mode: "cluster", it is determined to be a multi-gateway network and skip step (8.1.2). If the configuration file displays network_mode: "local", it is determined to be a single gateway network. (8.1.2) Dynamic automatic identification method: If static parameters are not configured, the gateway will be started and executed through the edge collaborative computing module: -Send a response message to the edge collaborative computing module to try to discover adjacent gateways; - If a response is received from another gateway within 30 seconds, it is determined to be a multi-gateway network, and the plug-in sharing and data synchronization process will be activated; -If there is no response after the timeout, it is determined to be a single gateway and only the localization preprocessing of step (8.2) is performed.

[0070] The above configuration file can be a config.json file.

[0071] In step (8.2), data filtering involves threshold detection. If semantic data exceeds or falls below the threshold, the data is marked as an outlier and discarded. Aggregation calculation involves downsampling high-frequency data or calculating cumulative values. Protocol preprocessing involves splitting long data frames into shorter frames supported by the target protocol. For example, this involves converting long BACnet messages into multi-packet Modbus transmissions.

[0072] In step (8.3), plug-in sharing is to broadcast the newly loaded protocol plug-in metadata to all gateways in the subnet, and other gateways update the local plug-in index; the data synchronization is to send the processed key data to adjacent gateways through the collaborative communication interface to support distributed decision-making.

[0073] Step (9) includes the following steps: (9.1) Device identity authentication: The device identity is verified by the access control unit in the security enhancement module; (9.2) Data encryption processing: transmission encryption and storage encryption; (9.3) Target data forwarding; (9.4) Protocol encapsulation and transmission.

[0074] In the above step (9), the security enhancement module performs SM4 encryption on the processed data (calling the encryption interface of the security encryption chip) and sends it to the cloud server or target device through the TLS / SSL channel, while recording the data transmission log (time, source address, target address, data type).

[0075] In step (9.1), when verifying the device's identity through the access control unit in the security enhancement module, it is necessary to check whether the device's MAC address is on the whitelist. SSL two-way authentication is also performed for devices that support digital certificates. If authentication fails, the connection is terminated. The device connects to the gateway via an interface such as RS-485 or Ethernet. The security enhancement module verifies the device's MAC address and digital certificate (e.g., SSL two-way authentication) and matches it to the device whitelist. If the authentication passes, the data channel is opened. This SSL authentication refers to the device sending a certificate or the gateway using the CA public key for verification.

[0076] In step (9.2), transmission encryption involves selecting an encryption method based on the target protocol, using either the SM4 algorithm or the AES-256 algorithm to encrypt the data payload and generate ciphertext. Storage encryption involves performing AES-256 encryption on sensitive files such as semantic models and plugin configurations when data needs to be temporarily stored in the gateway storage module. The key is generated and managed by the secure encryption chip. These encryption methods can utilize MQTT over TLS or Modbus TCP with SSL.

[0077] The target data forwarding in step (9.3) is forwarded by selecting the following different communication interfaces according to the configuration rules: Device-side forwarding: sending control instructions to other devices via RS-485 interface or CAN interface; Cloud forwarding: Send data to the cloud server via Ethernet interface or 4G interface; Local system forwarding: transmits data to the local system through the LAN interface.

[0078] The above configuration rules can use a user-preset "Modbus device → MQTT cloud" mapping. The above control instructions can be parsed Modbus write instructions. The above cloud server can be Alibaba Cloud IoT or Siemens MindSphere. The above local system can be a local SCADA system.

[0079] The protocol encapsulation and transmission in step (9.4) encapsulates the processed semantic data into the target protocol format and sends it through the communication layer interface to complete cross-platform communication. The target protocol format can be an MQTT message or an OPC UA service request.

[0080] This embodiment also includes step (10) system monitoring and maintenance: (10.1) Real-time monitoring: View the operating status of each module in real time through the gateway management interface and receive abnormal alarms; (10.2) Remote Upgrade: The cloud server pushes the protocol plug-in update package or ontology model patch. After the gateway downloads it through a secure channel, it triggers the plug-in hot update mechanism to ensure continuous optimization of system compatibility and security.

[0081] The gateway management interface can be a web UI. The operating status of each module can include CPU utilization, memory usage, or plugin loading. The exception can include plugin authentication failure or data encryption errors. The plugin hot update mechanism loads the new plugin first, then uninstalls the old one.

[0082] In addition, it should be noted that the names of the various parts of the specific embodiments described in this specification may be different. Any equivalent or simple changes made based on the structure, features, and principles described in the patent concept of the present invention are included in the scope of protection of the patent of this invention. Those skilled in the art of the technical field to which the present invention relates may make various modifications, supplements, or replace the specific embodiments described in the description with similar methods. As long as they do not deviate from the structure of the present invention or exceed the scope defined by the claims, they shall fall within the scope of protection of the present invention.

Claims

1. A gateway-based cross-platform device communication protocol conversion method, characterized in that The steps include: (1) Hardware layer construction: The hardware layer includes processing unit, storage module, communication interface module and security unit; (2) Software layer configuration: The software layer includes a multimodal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module, and a security enhancement module; (3) Device access and protocol feature identification: After the device is connected, the device's protocol type is identified through the multimodal protocol dynamic loading module, and the protocol feature library is matched: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered; (4) Dynamic protocol plug-in loading: Dynamically load the module through the multimodal protocol to query the matching protocol plug-in: If a matching protocol plug-in exists, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in, proceed to step (5); (5) Plug-in request and transmission: Request plug-ins from the cloud server or adjacent gateway through the edge collaborative computing module; (6) Plug-in security authentication: The plug-in is authenticated by the security enhancement module. After passing the authentication, it is loaded into the memory and proceeds to step (7); (7) Data parsing and semantic conversion: calling plug-ins to parse data and complete data conversion through the semantic data mapping engine; (8) Edge data processing and collaboration: Based on the networking scenario, local data processing or multi-gateway protocol collaboration is performed through the edge collaborative computing module; (9) After security verification and data encryption by the security enhancement module, data forwarding and cross-domain communication are completed.

2. The gateway-based cross-platform device communication protocol conversion method according to claim 1, characterized in that: In the step (2), the multimodal protocol dynamic loading module is provided with a protocol feature recognition unit and a plug-in management unit; the semantic data mapping engine is provided with a mapping algorithm module; the edge collaborative computing module is provided with a collaborative communication interface and a local processing engine; and the security enhancement module is provided with a plug-in signature verification unit and an access control unit.

3. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: The device access and protocol feature identification in step (3) includes the following steps: (3.1) Hardware connection and data monitoring: The device connects to the gateway through the communication interface module of the hardware layer, initializes the hardware layer and monitors the data port; (3.2) Protocol feature recognition: The protocol feature recognition unit in the multimodal protocol dynamic loading module of the software layer extracts data frame features; (3.3) Protocol type determination: Determine whether the protocol type used by the device matches the protocol signature library through the preset protocol signature library: If the protocol type matches the protocol signature library, proceed to step (4); If the protocol type does not match the protocol signature library, it is marked as an unknown protocol and step (5) is triggered; Extracting data frame features in step (3.2) includes parsing handshake packets, identifying port numbers, and matching data frame formats; In the step (3.3), the protocol feature library is the read holding register of the Modbus function code 0x03 or the NPDU message header of BACnet; and the protocol type is the Modbus RTU protocol or the MQTT protocol.

4. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: In step (4), the local plug-in library is queried through the plug-in management unit in the multimodal protocol dynamic loading module to determine whether there is a matching protocol plug-in in the local plug-in library: If a matching protocol plug-in exists in the local plug-in library, the matching protocol plug-in is directly loaded into the memory and step (7) is performed; If there is no matching protocol plug-in in the local plug-in library, proceed to step (5).

5. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: In step (5), requesting a plug-in from a cloud server or an adjacent gateway through the collaborative communication interface of the edge collaborative computing module includes the following steps: (5-1) Cloud scenario: Download from the preset plug-in repository; (5-2) Edge collaboration scenario: Request the plug-in file from the gateway that has loaded the plug-in through the DHT network.

6. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: The step (6) is performed by the plug-in signature verification unit of the security enhancement module to perform the following steps: (6.1) Extract the digital signature file of the plug-in and verify the signature hash value using the CA public key to ensure that the plug-in has not been tampered with; (6.2) Check if the plugin metadata matches the current device: If the plugin metadata matches the current device, it is loaded into memory and proceeds to step (7); If the plugin metadata does not match the current device, reject and log it.

7. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: The data analysis and semantic conversion in step (7) includes: (7.1) Syntax-level data parsing: calling the parsing function of the loaded protocol plug-in to convert the original binary data into an intermediate format; (7.2) Semantic ontology mapping: The mapping algorithm module of the semantic data mapping engine performs bidirectional conversion based on the semantic ontology model library; In the step (7.1), the construction of the protocol plug-in: using C++ / Python to develop each protocol parsing plug-in, encapsulating the protocol parsing function, and digitally signing it, and storing the plug-in and signature file in the local plug-in library or cloud server; In the step (7.2), the semantic ontology model library is imported: an industrial domain ontology model is constructed based on the OWL language, entity classes, attributes and relationships are defined, and the semantic ontology model library is imported into the gateway storage module via USB or network; In step (7.2), the bidirectional conversion of semantic ontology mapping includes: (7.2.1) Source protocol to ontology model: Identify corresponding ontology entities, apply transformation rules, extract semantic metadata, and generate ontology instances; (7.2.2) Ontology model to target protocol: Convert the ontology instance into the target data structure according to the format requirements of the target protocol.

8. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: The step (8) of edge data processing and collaboration includes: (8.1) Network scenario judgment: Use static configuration judgment and dynamic automatic identification methods to determine whether the gateway is a multi-gateway network scenario: If the gateway is not a multi-gateway networking scenario, it is determined to be a single gateway and proceed to step (8.2); If the gateway is a multi-gateway networking scenario, it is determined to be a multi-gateway networking and step (8.3) is performed; (8.2) Localized preprocessing: Data filtering, aggregation calculation, and protocol preprocessing are performed by the local processing engine of the edge collaborative computing module, and step (9) is performed. (8.3) Multi-gateway protocol sharing: Implement multi-gateway protocol plug-in sharing and data synchronization through the collaborative communication interface of the edge collaborative computing module, and proceed to step (9).

9. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: The step (9) comprises the following steps: (9.1) Device identity authentication: The device identity is verified by the access control unit in the security enhancement module; (9.2) Data encryption processing: transmission encryption and storage encryption; (9.3) Target data forwarding; (9.4) Protocol encapsulation and transmission; In step (9.1), when verifying the device identity through the access control unit in the security enhancement module, it is necessary to check whether the device MAC address is in the whitelist; and perform SSL two-way authentication on devices that support digital certificates. If the authentication fails, the connection is disconnected; In the step (9.2), the transmission encryption is to select an encryption method according to the target protocol, and use the national secret SM4 algorithm or AES-256 algorithm to encrypt the data payload to generate ciphertext; the storage encryption is to encrypt the semantic model, plug-in configuration and other sensitive files with AES-256 when the data needs to be temporarily stored in the gateway storage module, and the key is generated and managed by the security encryption chip; The target data forwarding in step (9.3) is forwarded by selecting the following different communication interfaces according to the configuration rules: Device-side forwarding: sending control instructions to other devices via RS-485 interface or CAN interface; Cloud forwarding: Send data to the cloud server via Ethernet interface or 4G interface; Local system forwarding: transfer data to the local system via the LAN interface; The protocol encapsulation and sending in the step (9.4) is to encapsulate the processed semantic data into the target protocol format and send it through the communication layer interface to complete cross-platform communication.

10. The gateway-based cross-platform device communication protocol conversion method according to claim 2, characterized in that: It also includes step (10) system monitoring and maintenance: (10.1) Real-time monitoring: View the operating status of each module in real time through the gateway management interface and receive abnormal alarms; (10.2) Remote Upgrade: The cloud server pushes the protocol plug-in update package or ontology model patch. After the gateway downloads it through a secure channel, it triggers the plug-in hot update mechanism to ensure continuous optimization of system compatibility and security.

Images