A gateway-based cross-platform device communication protocol conversion method

Abstract

The application discloses a gateway-based cross-platform device communication protocol conversion method, comprising the following steps: (1) the 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) device access and protocol feature recognition; (4) dynamic protocol plug-in loading; (5) plug-in request and transmission; (6) plug-in security authentication; (7) data analysis and semantic conversion; (8) according to the networking scene, local data processing or multi-gateway protocol collaboration is carried out through the edge collaborative computing module; (9) after security verification and encryption by the security enhancement module, data forwarding and cross-domain communication are completed. The application can break through the static limitation of protocol adaptation, improve the heterogeneous data semantic interoperability precision, enhance the edge computing and collaborative ability, and build a multi-layer security protection system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial internet and internet of things fusion, and particularly relates to a gateway-based cross-platform device communication protocol conversion method. BACKGROUND

[0002] In the industrial internet and internet of things fusion scene, devices usually use heterogeneous communication protocols such as Modbus, OPC UA, MQTT, BACnet, CAN, Modbus TCP, etc., which leads to great challenges in the interconnection and intercommunication of cross-platform devices. The traditional protocol conversion gateway, as the core component connecting heterogeneous devices and upper-layer systems, has the following significant defects in its technical solution:

[0003] (1) Protocol adaptation capability is fixed and dynamic expansion is insufficient

[0004] Existing gateways generally use a static protocol library architecture, only supporting pre-integrated fixed protocols, and when a new protocol is added, the gateway needs to be upgraded offline or restarted, which cannot dynamically load protocol plug-ins at runtime. The essential defect is that the protocol parsing module is strongly coupled with the gateway core logic, and protocol parsing is realized by hard coding, which cannot meet the flexible adaptation requirements in the mixed access scene of multiple protocols.

[0005] (2) Heterogeneous data semantic analysis is missing, and conversion accuracy is insufficient

[0006] Traditional gateways only implement syntax conversion of data formats (such as converting Modbus register addresses to JSON fields), lack understanding of data semantics, and lead to the following problems: First, semantic ambiguity and data distortion, different protocols have different definitions for the same physical quantity (for example: temperature data in the Modbus protocol may be stored in integer form, with a unit of 0.1℃, while the OPC UA protocol directly represents ℃ in float type), when the traditional gateway converts through a fixed mapping table, it is easy to ignore semantic information such as units and precision, leading to data errors. For example: the Modbus register value 256 is directly mapped to 256℃ in OPC UA, which should actually be 25.6℃, with a high error rate; second, weak processing capability for complex data structures, for structured data containing context relationships (such as device state parameter sets), traditional solutions rely on hard-coded rules to map each field, and cannot identify the semantic association between data (such as the correlation between voltage and current), making it difficult to meet the requirements of data integrity and accuracy in industrial scenarios.

[0007] (3) Lack of edge computing capability, insufficient real-time and collaboration

[0008] Traditional gateways lack local data processing capability and need to upload all raw data to the cloud for protocol conversion and business logic processing, resulting in:

[0009] High transmission delay: Industrial control scenarios require data processing delay < 50ms, while traditional solutions require data to be transmitted back and forth between the gateway, the cloud and the application system, with a delay of more than 200ms, which cannot meet the real-time control requirements (such as robot motion control, production line linkage);

[0010] 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 malfunction;

[0011] Poor collaboration: Multiple gateways cannot share protocol resources or device state information, and the same protocol plug-in is loaded repeatedly, wasting computing resources (such as multiple gateways in the same factory each loading a Modbus plug-in, resulting in redundant memory usage).

[0012] (4) Weak security mechanism, risk of protocol layer attack

[0013] Existing gateways lack effective security measures during protocol analysis and data transmission:

[0014] (4-1) Lack of protocol plug-in security: Third-party protocol plug-ins may be maliciously tampered with (such as inserting virus code), but traditional gateways do not perform signature authentication on the plug-ins, allowing malicious code to enter the system with the plug-ins, causing device control abnormalities or data leaks;

[0015] (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, making them vulnerable to interception and tampering; Protocol configuration files and mapping rules stored are also not encrypted, posing a risk of sensitive information leakage;

[0016] (4-3) Lack of access control: There is no identity authentication (such as MAC address white list, digital certificate verification) for access devices, and illegal devices can launch attacks by forging protocol data, causing resource exhaustion or incorrect conversion of the gateway. SUMMARY

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

[0018] To solve the above technical problems, the technical solution adopted by the present application is as follows:

[0019] A gateway-based cross-platform device communication protocol conversion method, characterized by the following steps:

[0020] (1) Hardware layer construction: The hardware layer includes a processing unit, a storage module, a communication interface module, and a security unit;

[0021] (2) Software layer configuration: The software layer includes a multi-modal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module, and a security enhancement module;

[0022] (3) Device access and protocol feature recognition: After device access, the multi-modal protocol dynamic loading module identifies the protocol type of the device and matches the protocol feature library:

[0023] If the protocol type matches the protocol feature library, proceed to step (4);

[0024] If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered;

[0025] (4) Dynamic protocol plug-in loading: The multi-modal protocol dynamic loading module queries the matching protocol plug-in:

[0026] If there is a matching protocol plug-in, the matching protocol plug-in is directly loaded into the memory and step (7) is performed;

[0027] If there is no matching protocol plug-in, proceed to step (5);

[0028] (5) Plug-in request and transmission: The edge collaborative computing module requests a plug-in from a cloud server or a neighboring gateway;

[0029] (6) Plug-in security authentication: The security enhancement module performs security authentication on the plug-in, and after authentication, loads it into the memory and proceeds to step (7);

[0030] (7) Data analysis and semantic conversion: Call the plug-in to analyze the data and complete the data conversion through the semantic data mapping engine;

[0031] (8) Edge data processing and collaboration: According to the networking scenario, the edge collaborative computing module performs local data processing or multi-gateway protocol collaboration;

[0032] (9) After security verification and data encryption by the security enhancement module, complete data forwarding and cross-domain communication.

[0033] The hardware layer of step (1) is the physical root of the system, which is dominated by a high-performance low-power processing unit (such as a central processing unit (CPU), an ARM Cortex-A series or an X86 architecture processor) for operation control, and is matched with a large-capacity storage module (such as 1 GB and above DDR4) to support dynamic loading and temporary storage, supplemented by a flash memory or a solid state disk (8 GB-128 GB) to store key system data, and through an integrated communication interface module to realize device connection, and with the help of a security unit to ensure data security, a physical support is built for software operation and data processing. The above-mentioned storage module includes a memory and a storage device. The above-mentioned security unit includes a secure encryption chip; the secure encryption chip is a national encryption SM4 chip or an AES chip. The central processing unit (CPU) provides operation resources for the software module (such as a semantic mapping algorithm), the memory (RAM) provides temporary storage space for the plug-in and data processing, and the storage device (ROM) persistently stores the protocol plug-in, the semantic ontology model and the system configuration; the communication interface module is a physical connection channel of the software layer and the external device / system, and the secure encryption chip provides hardware-level encryption acceleration (such as SM4 algorithm hardware implementation) for the security module of the software layer.

[0034] The application creates an architecture of deep integration of hardware security support and software intelligent processing: the hardware layer integrates a secure encryption chip and a high-performance processing unit, etc., to cooperatively guarantee data security and processing efficiency; the software layer relies on a multi-modal protocol dynamic loading module to realize flexible analysis and management of heterogeneous protocols, relies on a semantic data mapping engine to complete semantic unification and conversion of heterogeneous data based on an ontology model, realizes local rapid processing and multi-gateway distributed collaboration through an edge collaborative computing module, and a security enhancement module runs through the whole process to ensure system security, so that efficient, safe and flexible cross-platform device communication protocol conversion is realized, and the problem of multi-protocol device interconnection and data interaction in industrial scenes is effectively solved, providing an innovative solution for industrial internet application.

[0035] In the preferred scheme, in step (1), the communication interface module includes a plurality of wired communication interfaces, a plurality of wireless communication interfaces and a plurality of 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 above-mentioned Ethernet interface can be an RJ45 interface.

[0036] In the preferred embodiment, in step (2), the multimodal protocol dynamic loading module is equipped with a protocol feature recognition unit and a plug-in management unit; the semantic data mapping engine is equipped with a mapping algorithm module; the edge collaborative computing module is equipped with a collaborative communication interface and a local processing engine; and the security enhancement module is equipped 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 recognition unit to realize heterogeneous protocol parsing; the semantic data mapping engine relies on the ontology model library and mapping algorithm to complete the unified semantic conversion of data; 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 provides comprehensive system security from plug-in verification and data encryption to access control. Each module works together to realize 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 enabling the RS-485 port to listen for device access), configures communication parameters (such as baud rate and data bits), and calls the security encryption chip interface to realize data encryption / decryption through the driver program.

[0037] In a further preferred embodiment, step (3) of device access and protocol feature identification includes the following steps:

[0038] (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;

[0039] (3.2) Protocol feature identification: The protocol feature identification unit in the multimodal protocol dynamic loading module of the software layer extracts data frame features;

[0040] (3.3) Protocol Type Determination: Based on a preset protocol feature library, determine whether the protocol type used by the device matches the protocol feature library:

[0041] If the protocol type matches the protocol feature library, proceed to step (4).

[0042] If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered.

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

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

[0045] In a further preferred embodiment, the step (4) queries the local plugin library through the plugin management unit in the multi-modal protocol dynamic loading module to determine whether the local plugin library has a matching protocol plugin:

[0046] If the local plugin library has a matching protocol plugin, the matching protocol plugin is directly loaded into the memory and step (7) is performed.

[0047] If the local plugin library does not have a matching protocol plugin, step (5) is performed.

[0048] In the above step (4), if the local plugin library does not have a matching protocol plugin, step (5) of plugin request and transmission is performed, that is, a plugin acquisition request is initiated to the cloud server or adjacent gateway through the collaborative communication interface of the edge collaborative computing module, ensuring that the protocol analysis capability can still be supplemented through the collaborative mechanism when there is no local plugin. The above cloud server can be a Docker Hub industrial protocol plugin library. The above gateway can be a gateway that has loaded the target plugin.

[0049] In a further preferred embodiment, the step (5) of requesting a plugin from the cloud server or adjacent gateway through the collaborative communication interface of the edge collaborative computing module includes the following steps:

[0050] (5-1) Cloud scenario: download from a preset plugin warehouse;

[0051] (5-2) Edge collaborative scenario: request a plugin file from a gateway that has loaded the plugin through a DHT network. The above plugin warehouse can be a Docker Hub industrial protocol plugin library. The above plugin file can be a.so / .dll file or a Docker image file, and its request format can be set as: {protocol: "Modbus RTU", version: "1.0"}.

[0052] In a further preferred embodiment, the step (6) performs the following steps through the plugin signature verification unit of the security enhancement module: (6.1) extract the digital signature file of the plugin, verify the signature hash value using the CA public key, and ensure that the plugin has not been tampered with;

[0053] (6.2) Check if the plugin metadata matches the current device:

[0054] If the plugin metadata matches the current device, load into memory and proceed to step (7);

[0055] If the plugin metadata does not match the current device, reject and record logs.

[0056] In further preferred embodiments, the step (7) data parsing and semantic conversion comprises:

[0057] (7.1) Syntax-level data parsing: call the parsing function of the loaded protocol plugin to convert the original binary data into an intermediate format;

[0058] (7.2) Semantic ontology mapping: bidirectional conversion according to the semantic ontology model library through the mapping algorithm module of the semantic data mapping engine.

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

[0060] The above call to the parsing function of the loaded protocol plugin can be Modbus plugin's parse(data); the intermediate format can be a JSON object, for example:

[0061] {

[0062] "protocol":"Modbus RTU",

[0063] "device_id":"01",

[0064] "register_address":"0x0100",

[0065] "raw_value":256

[0066] }

[0067] In further preferred embodiments, in step (7.1), the protocol plugin is constructed: develop each protocol parsing plugin using C++ / Python, encapsulate the protocol parsing function, and perform digital signature, store the plugin and signature file to the local plugin library or cloud server. The above protocol parsing plugin includes Modbus RTU plugin, MQTT plugin or BACnet plugin. The above protocol parsing function can use parse_modbus(data). The above digital signature is generated by calling the security encryption chip API to generate RSA signature.

[0068] In a further preferred embodiment, step (7.2) involves importing the semantic ontology model library: An industrial domain ontology model is constructed based on the OWL language, defining entity classes, attributes, and relationships. The semantic ontology model library is then imported into the gateway storage module via USB or network. The aforementioned industrial domain ontology model can be a temperature data ontology or a pressure data ontology. Entity classes can be equipment classes or data classes. The aforementioned attributes can be values, units, or precision. The aforementioned relationships can be membership or inclusion relationships. The aforementioned semantic ontology model library is a .owl file.

[0069] In a further preferred embodiment, step (7.2), the bidirectional transformation of the semantic ontology mapping includes:

[0070] (7.2.1) Source Protocol to Ontology Model: Identify the corresponding ontology entity, apply transformation rules, extract semantic metadata, and generate an ontology instance;

[0071] (7.2.2) Ontology model to target protocol: Convert ontology instances into target data structures according to the format requirements of the target protocol.

[0072] The target protocol mentioned above can be either MQTT or OPC UA. The target data structure, for example, has a payload of 25.6 for MQTT, accompanied by JSON metadata indicating the unit.

[0073] The source protocol to ontology model step (7.2.1) above involves: identifying the ontology entity "TemperatureData" corresponding to raw_value (through the mapping rules between register addresses and ontology models), applying transformation rules (e.g., value = raw_value / 10), extracting semantic metadata (unit "℃", precision 0.1, function "device temperature monitoring"), and generating an ontology instance.

[0074] {

[0075] "entity":"TemperatureData",

[0076] "value":25.6,

[0077] "unit":"℃",

[0078] "precision":0.1,

[0079] "description": "Equipment temperature monitoring"

[0080] }

[0081] In a further preferred embodiment, step (8) edge data processing and collaboration includes:

[0082] (8.1) Network scene judgment: Determine whether the gateway is a multi-gateway network scene through static configuration judgment and dynamic automatic identification method:

[0083] If the gateway is not a multi-gateway network scene, it is determined to be a single gateway and step (8.2) is performed;

[0084] If the gateway is a multi-gateway network scene, it is determined to be a multi-gateway network and step (8.3) is performed;

[0085] (8.2) Localized preprocessing: Perform data filtering, aggregation calculation and protocol preprocessing through the local processing engine of the edge collaborative computing module, and proceed to step (9);

[0086] (8.3) Multi-gateway protocol sharing: Through the collaborative communication interface of the edge collaborative computing module, the protocol plug-in sharing and data synchronization of multi-gateway are realized, and step (9) is performed.

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

[0088] In the above step (8.3), through DHT network or MQTT protocol, the local non-stored protocol plug-in (such as newly acquired BACnet plug-in) is shared to the adjacent gateway, and the device state data (such as device online / offline state) is synchronized, realizing the distributed sharing of gateway plug-in and data in the region.

[0089] In a further preferred embodiment, the static configuration judgment and dynamic automatic identification method in step (8.1) includes:

[0090] (8.1.1) Static configuration judgment method: Read the configuration file in the initialization stage, if the configuration file shows network_mode: "cluster", it is determined to be a multi-gateway network, and step (8.1.2) is skipped; if the configuration file shows network_mode: "local", it is determined to be a single gateway;

[0091] (8.1.2) Dynamic automatic identification method: If no static parameters are configured, the gateway sends a response message to the edge collaborative computing module after startup to try to discover adjacent gateways;

[0092] - Send a response message to the edge collaborative computing module to try to discover adjacent gateways;

[0093] - If a response from another gateway is received within 30 seconds, it is determined to be a multi-gateway network, and the plug-in sharing and data synchronization process is activated;

[0094] If there is no response after the timeout, it is determined that it is a single gateway, and only the localization preprocessing of step (8.2) is performed.

[0095] The configuration file can be a config.json file.

[0096] In a further preferred solution, in step (8.2), data filtering: threshold detection is used to determine whether the semantic data is greater than or less than the threshold value, and if so, the semantic data is marked as an abnormal value and discarded; aggregate calculation: high-frequency data is down-sampled or cumulative values are calculated; protocol preprocessing: long data frames are split into short frames supported by the target protocol. For example, long messages of BACnet are converted into multi-packet transmission of Modbus.

[0097] In a further preferred solution, 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 cooperative communication interface, supporting distributed decision-making.

[0098] In a further preferred solution, step (9) includes the following steps:

[0099] (9.1) Device identity authentication: verifying the device identity through the access control unit in the security enhancement module;

[0100] (9.2) Data encryption processing: transmission encryption and storage encryption;

[0101] (9.3) Target data forwarding;

[0102] (9.4) Protocol encapsulation and sending.

[0103] In step (9) above, the security enhancement module performs SM4 encryption on the processed data (calling the security encryption chip encryption interface), 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).

[0104] In a further preferred solution, 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 SSL two-way authentication is performed on devices supporting digital certificates, and the connection is disconnected if the authentication fails. The device is connected to the gateway through the RS-485 / Ethernet interface, and the security enhancement module verifies the device MAC address / digital certificate (such as SSL two-way authentication), matches the device whitelist, and opens the data channel after passing. The above SSL authentication refers to the device sending a certificate or the gateway verifying with a CA public key.

[0105] In a further preferred solution, in the step (9.2), the transmission encryption is to select an encryption mode according to a target protocol, encrypt the data Payload using the SM4 algorithm or the AES-256 algorithm to generate ciphertext; and the storage encryption is to perform AES-256 encryption on sensitive files such as semantic models and plug-in configurations when the data needs to be temporarily stored in the gateway storage module, and the key is generated and managed by a secure encryption chip. The above encryption mode can use MQTT over TLS or Modbus TCP with SSL.

[0106] In a further preferred solution, in the step (9.3), the target data forwarding is performed according to a configuration rule by selecting different communication interfaces, including:

[0107] Device-side forwarding: sending control instructions to other devices through an RS-485 interface or a CAN interface;

[0108] Cloud forwarding: sending data to a cloud server through an Ethernet interface or a 4G interface;

[0109] Local system forwarding: transmitting data to a local system through a local area network interface.

[0110] The above configuration rule can use a user-preset "Modbus device -> MQTT cloud" mapping. The above control instruction can be a parsed Modbus write instruction. The above cloud server can be an Ali Cloud IoT or a Siemens MindSphere. The above local system can be a SCADA local system.

[0111] In a further preferred solution, in the step (9.4), the protocol packaging and sending is to package the processed semantic data into a target protocol format and send it through a communication layer interface to complete cross-platform communication. The above target protocol format can be an MQTT message or an OPC UA service request.

[0112] In a preferred solution, it further includes a step (10) of system monitoring and maintenance:

[0113] (10.1) Real-time monitoring: real-time monitoring of the running state of each module through a gateway management interface and receiving an abnormal alarm;

[0114] (10.2) Remote upgrade: the cloud server pushes a protocol plug-in update package or an ontology model patch, and the gateway downloads it through a secure channel, triggers a plug-in hot update mechanism, and ensures the continuous optimization of system compatibility and security.

[0115] The gateway management interface can be a Web UI. The module running states are, for example, CPU utilization, memory occupation, or plug-in loading. The exception can be plug-in authentication failure or data encryption error. The plug-in hot update mechanism is to load a new plug-in first and then uninstall an old plug-in.

[0116] Compared with the prior art, the present application has the following advantages:

[0117] (1) Breakthrough of protocol adaptation static limitation: through dynamic loading technology, flexible expansion of runtime protocol plug-in is realized, new private protocol access can be supported without offline upgrade or gateway restart, and the problems of traditional gateway protocol library solidification and low adaptation efficiency are solved.

[0118] (2) Improve the precision of heterogeneous data semantic interoperability: build a domain ontology model and an intelligent mapping engine to realize accurate conversion of data at the semantic level of unit, precision, and functional meaning, avoid information distortion and ambiguity caused by syntax level conversion, and meet the requirements of industrial scenarios for data integrity and accuracy;

[0119] (3) Enhance edge computing and collaboration capabilities: through localized data processing and multi-gateway networking mechanism, reduce cloud dependence, reduce data transmission delay (target < 50ms), improve system real-time performance and reliability, and realize distributed sharing of protocol resources and device status, and optimize edge node computing power utilization efficiency;

[0120] (4) Build a multi-layer security protection system: through protocol plug-in signature authentication, data encryption transmission, and device access control mechanisms, resist security threats such as malicious code injection, data tampering, and illegal access, and ensure the security and stability of industrial internet and internet of things device communication.

[0121] (5) The present application integrates "dynamic loading + semantic mapping + edge collaboration + security enhancement" to build a complete technical system for cross-platform protocol conversion. Through the whole process cooperation of "device access → protocol dynamic identification → semantic conversion → edge processing → secure transmission", cross-platform communication of heterogeneous devices is realized. The core principle is: through plug-in architecture, dynamic adaptation of protocols is realized, based on domain ontology model, semantic unification of heterogeneous data is completed, using edge computing capability, localized processing and collaboration are realized, and finally through multi-layer security mechanism, reliable operation of the system is ensured.

[0122] (6) The hardware layer of the present application relies on high-performance CPU, large-capacity storage, rich communication interface and secure encryption chip to provide strong physical support and data security guarantee; the software layer realizes flexible analysis of heterogeneous protocols through multi-modal protocol dynamic loading module, unified data semantics through semantic data mapping engine, improves processing real-time and multi-gateway collaboration ability through edge collaborative computing module, and guarantees the whole process security through security enhancement module; the communication mode supports multi-element communication among devices, cloud, and gateway, and the whole has high-efficiency protocol conversion, accurate semantic mapping, flexible collaboration and high security, effectively solves the cross-platform communication problem of industrial equipment, improves the system compatibility, real-time and reliability, and adapts to the needs of complex industrial scenes.

[0123] (7) The communication of the present application interacts with the equipment in real time through the multi-element communication interface module on the one hand, collects data and issues instructions; on the other hand, it communicates with the cloud server through 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 among multiple gateways, shares plug-ins, models and device states through distributed network or message queue, improves the overall performance and reliability of the system, and ensures efficient transmission and collaboration of data among devices, gateways, and clouds. BRIEF DESCRIPTION OF DRAWINGS

[0124] Figure 1 is the hardware architecture diagram of the embodiment of the present application;

[0125] Figure 2 is the software module architecture diagram of the embodiment of the present application;

[0126] Figure 3 is the data conversion flowchart of the embodiment of the present application;

[0127] Figure 4 is the edge collaborative networking diagram of the embodiment of the present application;

[0128] Figure 5 is the semantic ontology model diagram of the embodiment of the present application.

[0129] Remarks:

[0130] Figure 1 It shows the connection relationship of central processing unit (CPU), memory (RAM), storage device (Flash / SSD), wired / wireless communication interface and secure encryption chip, which provides physical support for the software layer;

[0131] Figure 2 It shows the interaction relationship of multi-modal protocol dynamic loading module, semantic data mapping engine, edge collaborative computing module and security enhancement module, which embodies the software processing logic from protocol analysis to secure transmission;

[0132] Figure 3 The complete process from device access to protocol feature recognition, dynamic plug-in loading, syntax semantic analysis, edge processing, security check and data forwarding is demonstrated, and the processing logic and flow of heterogeneous data in the gateway are embodied.

[0133] Figure 4 The networking architecture of protocol plug-in (such as Modbus plug-in) sharing and device state data synchronization is demonstrated by connecting multiple edge gateways (such as gateways A, B and C) through DHT network or MQTT protocol, and the distributed collaboration characteristics of edge computing are embodied.

[0134] Figure 5 Taking temperature data as an example, the hierarchical structure of "semantic ontology model library → data class → temperature data" and the attributes (value, unit, precision, description) of temperature data are demonstrated, and the supporting role of semantic ontology model for semantic unification of heterogeneous data is embodied. DETAILED DESCRIPTION

[0135] The preferred embodiments of the present application will be further described in conjunction with the accompanying drawings and the preferred embodiments of the present application.

[0136] As shown in the figure, the gateway-based cross-platform device communication protocol conversion method in the embodiment includes the following steps: Figures 1-5

[0137] (1) Hardware layer construction: the hardware layer includes a processing unit, a storage module, a communication interface module and a security unit;

[0138] (2) Software layer configuration: the software layer includes a multi-modal protocol dynamic loading module, a semantic data mapping engine, an edge collaborative computing module and a security enhancement module;

[0139] (3) Device access and protocol feature recognition: after the device is accessed, the protocol type of the device is recognized by the multi-modal protocol dynamic loading module, and the protocol feature library is matched:

[0140] If the protocol type matches the protocol feature library, step (4) is performed;

[0141] If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered;

[0142] (4) Dynamic protocol plug-in loading: the matching protocol plug-in is queried by the multi-modal protocol dynamic loading module:

[0143] If there is a matching protocol plug-in, the matching protocol plug-in is directly loaded into the memory and step (7) is performed;

[0144] If there is no matching protocol plug-in, step (5) is performed;

[0145] ​(5) Plug-in request and transmission: requesting plug-ins from a cloud server or a neighboring gateway through an edge collaborative computing module;

[0146] (6) Plug-in security authentication: performing security authentication on the plug-ins through a security enhancement module, loading the plug-ins into a memory after the authentication passes, and performing step (7);

[0147] (7) Data analysis and semantic conversion: calling the plug-ins to analyze data and completing data conversion through a semantic data mapping engine;

[0148] (8) Edge data processing and collaboration: performing local data processing or multi-gateway protocol collaboration through an edge collaborative computing module according to a networking scenario;

[0149] (9) After security verification and data encryption through a security enhancement module, completing data forwarding and cross-domain communication.

[0150] The hardware layer of step (1) is the physical foundation of the system, which is dominated by a high-performance low-power processing unit (such as a central processing unit (CPU), an ARM Cortex-A series or an X86 architecture processor) for operation control, is supported by a large-capacity storage module (such as 1 GB and above DDR4) for dynamic loading and temporary storage, is supplemented by a flash memory or a solid state disk (8 GB-128 GB) for storing key system data, realizes device connection through an integrated communication interface module, and guarantees data security through a security unit, thereby providing physical support for software operation and data processing. The storage module includes a memory and a storage device. The security unit includes a security encryption chip; the security encryption chip is a national encryption SM4 chip or an AES chip. The central processing unit (CPU) provides operation resources for software modules (such as semantic mapping algorithms), the memory (RAM) provides temporary storage space for plug-ins and data processing, the storage device (ROM) stores protocol plug-ins, semantic ontology models and system configurations, the communication interface module serves as a 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.

[0151] In step (1), the communication interface module includes various wired communication interfaces, various wireless communication interfaces and various 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 can be an RJ45 interface.

[0152] In step (2), the multi-modal 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. The software layer is the core of the system, the multi-modal protocol dynamic loading module is dynamically managed by the protocol feature recognition unit to realize heterogeneous protocol analysis; the semantic data mapping engine relies on the ontology model library and the mapping algorithm to complete the unified conversion of data semantics; 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; and the security enhancement module ensures the safety of the system from plug-in verification, data encryption to access control, and realizes key functions such as protocol conversion, semantic mapping and security processing in collaboration. The software layer controls the start and stop of the hardware interface (such as opening the RS-485 port to monitor device access) through the driver program, configures the communication parameters (such as baud rate, data bits), and calls the security encryption chip interface to realize data encryption / decryption.

[0153] In step (3), device access and protocol feature recognition include the following steps:

[0154] (3.1) Hardware connection and data monitoring: the device accesses the gateway through the communication interface module of the hardware layer, initializes the hardware layer and monitors the data port;

[0155] (3.2) Protocol feature recognition: the protocol feature recognition unit in the multi-modal protocol dynamic loading module of the software layer extracts data frame features;

[0156] (3.3) Protocol type determination: whether the protocol type used by the device matches the protocol feature library is determined through the preset protocol feature library:

[0157] If the protocol type matches the protocol feature library, step (4) is performed;

[0158] If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered.

[0159] In step (3.2), the extraction of data frame features includes parsing handshake packets, identifying port numbers and matching data frame formats. The handshake packet can be the slave address of Modbus RTU, the function code of Modbus RTU or the CONNECT packet of MQTT. The port number can be the default port 502 of Modbus TCP or the default port 1883 of MQTT. The data frame format can be the 29-bit identifier of CAN protocol or the CRC check code of Modbus. The data frame feature can be Modbus function code 0x03 or MQTT fixed header 0x10.

[0160] The protocol feature library in step (3.3) is a read holding register of Modbus function code 0x03 or a NPDU packet header of BACnet; and the protocol type is Modbus RTU protocol or MQTT protocol.

[0161] In step (4), the plug-in management unit in the multi-modal protocol dynamic loading module queries the local plug-in library to determine whether the local plug-in library has a matching protocol plug-in:

[0162] If the local plug-in library has a matching protocol plug-in, the matching protocol plug-in is directly loaded into the memory and step (7) is performed.

[0163] If the local plug-in library does not have a matching protocol plug-in, step (5) is performed.

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

[0165] In step (5), requesting a plug-in from a cloud server or a neighboring gateway through the collaborative communication interface of the edge collaborative computing module includes the following steps:

[0166] (5-1) Cloud scenario: downloading from a preset plug-in warehouse;

[0167] (5-2) Edge collaborative scenario: requesting a plug-in file from a gateway that has loaded the plug-in through a DHT network. The above plug-in warehouse can be a Docker Hub industrial protocol plug-in library. The above plug-in file can be a.so / .dll file or a Docker image file, and its request format can be set as: {protocol: "Modbus RTU", version: "1.0"}.

[0168] In 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, verifying the signature hash value using the CA public key, to ensure that the plug-in has not been tampered with;

[0169] (6.2) checking whether the plug-in metadata matches the current device:

[0170] If the plug-in metadata matches the current device, it is loaded into the memory and step (7) is performed.

[0171] If the plug-in metadata does not match the current device, it is rejected and a log is recorded.

[0172] Step (7) data parsing and semantic conversion includes:

[0173] (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;

[0174] (7.2) Semantic ontology mapping: bidirectional conversion according to the semantic ontology model library through the mapping algorithm module of the semantic data mapping engine.

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

[0176] The above-mentioned 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:

[0177] {

[0178] "protocol":"Modbus RTU",

[0179] "device_id":"01",

[0180] "register_address":"0x0100",

[0181] "raw_value":256

[0182] }

[0183] In step (7.1), the construction of the protocol plug-in: develop each protocol parsing plug-in using C++ / Python, encapsulate the protocol parsing function, and perform digital signature, store the plug-in and signature file to the local plug-in library or cloud server. The above-mentioned protocol parsing plug-in includes Modbus RTU plug-in, MQTT plug-in or BACnet plug-in. The above-mentioned protocol parsing function can adopt parse_modbus(data). The above-mentioned digital signature is generated by calling the security encryption chip API to generate RSA signature.

[0184] In step (7.2), the semantic ontology model library is imported: an industrial domain ontology model is constructed based on the OWL language, defining entity classes, attributes, and relationships. The semantic ontology model library is then imported into the gateway storage module via USB or network. The aforementioned industrial domain ontology model can be a temperature data ontology or a pressure data ontology. Entity classes can be equipment classes or data classes. The aforementioned attributes can be values, units, or precision. The aforementioned relationships can be membership or containment relationships. The aforementioned semantic ontology model library is a .owl file.

[0185] In step (7.2), the bidirectional transformation of semantic ontology mapping includes:

[0186] (7.2.1) Source Protocol to Ontology Model: Identify the corresponding ontology entity, apply transformation rules, extract semantic metadata, and generate an ontology instance;

[0187] (7.2.2) Ontology model to target protocol: Convert ontology instances into target data structures according to the format requirements of the target protocol.

[0188] The target protocol mentioned above can be either MQTT or OPC UA. The target data structure, for example, has a payload of 25.6 for MQTT, accompanied by JSON metadata indicating the unit.

[0189] The source protocol to ontology model step (7.2.1) above involves: identifying the ontology entity "TemperatureData" corresponding to raw_value (through the mapping rules between register addresses and ontology models), applying transformation rules (e.g., value = raw_value / 10), extracting semantic metadata (unit "℃", precision 0.1, function "device temperature monitoring"), and generating an ontology instance.

[0190] {

[0191] "entity":"TemperatureData",

[0192] "value":25.6,

[0193] "unit":"℃",

[0194] "precision":0.1,

[0195] "description": "Equipment temperature monitoring"

[0196] }

[0197] Step (8) Edge data processing and collaboration includes:

[0198] (8.1) Network scenario judgment: Determine whether the gateway is a multi-gateway network scenario through static configuration and dynamic automatic identification method:

[0199] If the gateway is not a multi-gateway network scenario, it is determined to be a single gateway and step (8.2) is performed;

[0200] If the gateway is a multi-gateway network scenario, it is determined to be a multi-gateway network and step (8.3) is performed;

[0201] (8.2) Localized preprocessing: Perform data filtering, aggregation calculation and protocol preprocessing through the local processing engine of the edge collaborative computing module, and proceed to step (9);

[0202] (8.3) Multi-gateway protocol sharing: Through the collaborative communication interface of the edge collaborative computing module, the protocol plug-in sharing and data synchronization of multi-gateway are realized, and step (9) is performed.

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

[0204] In the above step (8.3), through DHT network or MQTT protocol, the local non-stored protocol plug-in (such as newly acquired BACnet plug-in) is shared to the adjacent gateway, and the device state data (such as device online / offline state) is synchronized, realizing the distributed sharing of gateway plug-in and data in the region.

[0205] The static configuration judgment and dynamic automatic identification method in step (8.1) includes:

[0206] (8.1.1) Static configuration judgment method: In the initialization phase, read the configuration file, if the configuration file shows network_mode:"cluster", it is determined to be a multi-gateway network, skip step (8.1.2); if the configuration file shows network_mode:"local", it is determined to be a single gateway;

[0207] (8.1.2) Dynamic automatic identification method: If no static parameters are configured, the gateway sends a response message to the edge collaborative computing module after starting to try to discover adjacent gateways;

[0208] - Send a response message to the edge collaborative computing module to try to discover adjacent gateways;

[0209] - If a response from another gateway is received within 30 seconds, it is determined to be a multi-gateway network, and the plug-in sharing and data synchronization process is activated;

[0210] If there is no response after the timeout, it is determined that it is a single gateway, and only the localization preprocessing of step (8.2) is performed.

[0211] The configuration file can be a config.json file.

[0212] In step (8.2), data filtering: threshold detection is used to determine whether the semantic data is greater than or less than the threshold value, and if so, the semantic data is marked as an abnormal value and discarded; aggregation calculation: high-frequency data is down-sampled or cumulative values are calculated; protocol preprocessing: long data frames are split into short frames supported by the target protocol. For example, long BACnet messages are converted into Modbus multi-packet transmission.

[0213] 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 the adjacent gateway through the cooperative communication interface, supporting distributed decision-making.

[0214] Step (9) includes the following steps:

[0215] (9.1) Device identity authentication: verifying the device identity through the access control unit in the security enhancement module;

[0216] (9.2) Data encryption processing: transmission encryption and storage encryption;

[0217] (9.3) Target data forwarding;

[0218] (9.4) Protocol encapsulation and sending.

[0219] In the above step (9), the security enhancement module performs SM4 encryption on the processed data (calls the security encryption chip encryption interface), 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).

[0220] 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 SSL two-way authentication is performed on devices supporting digital certificates, and the connection is disconnected if the authentication fails. The device is connected to the gateway through the RS-485 / Ethernet interface, and the security enhancement module verifies the device MAC address / digital certificate (such as SSL two-way authentication), matches the device whitelist, and opens the data channel after passing. The above SSL authentication refers to the device sending a certificate or the gateway verifying with a CA public key.

[0221] In step (9.2), the transmission encryption is to select an encryption mode according to a target protocol, encrypt the data Payload using a national secret SM4 algorithm or an AES-256 algorithm, and generate ciphertext; the storage encryption is to perform AES-256 encryption on sensitive files such as semantic models and plug-in configurations when the data needs to be temporarily stored in the gateway storage module, and the key is generated and managed by a secure encryption chip. The above encryption mode can use MQTT over TLS or Modbus TCP with SSL.

[0222] In step (9.3), the target data forwarding is to forward according to a configuration rule by selecting different communication interfaces as follows:

[0223] Device-side forwarding: sending control instructions to other devices through an RS-485 interface or a CAN interface;

[0224] Cloud-side forwarding: sending data to a cloud server through an Ethernet interface or a 4G interface;

[0225] Local system forwarding: transmitting data to a local system through a local area network interface.

[0226] The above configuration rule can use a user-preset "Modbus device -> MQTT cloud" mapping. The above control instruction can be a parsed Modbus write instruction. The above cloud server can be an Ali Cloud IoT or a Siemens MindSphere. The above local system can be a SCADA local system.

[0227] In step (9.4), the protocol encapsulation and sending is to encapsulate the processed semantic data into a target protocol format and send through a communication layer interface to complete cross-platform communication. The above target protocol format can be an MQTT message or an OPC UA service request.

[0228] The embodiment also includes step (10) system monitoring and maintenance:

[0229] (10.1) Real-time monitoring: real-time viewing of running states of each module through a gateway management interface and receiving of abnormal alarms;

[0230] (10.2) Remote upgrade: a cloud server pushes a protocol plug-in update package or an ontology model patch, a gateway downloads through a secure channel, triggers a plug-in hot update mechanism, and ensures continuous optimization of system compatibility and security.

[0231] The above gateway management interface can be a Web UI. The running states of each module are, for example, CPU utilization, memory occupation, or plug-in loading. The above abnormality can be plug-in authentication failure or data encryption error. The above plug-in hot update mechanism is to load a new plug-in first and then uninstall an old plug-in.

[0232] Furthermore, it should be noted that the specific embodiments described in the specification, the name of each part, etc. can be different, and any equivalent or simple change made according to the structure, features and principles described in the patent concept of the present application is included in the protection scope of the present application. Those skilled in the art of the present application can make various modifications or supplements to the described specific embodiments or use similar ways to replace them, as long as they do not deviate from the structure of the present application or exceed the scope defined by the present claims, which should belong to the protection scope of the present application.

Claims

1. A gateway-based cross-platform device communication protocol conversion method, characterized in that... Includes the following steps: (1) Hardware layer construction: The hardware layer includes a processing unit, a storage module, a communication interface module, and a 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 accessed, the protocol type of the device is identified through the multimodal protocol dynamic loading module, and matched with the protocol feature library: If the protocol type matches the protocol feature library, proceed to step (4). If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered. (4) Dynamic protocol plugin loading: The matching protocol plugin is queried through the multimodal protocol dynamic loading module: If a matching protocol plugin exists, the matching protocol plugin will be loaded directly into memory and step (7) will be performed. If no matching protocol plugin is found, proceed to step (5); (5) Plugin request and transmission: Request plugins from the cloud server or adjacent gateway through the edge collaborative computing module; (6) Plugin security authentication: The plugin is authenticated through the security enhancement module. After successful authentication, it is loaded into memory and step (7) is performed. (7) Data parsing and semantic transformation: The plugin is called to parse the data and the data transformation is completed through the semantic data mapping engine; (8) Edge data processing and collaboration: Depending 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 as described in claim 1, characterized in that: In step (2), the multimodal protocol dynamic loading module is equipped with a protocol feature recognition unit and a plug-in management unit; the semantic data mapping engine is equipped with a mapping algorithm module; the edge collaborative computing module is equipped with a collaborative communication interface and a local processing engine; and the security enhancement module is equipped with a plug-in signature verification unit and an access control unit.

3. The gateway-based cross-platform device communication protocol conversion method as described in 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 identification: The protocol feature identification unit in the multimodal protocol dynamic loading module of the software layer extracts data frame features; (3.3) Protocol Type Determination: Based on a preset protocol feature library, determine whether the protocol type used by the device matches the protocol feature library: If the protocol type matches the protocol feature library, proceed to step (4). If the protocol type does not match the protocol feature library, it is marked as an unknown protocol and step (5) is triggered. The extraction of data frame features in step (3.2) includes parsing the handshake packet, identifying the port number, and matching the data frame format; In step (3.3), the protocol feature library is the Modbus function code 0x03 read holding register or the BACnet NPDU message header; the protocol type is Modbus RTU protocol or MQTT protocol.

4. The gateway-based cross-platform device communication protocol conversion method as described in claim 2, characterized in that: In step (4), the plugin management unit in the multimodal protocol dynamic loading module queries the local plugin library to determine whether a matching protocol plugin exists in the local plugin library: If a matching protocol plugin exists in the local plugin library, the matching protocol plugin will be loaded directly into memory and step (7) will be performed. If no matching protocol plugin exists in the local plugin library, proceed to step (5).

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

6. The gateway-based cross-platform device communication protocol conversion method as described in claim 2, characterized in that: Step (6) involves the following steps being performed by the plugin signature verification unit of the security enhancement module: (6.1) Extract the digital signature file of the plugin, and verify the signature hash value using the CA public key to ensure that the plugin 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 step (7) is performed. If the plugin metadata does not match the current device, the plugin will be rejected and logged.

7. The gateway-based cross-platform device communication protocol conversion method as described in claim 2, characterized in that: Step (7) data parsing and semantic transformation includes: (7.1) Syntax-level data parsing: Call the parsing function of the loaded protocol plugin to convert the raw 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 step (7.1), the protocol plugin is constructed by developing each protocol parsing plugin using C++ / Python, encapsulating the protocol parsing function, performing digital signature, and storing the plugin and signature file in a local plugin library or cloud server. In step (7.2), the semantic ontology model library is imported: an industrial domain ontology model is constructed based on the OWL language, defining entity classes, attributes and relationships, and the semantic ontology model library is imported into the gateway storage module via USB or network. In step (7.2), the bidirectional transformation of semantic ontology mapping includes: (7.2.1) Source Protocol to Ontology Model: Identify the corresponding ontology entity, apply transformation rules, extract semantic metadata, and generate an ontology instance; (7.2.2) Ontology model to target protocol: Convert ontology instances into target data structures according to the format requirements of the target protocol.

8. The gateway-based cross-platform device communication protocol conversion method as described in claim 2, characterized in that: Step (8) edge data processing and collaboration includes: (8.1) Network Scenario Judgment: The method of static configuration judgment and dynamic automatic identification is used to determine whether the gateway is in a multi-gateway network scenario: If the gateway is not part of a multi-gateway network scenario, it is determined to be a single gateway and step (8.2) is performed. If the gateway is a multi-gateway network scenario, then it is determined to be a multi-gateway network and step (8.3) is performed. (8.2) Localized preprocessing: Data filtering, aggregation calculation and protocol preprocessing are performed through the local processing engine of the edge collaborative computing module, and step (9) is performed. (8.3) Multi-gateway protocol sharing: The protocol plugin sharing and data synchronization of multiple gateways are realized through the collaborative communication interface of the edge collaborative computing module, and step (9) is performed.

9. The gateway-based cross-platform device communication protocol conversion method as described in claim 2, characterized in that: Step (9) includes the following steps: (9.1) Device authentication: Verify device identity through the access control unit in the security enhancement module; (9.2) Data encryption processing: encryption during transmission and encryption during storage; (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 to perform SSL two-way authentication on devices that support digital certificates. If the authentication fails, the connection will be disconnected. In step (9.2), the transmission encryption is to select an encryption method according to the target protocol and use the national cryptographic SM4 algorithm or AES-256 algorithm to encrypt the data payload and generate ciphertext; the storage encryption is to encrypt sensitive files such as semantic model and plug-in configuration 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. In step (9.3), the target data forwarding is performed by selecting the following different communication interfaces according to the configuration rules: Device-side forwarding: Sending control commands to other devices via RS-485 or CAN interface; Cloud forwarding: Data is sent to the cloud server via Ethernet or 4G interface; Local system forwarding: Data is transmitted to the local system via the local area network interface; The protocol encapsulation and transmission in step (9.4) involves encapsulating the processed semantic data into the target protocol format and sending it through the communication layer interface to complete cross-platform communication.

10. The gateway-based cross-platform device communication protocol conversion method as described in 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 plugin update package or ontology model patch. After the gateway downloads it through the secure channel, it triggers the plugin hot update mechanism to ensure continuous optimization of system compatibility and security.

Images