Multi-protocol adaptive access method and device for Internet of Things, and medium

Abstract

The embodiment of the invention discloses an Internet of Things multi-protocol adaptive access method and device and a medium, belongs to the technical field of Internet of Things communication, and solves the problems that an Internet of Things gateway protocol is insufficient in compatibility and insufficient in safety controllability in an industrial-grade high-reliability scene and a cross-platform collaborative scene. Comprising the following steps: loading a preset protocol plug-in, and carrying out initialization processing on a communication engine and a configuration management center so as to monitor a default port corresponding to each protocol; based on a feature code matching and AI protocol identification combined strategy, performing corresponding protocol matching identification on the monitored equipment connection request; verifying the current equipment based on preset authentication information, and establishing an encrypted data transmission channel under the condition that the verification is passed; receiving an original message sent by the equipment, and converting the original message into a uniform data format; and encrypting the data in the uniform format through the encrypted data transmission channel, calling the matched and identified protocol, and reporting the encrypted data to the Internet of Things platform through the communication engine.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) communication technology, and in particular to an IoT multi-protocol adaptive access method, device, and medium. Background Technology

[0002] With the widespread adoption of IoT technology in smart parks, intelligent manufacturing, and smart cities, terminal devices are gradually exhibiting characteristics of heterogeneity, scalability, and dynamism. For example, in industrial scenarios, there are PLCs using Modbus RTU / TCP protocols, servers using OPC UA protocols, and sensors using CAN buses; in building scenarios, lighting controllers using KNX protocols and HVAC equipment using BACnet / IP protocols are deployed; while in lightweight scenarios, wireless terminals using MQTT and LwM2M protocols are widely used.

[0003] There are currently more than 30 mainstream communication protocols in the Internet of Things (IoT) field, and different manufacturers have their own proprietary protocols for their devices, making unified access for heterogeneous devices a common challenge in the industry.

[0004] Although the protocol support capabilities of IoT gateways in existing technologies have been significantly improved, in actual deployments, especially in industrial high-reliability scenarios, cost-sensitive scenarios for SMEs, and cross-platform collaboration scenarios, there are still problems such as insufficient compatibility and insufficient security controllability. Summary of the Invention

[0005] This application provides an IoT multi-protocol adaptive access method, device, and medium to solve the following technical problems: In the prior art, IoT gateway protocols still suffer from insufficient compatibility and security controllability in industrial-grade high-reliability scenarios, cost-sensitive scenarios for small and medium-sized enterprises, and cross-platform collaborative scenarios.

[0006] The embodiments of this application adopt the following technical solutions: This application provides an IoT multi-protocol adaptive access method. It includes: loading pre-built protocol plugins; initializing the communication engine and configuration management center to listen to the default ports corresponding to each protocol; matching and identifying the corresponding protocol for the listened-to device connection requests based on a combination strategy of feature code matching and AI protocol recognition; verifying the current device based on preset authentication information, and establishing an encrypted data transmission channel if the verification is successful; receiving the original message sent by the device, parsing the original message into structured data, and converting the structured data into a unified data format; encrypting the unified format data through the encrypted data transmission channel, invoking the matched and identified protocol, and reporting the encrypted data to the IoT platform through the communication engine.

[0007] In one implementation of this application, a combined strategy of feature code matching and AI protocol recognition is used to match and identify the corresponding protocol for the monitored device connection request. Specifically, this includes: reading a message within a preset byte range from the monitored device connection request; wherein the preset byte range includes at least the number of bytes and the byte position center; matching the message within the preset byte range with the message header features in a preset protocol feature code library; if the match is successful, invoking the corresponding protocol plugin; wherein the preset protocol feature code library includes multiple message header features and multiple protocol plugins corresponding to each message header feature; if the match fails, triggering the AI ​​protocol recognition, extracting message features from the connection request, and inputting the extracted message features into a random forest model for protocol recognition.

[0008] In one implementation of this application, the current device is verified based on preset authentication information, and an encrypted data transmission channel is established upon successful verification. Specifically, this includes: upon receiving a connection request sent by the device, verifying the device based on the device fingerprint and authentication information corresponding to the device; wherein the device fingerprint is composed of the hardware and software features corresponding to the device; upon successful verification, encrypting and transmitting the data using the national cryptographic SM4 algorithm; and signing the standardized data using the SM3 algorithm.

[0009] In one implementation of this application, receiving the raw message sent by the device, parsing the raw message into structured data, and converting the structured data into a unified data format specifically includes: receiving the raw message through a plugin, and calling the parse method implemented by the protocol plugin to parse the raw message into the structured data; converting the structured data into a unified JSON format; wherein the data corresponding to the JSON format includes at least one of the following: device unique identifier, data acquisition time, access protocol type, data type, standardized data, and data signature.

[0010] In one implementation of this application, after converting the structured data into a unified data format, the method further includes: matching the original fields of the protocol with a preset object model library using the Word2Vec semantic similarity algorithm, and realizing intelligent field mapping based on the similarity of the matching; wherein the preset object model includes attribute information covering the current application scenario; and, based on the historical data range corresponding to the device, performing validity verification on the current data, and if the verification result does not conform to the historical data range, marking abnormal data.

[0011] In one implementation of this application, the communication engine uses a master-slave Reactor multi-threaded network model; wherein the master Reactor is used to listen for device connection requests, and the slave Reactor is used for data read and write operations; the TCP_NODELAY algorithm is enabled for the communication engine, and memory allocation and reclamation overhead is reduced through a memory pool; and the state of batch data transmission of the communication engine is set by pre-setting a data transmission threshold; wherein the set transmission state includes at least one of single-node data throughput, response latency, and data loss rate.

[0012] In one implementation of this application, after the encrypted data is reported to the IoT platform through the communication engine, the method further includes: obtaining the operating data corresponding to the device within a preset historical time period, and extracting behavioral features based on the operating data; wherein, the behavioral features include at least one of data reporting frequency, data value range, and connection time period; determining the average data value corresponding to each behavioral feature, and determining the behavioral baseline corresponding to each behavioral feature based on the average data value; comparing the obtained current data corresponding to the device with the behavioral baseline, and determining the corresponding anomaly level based on the comparison difference.

[0013] In one implementation of this application, after loading a pre-built protocol plugin and initializing the communication engine and configuration management center, the method further includes: responding to a new protocol instruction and uploading a plugin compressed package through the configuration management center; decompressing, installing, and loading the plugin compressed package; and after the plugin is successfully loaded, listening to the interface corresponding to the new protocol to achieve dynamic extension of the protocol.

[0014] This application provides an IoT multi-protocol adaptive access device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: load a pre-set protocol plugin, initialize the communication engine and configuration management center to listen to the default ports corresponding to each protocol; match and identify the corresponding protocol for the listened-to device connection requests based on a combination strategy of feature code matching and AI protocol recognition; verify the current device based on preset authentication information, and establish an encrypted data transmission channel if the verification is successful; receive the original message sent by the device, parse the original message into structured data, and convert the structured data into a unified data format; encrypt the unified format data through the encrypted data transmission channel, call the matched and identified protocol, and report the encrypted data to the IoT platform through the communication engine.

[0015] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: load a pre-set protocol plugin; initialize the communication engine and configuration management center to listen to the default ports corresponding to each protocol; match and identify the corresponding protocol for the listened-to device connection requests based on a combination strategy of feature code matching and AI protocol recognition; verify the current device based on preset authentication information and establish an encrypted data transmission channel upon successful verification; receive the original message sent by the device, parse the original message into structured data, and convert the structured data into a unified data format; encrypt the unified format data through the encrypted data transmission channel, call the matched and identified protocol, and report the encrypted data to the IoT platform through the communication engine.

[0016] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: Firstly, this application embodiment uses feature code matching to identify most mainstream protocols, ensuring rapid access for conventional devices. Secondly, it uses a lightweight random forest model to solve the problem of difficult identification of non-standard or proprietary protocols, avoiding errors in manual configuration. Thirdly, this application embodiment uses device fingerprinting, national cryptographic algorithms, and dynamic authentication to intercept spoofing attacks, ensuring device legitimacy. It also uses encrypted channels to protect transmitted data, preventing eavesdropping and tampering, and ensuring the security of industrial instructions and sensitive data. Furthermore, this application embodiment parses the original message into structured data and then converts it to a standard format, eliminating differences in heterogeneous protocol data. Combined with semantic mapping, it eliminates the need for manual field mapping, laying the foundation for subsequent cross-platform collaboration and reducing adaptation costs. Finally, this application embodiment ensures data transmission security through encrypted channels and uses a high-concurrency engine to report data via a matching protocol, ensuring no data leakage during transmission while meeting the real-time requirements of large-scale concurrent reporting by devices, supporting efficient data collaboration in scenarios such as smart parks and intelligent manufacturing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A framework diagram of an IoT multi-protocol adaptive access system provided in this application embodiment; Figure 2 A flowchart of an IoT multi-protocol adaptive access method provided in this application embodiment; Figure 3A ProtocolInterface unified interface definition diagram provided for embodiments of this application; Figure 4 A flowchart for automatic protocol identification provided in this application embodiment; Figure 5 A cluster deployment architecture diagram provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of an IoT multi-protocol adaptive access device provided in an embodiment of this application.

[0018] Figure label: 200: IoT multi-protocol adaptive access device; 201: Processor; 202: Memory. Detailed Implementation

[0019] This application provides an IoT multi-protocol adaptive access method, device, and medium.

[0020] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0021] Figure 1 A framework diagram of an IoT multi-protocol adaptive access system provided in this application embodiment is shown below. Figure 1 As shown, the IoT multi-protocol adaptive access system includes the hierarchical relationship of the protocol adaptation layer, device access management module, unified data abstraction layer, security authentication module, configuration management center, high-concurrency communication engine, and device behavior analysis module, as well as the data flow of device access → protocol identification → security authentication → data standardization → forwarding monitoring.

[0022] Figure 2 A flowchart of an IoT multi-protocol adaptive access method provided in this application embodiment is shown below. Figure 2 As shown, the IoT multi-protocol adaptive access method includes the following steps: S101. Load the pre-built protocol plugins and initialize the communication engine and configuration management center to listen on the default ports corresponding to each protocol.

[0023] In one implementation of this application, a protocol adaptation layer is provided, namely a plug-in architecture and standardized interfaces. By adopting a unified interface combined with plug-in deployment, the runtime loading or unloading of protocol plug-ins is supported without requiring a system restart. Figure 3 A Protocol Interface unified interface definition diagram is provided for embodiments of this application, such as... Figure 3 As shown, the interface definition is as follows: Standardized interface definition: All protocol plugins implement the unified ProtocolInterface interface, which includes four core methods: connect(String deviceId, Map...).<String, Object> params): Establishes a device connection. Parameters include port number, baud rate, Broker address, etc. parse(byte[] rawData): Parses the raw message and returns structured data, such as parsing a Modbus register into key-value pairs; serialize(Map<String, Object> standardData: Serializes standardized data into protocol messages, such as JSON to MQTT payload; disconnect(String deviceId): Disconnects the device and releases resources.

[0024] Plugin deployment methods: Supports two deployment modes to meet different scenario requirements: Lightweight scenario: Deployed as a dynamic link library, with a loading time of ≤100ms; High reliability scenario: Deployed as a containerized microservice in Docker, each plugin occupies independent resources and communicates with the main system via gRPC.

[0025] Plugin ecosystem: Pre-installed with a variety of mainstream protocol plugins, including Modbus RTU / TCP, OPC UA, BACnet / IP, MQTT, CoAP, LwM2M, HTTP, WebSocket, Profibus, KNX, CAN, DDS, LoRaWAN, NB-IoT, ZigBee, etc., covering more than 95% of IoT device protocols.

[0026] Furthermore, during the system initialization phase, the gateway system is started, pre-built protocol plugins such as Modbus and MQTT are loaded, the Netty communication engine and configuration management center are initialized, and the default ports of each protocol are listened to, for example: 502 → ModbusTCP, 1883 → MQTT, 4840 → OPC UA.

[0027] S102. Based on the combined strategy of feature code matching and AI protocol recognition, the monitored device connection requests are matched and identified according to the corresponding protocols.

[0028] In one implementation of this application, a preset byte range of messages is read from the detected device connection request; the preset byte range includes at least the number of bytes and the byte position center. The messages within the preset byte range are matched with message header features in a preset protocol feature code library. If a match is successful, the corresponding protocol plugin is invoked; the preset protocol feature code library includes various message header features and corresponding protocol plugins for each of the various message header features. If a match fails, AI protocol recognition is triggered, message features are extracted from the connection request, and the extracted message features are input into a random forest model for protocol recognition.

[0029] Specifically, the embodiments of this application integrate a dual mechanism of feature code matching and machine learning recognition to achieve accurate and rapid recognition of the protocol. Figure 4 A flowchart for automatic protocol identification provided in this application embodiment, such as Figure 4 As shown, the automatic protocol identification process includes: device initiates connection → reads the first 8 bytes of the message → matches the feature code library → matching successfully → calls the corresponding protocol plugin; matching fails → extracts byte entropy value / field offset / length distribution features → inputs into a lightweight random forest model → identifies the protocol type → calls the plugin → updates the feature code library after manual confirmation, forming a self-optimizing closed loop.

[0030] Signature matching involves establishing a protocol signature database, storing the header features of each protocol. For example, the first two bytes of Modbus TCP are the transaction ID, BACnet / IP contains an APDU type identifier of 0x81-0xA0, and the first byte of the MQTT header is the control message type. Upon receiving a device connection request, the first 8 bytes of the message are read and matched against the signature database. The matching success rate is ≥90%, and the identification time is ≤1ms.

[0031] Machine learning recognition includes feature extraction: for non-standard messages (such as Modbus with custom ports), three core features are extracted: byte entropy, field offset, and message length distribution. Model selection: a lightweight random forest model is used, with training data containing over 100,000 heterogeneous protocol messages, cross-validation accuracy ≥98%, and inference time ≤5ms. Dynamic updates: the model is incrementally trained monthly based on newly added message data, continuously optimizing recognition accuracy.

[0032] It should be noted that the overall success rate, the number of bytes read, and the training data in this application embodiment can be dynamically adjusted according to the actual use scenario, and this application embodiment does not impose any limitations on this.

[0033] In other words, when a device initiates a connection request, the gateway reads the first 8 bytes of the message, first matching it against the protocol signature database. If a match is found, the corresponding protocol plugin is invoked. If the signature match fails, AI protocol recognition is triggered, extracting message features and inputting them into a random forest model. After identifying the protocol type, the corresponding plugin is loaded.

[0034] S103. Verify the current device based on the preset authentication information, and establish an encrypted data transmission channel if the verification is successful.

[0035] In one implementation of this application, upon receiving a connection request from a device, the device is verified based on its corresponding device fingerprint and authentication information; wherein the device fingerprint consists of the device's corresponding hardware and software features. If verification is successful, the data is encrypted and transmitted using the national cryptographic algorithm SM4, and the standardized data is signed using the SM3 algorithm.

[0036] Specifically, in this embodiment of the application, the plugin calls the security authentication module to verify the device fingerprint and authentication information. If the authentication is successful, an encrypted channel is established; if the authentication fails, the connection is rejected and a log is recorded.

[0037] Furthermore, this application embodiment employs triple protection of device fingerprinting, national cryptographic encryption, and dynamic authentication. First, the device performs fingerprint binding. When the device connects for the first time, hardware features such as MAC address and CPU serial number are collected, as well as software features such as firmware version and operating system version. A unique device fingerprint is generated through hardware and software features and bound to the device ID. It cannot be tampered with. During subsequent connections, the fingerprint consistency is verified. If the fingerprint does not match, the connection is rejected. The spoofing attack interception rate is ≥95%.

[0038] Secondly, national cryptographic algorithms are used for encryption. Transmission encryption: The national cryptographic algorithm SM4 is used to encrypt data transmission, and the key is negotiated through SM2 asymmetric encryption to prevent data eavesdropping. Data signature: The SM3 algorithm is used to sign standardized data to ensure data integrity and achieve a 100% tamper detection rate.

[0039] Furthermore, dynamic authentication is implemented. This application embodiment supports three authentication methods: X.509 certificate, token, and SMS verification code. These can be configured according to device importance; for example, core PLCs can use certificate authentication, while ordinary sensors can use token authentication. If authentication fails a certain number of times (e.g., after three attempts), the device will be locked and requires manual unlocking to prevent brute-force attacks.

[0040] S104. Receive the original message sent by the receiving device, parse the original message into structured data, and convert the structured data into a unified data format.

[0041] In one implementation of this application, the original message is received by a plugin, and the parse method implemented by the protocol plugin is called to parse the original message into structured data, and the structured data is converted into a unified JSON format; wherein, the data corresponding to the JSON format includes at least one of the following: device unique identifier, data acquisition time, access protocol type, data type, standardized data, and data signature.

[0042] Furthermore, this embodiment of the application uses the Word2Vec semantic similarity algorithm to match the original fields of the protocol with a preset object model library, and realizes intelligent field mapping based on the similarity of the match; wherein, the preset object model includes attribute information covering the current application scenario. Additionally, based on the historical data range corresponding to the device, the validity of the current data is verified; if the verification result does not conform to the historical data range, abnormal data is marked.

[0043] Specifically, in this embodiment, the plug-in receives the original message from the receiving device, calls the parse() method to parse it into structured data, the unified data abstraction layer converts the structured data into standard JSON format, performs intelligent field mapping and quality verification, and performs SM3 signing on the standardized data to ensure integrity.

[0044] Specifically, embodiments of this application can convert structured data from different protocols into a unified JSON format and support object model mapping.

[0045] The standard data format is defined as follows: {"device_id": "sensor_001", / / Unique device identifier (device fingerprint generation) "timestamp":"2025-04-05T10:00:00Z", / / Data acquisition time (UTC) "protocol": "modbus", / / Access protocol type "data_type": "property", / / Data type (property / event / service) "data": { / / Standardized data "temperature": {"value": 26.5, "unit": "℃", "quality": "good"},"humidity": {"value": 60, "unit": "%RH", "quality": "good"}},"signature": "xxx" / / Data signature (Chinese national cryptographic standard SM3)}.

[0046] Secondly, this application embodiment establishes a preset object model library, which covers 1000+ standard attributes in scenarios such as smart parks and manufacturing. The Word2Vec semantic similarity algorithm is used to match the original fields of the protocol, such as Modbus register address 0x0001, with the object model attributes. When the similarity is ≥0.8, the mapping is automatically recommended. After manual confirmation, the mapping rules are saved, and the mapping efficiency is improved by 80%.

[0047] This application also performs data quality verification. Specifically, it verifies the validity of data based on the historical data range of the equipment (such as temperature -40~85℃), marks abnormal data as "bad", and triggers an alarm.

[0048] It should be noted that the similarity in this embodiment is preferably set to 0.8, but it can be adjusted according to the usage scenario in the application. This embodiment does not limit this.

[0049] S105. Encrypt data in a unified format through an encrypted data transmission channel, call the matched and identified protocol, and report the encrypted data to the IoT platform through the communication engine.

[0050] In one implementation of this application, the encapsulated protocol message is submitted to a high-concurrency communication engine. The engine, based on the Netty asynchronous non-blocking I / O framework and a master-slave Reactor multi-threaded model, invokes preset network transmission logic, such as enabling TCP_NODELAY to optimize latency and using a memory pool to reduce resource overhead, to establish a communication connection with the IoT platform. The communication engine sends the protocol message to the IoT platform via the default port, simultaneously recording data reporting logs and triggering the device behavior analysis module to monitor the reporting behavior in real time, ensuring a stable and traceable data reporting process.

[0051] Furthermore, in this embodiment, the communication engine uses a master-slave Reactor multi-threaded network model; wherein the master Reactor listens for device connection requests, and the slave Reactor performs data read and write operations. The TCP_NODELAY algorithm is enabled for the communication engine, and a memory pool is used to reduce memory allocation and reclamation overhead. Additionally, a preset data sending threshold is used to set the state of batch data sending for the communication engine; wherein the set sending state includes at least one of the following: single-node data throughput, response latency, and data loss rate.

[0052] Specifically, this application embodiment is built on the Netty asynchronous non-blocking I / O framework, optimizing the network model and thread scheduling. The network model adopts a master-slave Reactor multi-threaded model, where the master Reactor is responsible for listening for connections and the slave Reactors are responsible for data reading and writing. The thread pool is dynamically adjusted according to the number of CPU cores (cores × 2). TCP_NODELAY is enabled to disable the Nagle algorithm, reducing latency. A memory pool (PooledByteBufAllocator) is used to reduce memory allocation and reclamation overhead, supporting batch data transmission, such as aggregating sensor data every 100ms, with a single-node throughput ≥ 100,000 records / second and a response latency ≤ 50ms. This application embodiment supports TCP reconnection with reconnection intervals of 1 / 3 / 5 seconds, and also supports data retransmission, with a data loss rate ≤ 0.01%.

[0053] In one implementation of this application, operational data corresponding to the device within a preset historical time period is obtained, and behavioral features are extracted based on the operational data; wherein, the behavioral features include at least one of data reporting frequency, data value range, and connection time period. The mean value of the data corresponding to each behavioral feature is determined, and a behavioral baseline corresponding to each behavioral feature is determined based on the mean value. The current data corresponding to the device is compared with the behavioral baseline, and the corresponding anomaly level is determined based on the comparison difference.

[0054] Specifically, this application embodiment establishes a baseline for normal equipment behavior, detects abnormal behavior, and triggers protective measures. The behavior baseline modeling includes: collecting 30 days of normal equipment operation data and extracting three types of behavioral characteristics: data reporting frequency (e.g., temperature and humidity sensors report data every 5 minutes); data value range (e.g., temperature 20~30℃); and connection time period (e.g., production equipment is online from 8:00 to 20:00).

[0055] A baseline is established using statistical methods (mean ± 2 standard deviations), and the baseline is updated every 7 days. Anomaly detection and handling include: real-time comparison of the current equipment behavior with the baseline. Anomaly types include: abnormal reporting frequency, such as changing from once every 5 minutes to once every second; abnormal data values, such as a sudden temperature change to 100℃; and abnormal connection times, such as production equipment connecting at 2 AM. Handling strategies include: triggering alarms for Level 1 anomalies (minor, such as reporting delays); triggering secondary authentication for Level 2 anomalies (moderate, such as data exceeding the range); and directly disconnecting the connection for Level 3 anomalies (severe, such as a sudden increase in frequency). The anomaly handling response time is ≤1 second.

[0056] In one implementation of this application, when adding a new protocol, this embodiment uploads the plugin.zip package through the configuration management center. The system automatically decompresses, installs, and loads the plugin. After the plugin is successfully loaded, it listens for the new protocol port, enabling devices to connect immediately without restarting the system.

[0057] In one implementation of this application, an embodiment provides a Web UI and a RESTful API to achieve visualized configuration and monitoring of the entire system. Specifically: Plugin Management: Supports uploading, installing, uninstalling, and upgrading protocol plugins. Upload format is .zip (containing plugin files, configuration templates, and documentation); displays plugin running status, automatically restarts in case of abnormalities, and triggers email alerts if restart fails.

[0058] Device Management: Displays device connection status, protocol type, data reporting frequency, and signal strength; supports remote device disconnection and parameter configuration; provides device access log query, with logs retained for ≥90 days.

[0059] System monitoring: Real-time monitoring of CPU, memory, and network throughput, concurrent connections per node, triggering expansion suggestions when thresholds are exceeded, supporting cluster deployment configuration, and automatic load balancing.

[0060] Taking a smart park as an application scenario, assuming the smart park deploys 1000 temperature and humidity sensors, of which 800 support Modbus RTU and connect via RS485, and 200 support MQTT and connect via WiFi, they need to be uniformly connected to the park's IoT platform to achieve real-time monitoring and alarms. This embodiment uses a single gateway to connect to the park's IoT platform, with pre-built plugins including: a Modbus plugin (.so format) and an MQTT plugin (Docker container format).

[0061] The system initializes, starts the gateway, and automatically loads the Modbus and MQTT plugins. Modbus listens on the RS485 serial port, for example, with a baud rate of 9600, 8 data bits, and 1 stop bit. MQTT listens on port 1883. The configuration management center's Web UI displays the plugin status as running.

[0062] For device connection and protocol identification, Modbus sensors are connected to the gateway via RS485. The gateway reads the first 8 bytes of the message, matches them with the feature code library, and calls the Modbus plugin. MQTT sensors are connected to port 1883 via WiFi. The gateway reads the first 2 bytes of the message, matches them with the feature code library, and calls the MQTT plugin.

[0063] For security authentication, when a sensor is first connected, the gateway collects its MAC address (00:1B:44:11:3A:B7) and firmware version to generate a device fingerprint (UUID: a1b2c3d4-e5f6-7890-abcd-1234567890ab), which is then bound to the device ID (sensor_001~sensor_1000). Token authentication is used, and an SM4 encrypted channel is established after successful authentication.

[0064] Data parsing and standardization: The Modbus plugin parses register data (0x0001=265 → temperature 26.5℃, 0x0002=600 → humidity 60%), calls the parse() method to return structured data, and the unified data abstraction layer converts it into standard JSON: { "device_id": "sensor_001", "timestamp": "2025-04-05T10:00:00Z", "protocol": "modbus_rtu", "data_type": "property", "data": { "temperature": {"value": 26.5, "unit": "℃", "quality": "good"}, "humidity": {"value": 60, "unit": "%RH", "quality": "good"}}, "signature": "sm3:abc123..."} - The MQTT plugin directly receives the JSON payload; the unified data abstraction layer only needs to supplement the fields and signature, without complex parsing.

[0065] Data forwarding and behavior monitoring: The high-concurrency communication engine reports standardized data in batches to the park platform, aggregating once every 100ms, with a throughput of 1000 data entries / second and a latency of ≤30ms. The device behavior analysis module monitors the reporting frequency of sensors, and continues to forward data if there are no abnormalities. If the reporting frequency of a certain sensor suddenly changes to once per second, a level 2 alarm is triggered and secondary authentication is required.

[0066] Dynamic expansion: When 50 more KNX protocol lighting controllers are added, the KNX plugin.zip package is uploaded through the configuration center, the system automatically unzips and installs it, the loading time is 80ms, and the lighting controllers listen on the default KNX port 3671. The lighting controllers are connected immediately without restarting the gateway.

[0067] In addition to the aforementioned quantitative advantages, the embodiments of this application also possess scenario adaptability and collaborative value: In industrial scenarios, it can directly connect to MES and digital twin systems, shortening the data access cycle from 3 days to 1 hour; in smart park scenarios, a single gateway can replace 3-5 traditional single-protocol gateways, reducing hardware and maintenance costs by 60%-70%; in cross-platform collaborative scenarios, the standard JSON format eliminates the need for customized converters, reducing the cost of adapting to mainstream platforms such as AWS IoT and Huawei Cloud IoT by 80%, demonstrating strong commercialization potential.

[0068] Based on this, using the method in this application embodiment, 1000 sensors can be connected within 5 minutes, improving efficiency by 99.8% compared to traditional manual configuration. The gateway CPU utilization is ≤30%, memory usage is ≤4GB, a single node can stably support 1000 devices, and can support 100,000+ after concurrent expansion. It can intercept simulated device spoofing attacks with a 100% interception rate. It cannot eavesdrop during data transmission and cannot decrypt SM4 encrypted data. The status of all devices can be viewed in real time through the Web UI. It automatically restarts when the plugin is abnormal, and the system availability reaches 99.99%.

[0069] This application's embodiments support hot-swappable deployment of over 15 mainstream protocols through a standardized interface plug-in architecture. The cycle for adding new protocols is shortened from the existing 2-7 days to ≤2 days, and the Docker containerized deployment mode avoids the risk of fault propagation. A dual-mechanism identification scheme integrating signature matching and a lightweight random forest model overcomes the challenge of automatically identifying non-standard and proprietary protocols, achieving an accuracy rate of ≥98% and significantly reducing the error rate of manual configuration. An abstraction layer design based on a unified JSON format and Word2Vec intelligent mapping enables standardized conversion of heterogeneous data, adapting to multi-platform collaboration needs. A triple security system of device fingerprinting, national cryptographic algorithms, and behavioral baselines increases the device spoofing interception rate from ≤60% to ≥95%, meeting the Level 3 requirements of the Information Security Protection Scheme 2.0.

[0070] Figure 5 A cluster deployment architecture diagram is provided for an embodiment of this application, such as Figure 5 As shown, the cluster includes multiple gateway nodes, a load balancer, an IoT platform connection relationship, and a load balancing strategy that dynamically allocates nodes based on the number of devices.

[0071] Figure 6 This is a schematic diagram of the structure of an IoT multi-protocol adaptive access device provided in an embodiment of this application. Figure 6As shown, the IoT multi-protocol adaptive access device 200 includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201. The memory 202 stores instructions executable by the at least one processor 201, which, when executed, enable the at least one processor 201 to: load pre-set protocol plugins; initialize the communication engine and configuration management center to listen to the default ports corresponding to each protocol; match and identify the corresponding protocol for the listened-to device connection requests based on a combination strategy of feature code matching and AI protocol recognition; verify the current device based on preset authentication information and establish an encrypted data transmission channel if verification is successful; receive raw messages sent by the device, parse the raw messages into structured data, and convert the structured data into a unified data format; encrypt the unified format data through the encrypted data transmission channel, call the matched and identified protocol, and report the encrypted data to the IoT platform through the communication engine.

[0072] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: load a pre-set protocol plugin; initialize the communication engine and configuration management center to listen to the default ports corresponding to each protocol; match and identify the corresponding protocol for the listened-to device connection requests based on a combination strategy of feature code matching and AI protocol recognition; verify the current device based on preset authentication information and establish an encrypted data transmission channel upon successful verification; receive the original message sent by the device, parse the original message into structured data, and convert the structured data into a unified data format; encrypt the unified format data through the encrypted data transmission channel, call the matched and identified protocol, and report the encrypted data to the IoT platform through the communication engine.

[0073] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0074] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A multi-protocol adaptive access method for the Internet of Things, characterized in that, The method includes: Load the pre-built protocol plugins and initialize the communication engine and configuration management center to listen on the default ports corresponding to each protocol; Based on a combination strategy of feature code matching and AI protocol recognition, the monitored device connection requests are matched and identified according to the corresponding protocols. The device is verified based on preset authentication information, and an encrypted data transmission channel is established if the verification is successful. Receive the raw message sent by the device, parse the raw message into structured data, and convert the structured data into a unified data format; The encrypted data transmission channel encrypts data in a unified format, and the matched and identified protocol is invoked. The encrypted data is then reported to the Internet of Things platform through the communication engine.

2. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, The strategy based on a combination of feature code matching and AI protocol recognition performs corresponding protocol matching and recognition on the monitored device connection requests, specifically including: For the detected device connection request, a message within a preset byte range is read; wherein, the preset byte range includes at least one of the number of bytes and the byte position center; The message within the preset byte range is matched with the message header features in the preset protocol feature code library. If the match is successful, the corresponding protocol plugin is invoked. The preset protocol feature code library includes various message header features and various protocol plugins corresponding to each message header feature. If the match fails, the AI ​​protocol identification is triggered, the message features of the connection request are extracted, and the extracted message features are input into the random forest model for protocol identification.

3. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, The process of verifying the current device based on preset authentication information and establishing an encrypted data transmission channel upon successful verification specifically includes: Upon receiving a connection request from the device, the device is verified based on its corresponding device fingerprint and authentication information; wherein, the device fingerprint is composed of the device's corresponding hardware and software features. If the verification is successful, the data is transmitted in encrypted form using the national cryptographic algorithm SM4. In addition, standardized data is signed using the SM3 algorithm.

4. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, The process of receiving the raw message sent by the device, parsing the raw message into structured data, and converting the structured data into a unified data format specifically includes: The plugin receives the original message and calls the parse method implemented by the protocol plugin to parse the original message into the structured data. Convert the structured data into a unified JSON format; The data in the JSON format includes at least one of the following: unique device identifier, data collection time, access protocol type, data type, standardized data, and data signature.

5. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, After converting the structured data into a unified data format, the method further includes: The Word2Vec semantic similarity algorithm is used to match the original fields of the protocol with a pre-set object model library, and intelligent field mapping is achieved based on the similarity of the matching; wherein, the pre-set object model includes attribute information covering the current application scenario; Furthermore, based on the historical data range corresponding to the device, the current data is validated. If the validation result does not conform to the historical data range, abnormal data is marked.

6. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, The communication engine is a master-slave Reactor multi-threaded network model; the master Reactor is used to listen for device connection requests, and the slave Reactor is used for data read and write operations. Enable the TCP_NODELAY algorithm for the communication engine and reduce memory allocation and reclamation overhead through a memory pool; Furthermore, the communication engine's batch data transmission status is set by pre-setting a data transmission threshold; wherein the set transmission status includes at least one of single-node data throughput, response latency, and data loss rate.

7. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, After the encrypted data is reported to the IoT platform via the communication engine, the method further includes: The system acquires the device's operational data within a preset historical time period and extracts behavioral features based on the operational data; wherein the behavioral features include at least one of the following: data reporting frequency, data value range, and connection time period. The mean data value corresponding to each of the aforementioned behavioral features is determined, and the behavioral baseline corresponding to each of the aforementioned behavioral features is determined based on the mean data value; The current data corresponding to the acquired device is compared with the behavior baseline, and the corresponding abnormality level is determined based on the comparison difference.

8. The IoT multi-protocol adaptive access method according to claim 1, characterized in that, After loading the pre-built protocol plugin and initializing the communication engine and configuration management center, the method further includes: In response to the new protocol command, upload the plugin compressed package through the configuration management center; The plugin package is then decompressed, installed, and loaded. After the plugin is successfully loaded, it listens for the interface corresponding to the new protocol to enable dynamic extension of the protocol.

9. An Internet of Things (IoT) multi-protocol adaptive access device, characterized in that, The device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to perform the method described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-8.

Images