Edge computing and protocol unified conversion method based on Internet of Things intelligent gateway

Abstract

The invention provides an edge computing and protocol unified conversion method based on an Internet of Things intelligent gateway. The method comprises the following steps: collecting data of the Internet of Things intelligent gateway; inputting the extracted protocol features into the constructed protocol recognition model for recognition; the network state and load of the Internet of Things gateway are collected in real time, a conversion strategy is dynamically adjusted based on a load balancing mechanism, equipment data characteristics are predicted through an algorithm, and resources are allocated in combination with the priority level of a conversion task; performing protocol analysis on the collected data based on the identified protocol type, extracting key fields in the original data, mapping the analyzed data into a standardized format by constructing a unified data model, and packaging the standardized data into a target protocol format according to downlink requirements for outputting; and performing encryption uplink storage on the data based on the block chain in combination with an encryption technology. A conversion strategy can be dynamically adjusted, and resource allocation is optimized; the conversion from a multi-source protocol to a standardized format is realized, and multiple target protocols can be packaged as required.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of gateway communication, in particular to an edge computing and protocol unified conversion method based on an Internet of Things intelligent gateway. BACKGROUND

[0002] In the large-scale application scenario of the Internet of Things, the existing edge computing and protocol unified conversion based on intelligent gateways face many key bottlenecks. The traditional system relies on fixed software analysis mechanism, and the multi-protocol layer-by-layer analysis leads to high conversion delay, which is difficult to meet the low latency demand of industrial control, real-time monitoring, etc. In the face of frequent increase and decrease of devices, network fluctuations and burst data transmission, there is a lack of flexible dynamic resource allocation scheme, and the traditional load balancing strategy cannot solve the resource conflict of cross-protocol devices, which is easy to cause system overload or resource waste. At the same time, the Internet of Things device protocols are highly heterogeneous, and the compatibility adaptation of the existing system is complicated, the multi-source data format is not unified, which leads to poor cross-platform interoperability, and the target protocol encapsulation method is fixed, which is difficult to match the diversified downlink demand. These problems seriously restrict the running efficiency, stability and expansibility of the system, and cannot adapt to complex and variable Internet of Things application scenarios. Therefore, it is crucial to propose a conversion method that can realize real-time perception of network state and gateway load, accurately predict the periodicity or burstiness of device data through algorithm, and dynamically adjust the resource allocation strategy combined with the conversion task priority. SUMMARY

[0003] To solve the above problems, the present application provides an edge computing and protocol unified conversion method based on an Internet of Things intelligent gateway, which can dynamically adjust the conversion strategy according to the network state and device data characteristics, optimize resource allocation, realize conversion from multi-source protocol to standardized format, and support on-demand encapsulation into multiple target protocols.

[0004] To achieve the above purpose, the technical solution adopted by the present application is: The present application provides an edge computing and protocol unified conversion method based on an Internet of Things intelligent gateway, comprising the following steps: S1: collecting data of the Internet of Things intelligent gateway and preprocessing the data, the data being service data generated by Internet of Things heterogeneous devices; S2: extracting protocol features in the data and inputting the extracted protocol features into a constructed protocol recognition model for recognition; S3: real-time collection of network state and load of the Internet of Things gateway, dynamic adjustment of conversion strategy based on load balancing mechanism, prediction of device data characteristics through algorithm, and resource allocation combined with conversion task priority level; S4: Protocol analysis is performed on the collected data based on the identified protocol type, key fields in the original data are extracted, the parsed data is mapped to a standardized format by constructing a unified data model, and the standardized data is encapsulated into a target protocol format output according to the downstream requirements; S5: Based on the blockchain combined with encryption technology, the data is encrypted and stored on the chain.

[0005] Preferably, when collecting data, multiple types of interfaces are supported for parallel access, including wired interfaces and wireless interfaces; an asynchronous IO collection mode is used, and an event-driven mechanism is used to simultaneously listen to data transmission requests of multiple interfaces; the collection interval is dynamically configured based on the device type, and manual configuration extension is supported; a local cache mechanism is set to cache collected data in a disconnected state, and an incremental upload strategy is used; after network recovery, the gateway automatically verifies the time stamps of the local cache data and the received data in the cloud, and only uploads the newly added unsynchronized data during the network outage.

[0006] Preferably, the collected raw data is preprocessed, and the preprocessing includes format standardization, exception handling, feature enhancement, and data compression, and the features include time series features and statistical features.

[0007] Preferably, the protocol features include frame structure features, coding features, timing features, and semantic features.

[0008] Preferably, a deep learning model based on CNN-LSTM is used to predict the protocol type of the standardized feature vector, including the following steps: Input a 64-dimensional feature vector into a CNN layer, and extract local features through 3 convolution kernels; Input the feature sequence output by the CNN into an LSTM layer to capture the long-term dependence of the timing features; Output the probability distribution of the model for the main protocol through a fully connected layer and a Softmax activation function; Select the protocol corresponding to the maximum probability as the preliminary identification result, and record the probability value; If the confidence is ≥0.8, directly enter the result output link; if the confidence is <0.8, trigger the rule verification process.

[0009] Preferably, when verifying and correcting the prediction result, a preset protocol feature rule library is called to match the feature vector of the low-confidence sample piece by piece; the rule matching result is input into a decision tree model to exclude rule conflicts and determine the final protocol type; the final protocol identification result is output, and the feature vector of the low-confidence sample and the corrected protocol type are used as new labeled data to supplement the model training set; the CNN-LSTM model parameters are fine-tuned periodically to improve the model identification accuracy.

[0010] Preferably, the network state and load data of the Internet of Things gateway are collected in real time to construct load evaluation basic data, and the network state data includes CPU utilization, memory occupation, network bandwidth and protocol conversion queue length.

[0011] Preferably, in combination with real-time load state, data characteristic prediction results and task priority, a hybrid mechanism combining weighted round robin and resource reservation is used to allocate CPU, memory and bandwidth resources: the gateway load is divided into three levels, including light load, medium load and high load.

[0012] Preferably, the S4 comprises the following steps: According to the protocol type output by the protocol identification model, the matched special analysis plug-in is dynamically loaded, and targeted analysis is performed; The analysis plug-in disassembles the original data and extracts the core key fields according to the frame structure and data format rules of the corresponding protocol, and the analysis logic of different protocols is differentially adapted; The key fields extracted by different protocols are mapped to the preset unified data model, eliminating the data format heterogeneity problem caused by protocol differences; Based on the downlink demand of the business scene, the standardized UDM data is encapsulated into the corresponding target protocol format.

[0013] Preferably, the S5 comprises the following steps: For the standardized data output by the protocol conversion module, a double-encryption mechanism combining transmission encryption and storage encryption is used to ensure the security of the data in the transmission and storage links; The encrypted UDM data is subjected to hash digest and digital signature to ensure data integrity and traceability; The core metadata of the data is stored on the chain by using the HyperledgerFabric alliance chain architecture, balancing security and storage efficiency; The complete original data after encryption is saved by using a combination of local storage and IPFS backup, ensuring that the data is accessible and does not depend on a single node; When the data needs to be used or audited, multi-dimensional verification is performed on the blockchain metadata and local / IPFS stored data.

[0014] The beneficial effects of the present application are: Data acquisition and preprocessing: a multi-interface parallel acquisition mechanism is designed, combined with outlier filtering, smoothing processing and feature extraction technology, to provide high-quality data input for subsequent protocol identification.

[0015] Protocol feature extraction and identification: a multi-dimensional feature system is constructed, and a hybrid identification scheme combining CNN-LSTM deep learning model and rule engine is used to realize high-accuracy automatic protocol identification.

[0016] Dynamic resource scheduling: Based on real-time load monitoring and LSTM prediction model, a priority grading scheduling mechanism is designed, which can dynamically adjust the conversion strategy according to the network state and device data characteristics, and optimize resource allocation.

[0017] Protocol conversion and unified data model: Through the plug-in parser and general data model, the conversion from multiple source protocols to standardized format is realized, and the encapsulation into multiple target protocols is supported on demand.

[0018] Blockchain secure storage: AES-256 encryption and ECC signature technology are adopted, combined with alliance chain architecture, to realize secure encryption of data on chain and traceable management. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 It is an edge computing and protocol unified conversion method flow chart based on an Internet of Things intelligent gateway. DETAILED DESCRIPTION

[0020] Please refer to Figure 1 The application relates to an edge computing and protocol unified conversion method based on an Internet of Things intelligent gateway, which comprises the following steps: S1: Collecting data of the Internet of Things intelligent gateway and preprocessing the data, wherein the data is service data generated by Internet of Things heterogeneous devices; The service data is divided into the following categories according to data types: Numerical type: physical quantity, quantitative index data generated in the process of device monitoring or operation. For example, environment type, industrial type, medical type and energy consumption type.

[0021] State type: descriptive data reflecting device running state and instruction execution result. For example, device running state, instruction response result and interface connection state.

[0022] Identification type: basic identification information for positioning data ownership and time dimension. For example, device identification, time identification and protocol identification (preliminary information related to the protocol used in communication).

[0023] Abnormal type: warning data related to device failure and abnormal event, such as fault code and alarm information (abnormal event description and alarm level).

[0024] Taking "multi-interface adaptation + adaptive adjustment + breakpoint continuation" as the core, the comprehensiveness, real-time performance and continuity of data acquisition are ensured.

[0025] Collection interface and mode configuration: support multiple types of interface access in parallel, covering wired interfaces (RS485, RS232, Gigabit Ethernet) and wireless interfaces (Wi-Fi6, Bluetooth 5.0, LoRaWAN, NB-IoT), adapting to industrial sensors, environmental monitoring devices, medical terminals and other heterogeneous Internet of Things devices. Adopt asynchronous IO (AIO) collection mode, listen to multiple interface data transmission requests at the same time through event-driven mechanism, avoid collection delay caused by single interface blocking, improve multi-device concurrent collection efficiency.

[0026] Collection frequency adaptive adjustment: based on device type, dynamically configure collection interval, for example, industrial control type sensor (such as motor vibration sensor) default 100ms / second, environmental monitoring device (such as temperature and humidity sensor) default 1s / second, log type device default 10s / second. Support manual configuration extension, users can customize collection frequency (range 10ms~60s) through gateway management platform, meet the data timeliness requirements of different scenarios.

[0027] Breakpoint resuming and data caching: set local caching mechanism, gateway built-in 64G BeMMC storage, reserve 16GB special space for caching collection data in offline state, avoid data loss. Adopt incremental upload strategy, after network recovery, gateway automatically checks the timestamp of local cache data and cloud received data, only uploads new data not synchronized during offline period, reduces bandwidth occupation.

[0028] Preprocessing operation is performed on the collected raw data, which includes format standardization, abnormality processing, feature enhancement and data compression, providing high-quality data input for subsequent protocol identification and conversion.

[0029] Format standardization conversion: unify the heterogeneous formats such as binary stream, hexadecimal string, ASCII code output by different devices into standard byte array (ByteArray), eliminate format differences. Automatically identify the encoding type of raw data (such as UTF-8, GBK, BCD code), convert it into UTF-8 encoding supported by gateway, ensure data parsing.

[0030] Abnormal value detection and processing: based on 3σ principle of abnormal filtering, calculate the mean μ and standard deviation σ of historical data, judge the data beyond the range of [μ-3σ, μ+3σ] as abnormal value (such as temperature sensor reporting 1000℃ data), directly filter out. Adopt configurable size sliding window (default 5 sampling points), calculate the mean value of continuous collection data, smooth the fluctuating data caused by sensor noise, improve data stability.

[0031] Feature enhancement extraction: extract timing features, calculate data sampling interval, data mutation rate (absolute value of the difference between two adjacent sampling values / collection interval), continuous stable duration, etc., to provide timing dimension basis for protocol identification. Calculate statistical features, calculate mean, variance, peak, valley, etc. of the data in the sliding window, enrich the feature dimension of protocol identification, and improve the identification accuracy.

[0032] Data compression optimization: use LZ77 lossless compression algorithm to compress continuous repeated data segments (such as periodically reported fixed format metadata), compression rate ≥ 30%, reduce subsequent data transmission and storage resource consumption. Encapsulate the compressed data with feature information, device identifier, and timestamp into a unified data frame for subsequent module call processing.

[0033] The final preprocessing outputs two types of data: one is the standardized raw data after cleaning and compression (used for protocol analysis and conversion); the other is the extracted multi-dimensional feature vector (64 dimensions, including frame structure, timing, statistical features, used for protocol identification model input), to ensure efficient processing of subsequent modules.

[0034] S2: extract protocol features from the data and input the extracted protocol features into the constructed protocol identification model for identification; The protocol features include frame structure features, encoding features, timing features, and semantic features.

[0035] Frame structure feature extraction: identify frame start symbol (such as Modbus protocol device address field 0x01, LoRaWAN protocol frame start symbol 0x7E), end symbol (such as ASCII protocol carriage return symbol ), record the position offset of the start symbol and the end symbol; read the length field in the protocol frame (such as the remaining length field in the MQTT fixed header, the message length field in the TCP protocol), calculate the total number of bytes of single frame data; according to the structure rule of the protocol frame, split the address segment, control segment, data segment, and verification segment, record the byte length of each field (such as the field division of "function code (1 byte) + register address (2 bytes) + data length (1 byte) + data (N bytes) + CRC verification (2 bytes)" in Modbus-RTU frame).

[0036] Encoding feature extraction: distinguish binary encoding and ASCII encoding by the proportion of printable characters in data (e.g., if the proportion of characters in the range of 0x20-0x7E in ASCII code is greater than or equal to 80%, it is determined as ASCII encoding), special symbol format (e.g., the symbols of “{” “}” “:” in JSON protocol); detect whether the frame tail has CRC16 / CRC32 check code (verified by polynomial calculation), MD5 / SHA hash value (verified by hash length matching), and record the position and length of the check field (e.g., the Modbus-RTU frame tail is fixed at 2 bytes as CRC16 check code).

[0037] Timing feature extraction: based on the timestamp collected by the gateway, calculate the time difference of two consecutive frames, take the average value of 5 intervals as the “average interval of data packet” feature (e.g., the data packet interval of industrial equipment Modbus protocol is usually 100-500 ms, and the interval of LoRaWAN protocol is usually 1-10 s due to low power consumption characteristics); record the interaction mode of the device and the gateway (e.g., “request-response” mode: the device returns data after the gateway sends a query instruction, commonly used in Modbus, OPCUA protocol; “active reporting” mode: the device does not need to request and directly sends data periodically, commonly used in LoRaWAN, NB-IoT protocol), and count the number of requests and responses per unit time.

[0038] Semantic feature extraction: extract semantic fields with protocol identification from data frames (e.g., the “topic” field in MQTT protocol, the “GET / POST” request method field in HTTP protocol, the “MSH” message header field in HL7 medical protocol), record the key characters and format of the field (e.g., the topic field of MQTT is separated by “ / ”); detect whether the data segment conforms to the semantic format of a specific protocol (e.g., the “key-value pair” structure of JSON format, the “<tag> content < / tag>” structure of XML format, the “register address-value” mapping relationship in industrial protocol).

[0039] Convert the extracted multi-dimensional features into standardized feature vectors (fixed at 64 dimensions) that can be input into the model, eliminating the differences in feature dimensions and the influence of dimensions: Feature quantization: numerical mapping for non-numeric features (e.g., encoding type: ASCII encoding is recorded as 1, binary encoding is recorded as 0; communication mode: request-response mode is recorded as 1, active reporting mode is recorded as 0); normalize numeric features (e.g., data packet interval, frame length) by mapping the feature values to the [0, 1] interval through the formula; Feature completion and screening: If a certain type of feature is missing in the current data (e.g., some protocols do not have a clear end-of-frame marker), fill it with the mean value of the same type of protocol; screen out the core features that contribute ≥0.8 to protocol identification (based on feature importance analysis of historical labeled data), and eliminate redundant features (e.g., repeated check field length features); Vector assembly: assemble into a 64-dimensional feature vector in the fixed order of "frame structure features (20-dimensional) + encoding features (10-dimensional) + timing features (14-dimensional) + semantic features (20-dimensional)", as the input data of the protocol identification model.

[0040] Use a deep learning model based on CNN-LSTM to predict the protocol type of the standardized feature vector, including the following steps: Model input and feature extraction: input the 64-dimensional feature vector into the CNN (Convolutional Neural Network) layer, extract local features (such as the association features of frame start symbol and check field) through 3 convolution kernels (sizes are 3x1, 5x1, 7x1); then input the feature sequence output by CNN into the LSTM (Long Short-Term Memory Network) layer to capture the long-term dependence of timing features (such as the periodicity of packet interval); Probability distribution output: output the probability distribution of 20+ mainstream protocols (such as Modbus, LoRaWAN, MQTT, OPCUA, Zigbee, etc.) through the fully connected layer and Softmax activation function (such as Modbus protocol probability 0.92, LoRaWAN protocol probability 0.05, and the sum of other protocol probabilities 0.03); Preliminary protocol determination: select the protocol corresponding to the maximum probability as the preliminary identification result, and record the probability value (called "confidence level"); if the confidence level ≥0.8, directly enter the result output link; if the confidence level <0.8, trigger the subsequent rule checking process.

[0041] Through the pre-set protocol feature rule base and decision tree, the low confidence level result of the model is corrected to ensure the identification accuracy: Rule base matching: call the pre-set protocol feature rule base (including the "key feature-protocol type" mapping rules of each protocol) to match the feature vector of the low confidence level sample one by one. For example: Rule 1: if the feature vector has "frame start symbol = 0x7E" and "communication mode = active reporting", it is determined as LoRaWAN protocol; Rule 2: if the feature vector has "semantic field contains 'topic'" and "encoding type = ASCII", it is determined as MQTT protocol; Rule 3: if the feature vector has "frame structure contains 'function code field'" and "check method = CRC16", it is determined as Modbus protocol.

[0042] Decision Tree Verification: The rule matching results are input into the decision tree model (trained based on 100,000+ labeled samples), which determines the final protocol type through multiple rounds of conditional judgments (such as "whether there is an 'MSH' message header → whether it is an HL7 protocol; whether there is a'register address field' → whether it is an industrial bus protocol") and rule conflict elimination (such as the case of simultaneously matching Modbus and Profinet protocols).

[0043] Result Output and Model Optimization: Output the final protocol identification results (such as "Modbus-RTU protocol" "MQTT protocol"); at the same time, the feature vectors of low confidence samples and the corrected protocol types are used as new labeled data to supplement the model training set, and the CNN-LSTM model parameters are fine-tuned regularly to improve the model recognition accuracy.

[0044] S3: Real-time collection of network status and load of Internet of Things gateway, dynamic adjustment of conversion strategy based on load balancing mechanism, prediction of device data characteristics through algorithm, and allocation of resources combined with conversion task priority level; Real-time collection of network status and load data of Internet of Things gateway, construction of load evaluation basic data, the network status data includes CPU utilization, memory occupation, network bandwidth and protocol conversion queue length.

[0045] Train LSTM time series prediction model based on historical data to predict the transmission characteristics (periodicity / burstiness) of device data in the next 5 minutes, provide basis for resource reservation, including the following steps: Extract 3 types of key features of device historical data to form prediction model input vector, including historical data transmission volume (collect device data packet quantity and total byte number every 1 minute in the past 10 minutes), timestamp feature (extract time information of data collection), and device type label (assign classification label according to device function).

[0046] Use the architecture of "input layer (128-dimensional features) → LSTM layer (64 neurons) → Dropout layer (to prevent overfitting) → fully connected layer → output layer", the output is "periodicity probability" and "burstiness probability" (the sum of the two is 1). Input the real-time collected device features into the trained LSTM model, if "periodicity probability ≥ 0.8", determine that the future data is periodic transmission (such as temperature and humidity sensor reporting every 1s); if "burstiness probability ≥ 0.7", determine that the future data is burst transmission (such as alarm data batch reporting when device fails). If the prediction is burst data, reserve 20% of the CPU and memory resources of the gateway in advance to avoid load overload caused by burst tasks.

[0047] According to the business importance and real-time requirement of the protocol conversion task, all tasks to be processed are divided into four priority levels, and the resource allocation weight is determined: P0 (emergency, weight 4): industrial control instructions (such as PLC device start / stop instructions), device alarm information (such as temperature threshold alarm), requiring response delay ≤10ms; P1 (high, weight 2): real-time sensor data (such as medical device heart rate data, industrial motor vibration data), requiring response delay ≤50ms; P2 (medium, weight 1): device periodic state reporting (such as device firmware version detection once a day), allowing response delay ≤1s; P3 (low, weight 0.5): log data (such as gateway running log), historical data statistics (such as monthly data report), no strict real-time requirement, can be delayed processing.

[0048] When the gateway receives the conversion task, it automatically marks the priority label according to the task source (such as industrial control terminal, ordinary sensor, log module), for example, the task from industrial PLC is marked as P0; the task from LoRa temperature and humidity sensor is marked as P1; the task from gateway system log module is marked as P3.

[0049] Combined with real-time load state, data characteristic prediction result and task priority, a hybrid mechanism of "weighted round robin + resource reservation" is used to allocate CPU, memory and bandwidth resources: The gateway load is divided into three levels, including light load (CPU ≤50%, memory ≤60%, queue length ≤300), medium load (CPU 50%-80%, memory 60%-85%, queue length 300-1000) and high load (CPU >80%, memory >85%, queue length >1000).

[0050] Light load scenario: allocate resources according to task priority weighted round robin (P0 task gets 4 resources, P1 gets 2, P2 gets 1, P3 gets 0.5), ensure all tasks can be processed in real time; Medium load scenario: priority guarantee P0, P1 task resource demand (allocate 70% resource), the remaining 30% resource is allocated to P2, P3 task according to weight; High load scenario: suspend P3 task resource allocation, store P3 task in local cache (maximum cache amount 100,000), delay processing after load decreases; at the same time, compress P2 task resource proportion (reduce to 10%), fully guarantee P0, P1 task real-time processing; Sudden data response: if step two predicts sudden data, an additional 20% resource is reserved based on the current resource allocation (adjusted from P2 and P3 task resources), ensuring that there is no need to wait when sudden tasks arrive.

[0051] S4: Based on the identified protocol type, the collected data is parsed, the key fields in the original data are extracted, the parsed data is mapped to a standardized format by constructing a unified data model, and the standardized data is encapsulated into the target protocol format according to the downlink demand and output. S4 includes the following steps: According to the protocol type output by the protocol identification model, the matching special parsing plug-in is dynamically loaded and executed for targeted parsing. The gateway has a built-in plug-in management library, which pre-stores special parsing plug-ins developed in C++ for each supported protocol (20+ mainstream protocols). The plug-in and the protocol type are associated through a "protocol identification-plug-in path" mapping table (such as "Modbus-RTU→ / plugin / modbus_rtu_parser.so" "LoRaWAN→ / plugin / lora_parser.so"). When the protocol type is identified, the plug-in path is located through the mapping table, and the dynamic link library interface is called to load the parsing plug-in, avoiding hard-coded coupling.

[0052] The standardized original data (byte array format) processed in step S1 is input into the parsing plug-in, and the device basic information (such as device ID, interface type) is also transmitted. The parsing plug-in initializes the parsing environment (such as setting the CRC polynomial of Modbus and the spreading factor parameters of LoRaWAN), ensuring that the parsing rules match the actual communication parameters of the device.

[0053] The parsing plug-in disassembles the original data and extracts the core key fields according to the frame structure and data format rules of the corresponding protocol, and different protocols are adapted differently. Frame structure disassembly: For industrial bus protocols such as Modbus-RTU, the frame structure is disassembled according to "device address (1 byte) + function code (1 byte) + register address (2 bytes) + data length (1 byte) + data segment (N bytes) + CRC check (2 bytes)". First, verify the CRC check code (if the check fails, discard the data and record the exception), then extract the data segment content. For wireless protocols such as LoRaWAN, disassemble the structure according to "preamble + synchronization word + physical layer header + MAC header + MAC payload + MIC check". After verifying the MIC check value, extract the application data from the MAC payload. For application layer protocols such as MQTT, disassemble the structure according to "fixed header (2 bytes) + remaining length (1-4 bytes) + variable header (topic field, etc.) + payload (data content)". Extract the topic field and payload data.

[0054] For different protocol data formats, extract key fields that reflect device status and business needs. Core fields include but are not limited to: Numerical: temperature, humidity, pressure, current, voltage, and other physical quantity values (e.g., 16-bit binary value 0x0A3F stored in Modbus register converted to actual temperature 26.2°C); State: device running status (e.g., "running / stop" "normal / fault"), instruction execution result (e.g., "success / failure"); Identification: device unique ID, data collection timestamp, protocol version number; Exception: fault code, alarm level (e.g., "low battery" alarm code reported by LoRaWAN device).

[0055] Map the key fields extracted from different protocol analysis to the pre-set unified data model (UDM), eliminating data format heterogeneity caused by protocol differences; UDM uses JSON format as the standard carrier, containing 4 core levels, with fixed and extensible field definitions. The parsing plug-in has a built-in "protocol key field-UDM field" mapping table, which fills the extracted key fields into the corresponding UDM positions according to the rules. Device ID, timestamp, source protocol type, and core data indicators (metric / value) are mandatory fields that must be extracted and assigned from the parsing results (e.g., match the Modbus device address with the pre-set device ID association table to fill the "device_id" field). Optional fields such as physical units, data quality, and metadata are filled if the corresponding information exists in the parsing results (e.g., LoRaWAN signal strength field mapped to UDM "signal_strength"), or left blank or use default values (e.g., data quality default 90) if they do not exist. Perform uniform processing on numerical formats to ensure consistency in UDM data formats.

[0056] Based on the downlink demand of the business scene, the standardized UDM data is encapsulated into the corresponding target protocol format.

[0057] The gateway obtains the downlink target protocol type of the current data through a configuration file or cloud instructions, and supports target protocols including cloud communication protocols (MQTT, HTTP / HTTPS, CoAP), industrial control protocols (Profinet, EtherCAT, Modbus-TCP), database storage protocols (InfluxDB Line Protocol (time series database), MySQL SQL statement), and local interaction protocols (WebSocket (for local management platform calling)).

[0058] According to the format specifications of different target protocols, the UDM data is converted into the data packet structure of the corresponding protocol. According to the target protocol type, the corresponding communication interface or storage link is selected (such as MQTT sending through Wi-Fi / ethernet, Profinet sending through industrial Ethernet, and InfluxDB writing through a local network), and the link state is verified before sending (such as whether the MQTT connection is normal and whether the industrial bus is online). If the link is abnormal, the encapsulated data is temporarily stored in the local cache, and incremental sending is performed after the link is restored to ensure that the data is not lost.

[0059] S5: Based on the blockchain combined with encryption technology, the data is encrypted and stored on the chain.

[0060] S5 includes the following steps: For the standardized data (Unified Data Model UDM format) output by the protocol conversion module, a "transmission encryption + storage encryption" double encryption mechanism is adopted to ensure the security of the data in the transmission and storage links; Transmission encryption (TLS 1.3 protocol): If the data needs to be transmitted to the cloud or other edge nodes, an encrypted communication channel is first established through the TLS 1.3 protocol. The gateway acts as a client and performs TLS handshake with the cloud / target node to exchange encryption algorithm suites (default selection of TLS_AES_256_GCM_SHA384); Based on the Elliptic Curve Key Exchange Algorithm (ECDH), a session key is generated for real-time encryption of subsequent data transmission; During transmission, the UDM data is segmented and encrypted (each segment is up to 16KB), and a message authentication code (GCM mode) is added to prevent data tampering or eavesdropping.

[0061] Storage encryption (AES-256+ECC hybrid encryption): For UDM data that needs to be stored locally or before being stored on the chain, hybrid encryption operation is performed.

[0062] Symmetric encryption (AES-256): The gateway's local security chip (such as the national SM4 encryption chip) generates an AES-256 symmetric key to encrypt the complete UDM data (JSON format), generating encrypted binary data (encryption mode is CBC, and the initial vector IV is randomly generated and stored with the ciphertext). Asymmetric encryption (ECC secp256r1): The ECC private key of the gateway (pre-stored in the security chip and cannot be derived) is used to encrypt the AES-256 symmetric key, generating a key ciphertext; the final stored / transmitted data contains "UDM ciphertext + ECC encrypted AES key + IV" three parts, ensuring that only authorized parties (holding the corresponding public key) can decrypt.

[0063] Hash digest and digital signature are performed on the encrypted UDM data to ensure data integrity and traceability of ownership; The encrypted UDM ciphertext is extracted, and a fixed length (256 bits) hash value is calculated using the SHA-256 hashing algorithm, which uniquely corresponds to the original UDM data (if the original data is tampered with, the hash value will be completely different), serving as the core basis for data integrity verification. The gateway calls the ECC private key in the security chip to digitally sign the above SHA-256 hash value, generating a signature data (format is ASN.1 encoding); the signature process is executed entirely within the security chip, and the private key is not exposed to the operating system level, avoiding the risk of private key leakage.

[0064] Hyperledger Fabric consortium chain architecture is adopted to store the core metadata of data on the chain, balancing security and storage efficiency; The metadata structure required for building a blockchain transaction includes the following core fields: tx_id (transaction unique identifier based on UUID), device_id (unique ID of the device to which the data belongs, taken from the device_id field of UDM), timestamp (data collection timestamp, taken from the timestamp field of UDM), data_hash (SHA-256 hash value of UDM data), signature (ECC digital signature of the hash value), gateway_id (unique identifier of the gateway generating the data, pre-registered in the consortium chain), storage_addr (storage address of the original encrypted data).

[0065] The gateway connects the blockchain network through the SDK of the consortium chain node, initiates a "data chaining" transaction request, calls the recordData function in the preset smart contract (chain code), and transmits the assembled metadata into the smart contract. The endorsement node in the consortium chain verifies the transaction (verifies whether the gateway identity has been registered and whether the signature is valid), generates a signature after verification, and the ordering node sorts the transaction, packages it into a block, and submits it to the accounting node, completes the block writing and account synchronization, and the on-chain process delay is ≤200 ms.

[0066] The encrypted complete original data is saved in a combination of local storage and IPFS backup, ensuring that the data is accessible and does not depend on a single node. Local storage: Store "UDM ciphertext + ECC encrypted AES key + IV" in the gateway's built-in 64G BeMMC or extended SSD, and store it in the directory structure of "device ID / date / timestamp" for easy retrieval in the future. At the same time, record the storage path and associated blockchain tx_id to establish a mapping relationship between local data and on-chain metadata.

[0067] IPFS distributed storage: If the data volume is large or needs to be shared across nodes, upload the encrypted original data to IPFS (InterPlanetary File System), and the gateway adds the data to the IPFS network through the IPFS client to obtain a unique IPFS file hash (CID). Update the CID to the storage_addr field of the blockchain metadata (through the updateStorageAddr function of the smart contract), and associate the on-chain metadata with the IPFS distributed storage data. In the future, you can get the original encrypted data from the IPFS network through the CID.

[0068] When data needs to be used or audited, multi-dimensional verification is performed on the blockchain metadata and local / IPFS storage data.

[0069] Integrity verification: Obtain the encrypted original data from local / IPFS, recalculate the SHA-256 hash value, query the metadata of the corresponding tx_id from the blockchain, extract the data_hash stored on the chain, and compare the recalculated hash value with the data_hash on the chain. If they are consistent, the data has not been tampered with, otherwise the data is invalid.

[0070] Realness and ownership verification: Extract the signature (gateway signature) and gateway_id from the blockchain metadata, obtain the ECC public key corresponding to the gateway_id through the consortium chain node (the gateway has uploaded it to the chain during registration), decrypt the signature using the public key to obtain the decrypted hash value, and compare it with the data_hash on the chain. If they are consistent, it proves that the data is generated by the gateway and is real and valid.

[0071] Trace query: Through the queryData function of the smart contract, support retrieval according to device_id (query all historical data of a certain device), timestamp (query data in a certain time period), gateway_id (query data generated by a certain gateway) and other conditions; The retrieval result contains blockchain metadata and storage_addr, which can be used to further obtain and decrypt the original encrypted data, and at the same time the smart contract will record the initiator and timestamp of each query operation to form a complete audit tracking log.

[0072] The above embodiments only describe the preferred embodiments of the present application, and do not limit the scope of the present application. Without departing from the design spirit of the present application, various modifications and improvements to the technical solutions of the present application made by ordinary engineering technicians in the art shall fall within the protection scope determined by the claims of the present application.

Claims

1. A method for edge computing and unified protocol conversion based on an IoT smart gateway, characterized in that, Includes the following steps: S1: Collect data from the IoT smart gateway and preprocess the data, wherein the data is business data generated by IoT heterogeneous devices; S2: Extract protocol features from the data and input the extracted protocol features into the constructed protocol recognition model for recognition; S3: Real-time collection of network status and load of IoT gateways, dynamic adjustment of conversion strategies based on load balancing mechanisms, prediction of device data characteristics through algorithms, and allocation of resources based on conversion task priority levels; S4: Based on the identified protocol type, the collected data is parsed to extract key fields from the raw data. A unified data model is constructed to map the parsed data into a standardized format. The standardized data is then encapsulated into the target protocol format for output according to downlink requirements. S5: Based on blockchain and encryption technology, data is encrypted and stored on the blockchain.

2. The edge computing and protocol unification conversion method based on an IoT smart gateway according to claim 1, characterized in that, When collecting data, it supports parallel access from multiple types of interfaces, including wired and wireless interfaces; it adopts an asynchronous IO acquisition mode, listening to data transmission requests from multiple interfaces simultaneously through an event-driven mechanism; it dynamically configures the acquisition interval based on device type and supports manual configuration for expansion; it has a local caching mechanism to cache data collected during network outages, and adopts an incremental upload strategy. After the network is restored, the gateway automatically verifies the timestamps of the locally cached data and the data already received in the cloud, and only uploads the unsynchronized data added during the network outage.

3. The edge computing and protocol unified conversion method based on an IoT smart gateway according to claim 1, characterized in that, The collected raw data is preprocessed, including format standardization, anomaly handling, feature enhancement, and data compression. The features include time-series features and statistical features.

4. The edge computing and protocol unification conversion method based on an IoT smart gateway according to claim 1, characterized in that, The protocol features include frame structure features, coding features, timing features, and semantic features.

5. The edge computing and protocol unification conversion method based on an IoT smart gateway according to claim 1, characterized in that, The protocol type prediction is performed on the normalized feature vectors using a deep learning model based on CNN-LSTM, including the following steps: The 64-dimensional feature vector is input into the CNN layer, and local features are extracted through three convolutional kernels; The feature sequences output by the CNN are input into the LSTM layer to capture the long-term dependencies of temporal features; By using a fully connected layer and the Softmax activation function, the probability distribution of the output model for mainstream protocols is obtained. The protocol corresponding to the highest probability is selected as the preliminary identification result, and the probability value is recorded. If the confidence level is ≥0.8, proceed directly to the result output stage; if the confidence level is <0.8, trigger the rule validation process.

6. The edge computing and protocol unified conversion method based on an IoT smart gateway according to claim 5, characterized in that, When verifying and correcting the prediction results, the preset protocol feature rule library is called to match the feature vectors of low-confidence samples one by one; the rule matching results are input into the decision tree model to eliminate rule conflicts and determine the final protocol type; the final protocol recognition result is output, and the feature vectors of low-confidence samples and the corrected protocol type are used as new labeled data to supplement the model training set. The parameters of the CNN-LSTM model are fine-tuned periodically to improve the model recognition accuracy.

7. The edge computing and protocol unification conversion method based on an IoT smart gateway according to claim 1, characterized in that, Real-time collection of network status and load data from IoT gateways is used to construct basic data for load assessment. The network status data includes CPU utilization, memory usage, network bandwidth, and protocol conversion queue length.

8. The edge computing and protocol unified conversion method based on an IoT smart gateway according to claim 1, characterized in that, By combining real-time load status, data characteristic prediction results and task priorities, a hybrid mechanism combining weighted round-robin and resource reservation is adopted to allocate CPU, memory and bandwidth resources, and the gateway load is divided into three levels: light load, medium load and high load.

9. The edge computing and protocol unified conversion method based on an IoT smart gateway according to claim 1, characterized in that, S4 includes the following steps: Based on the protocol type output by the protocol identification model, dynamically load the matching dedicated parsing plugin and perform targeted parsing; The parsing plugin breaks down the raw data and extracts the core key fields according to the frame structure and data format rules of the corresponding protocol, and adapts the parsing logic to the differences of different protocols. Key fields extracted from different protocols are mapped to a pre-defined unified data model to eliminate data format heterogeneity issues caused by protocol differences. Based on the downlink requirements of business scenarios, standardized UDM data is encapsulated into the corresponding target protocol format.

10. The edge computing and protocol unified conversion method based on an IoT smart gateway according to claim 1, characterized in that, S5 includes the following steps: For the standardized data output by the protocol conversion module, a two-layer encryption mechanism combining transmission encryption and storage encryption is adopted to ensure the security of data during transmission and storage. Hash digests and digital signatures are applied to the encrypted UDM data to ensure data integrity and traceability of ownership. The Hyperledger Fabric consortium blockchain architecture is adopted to store the core metadata of the data on the blockchain, balancing security and storage efficiency. The encrypted, complete original data is stored using a combination of local storage and IPFS backup to ensure that the data is accessible and does not depend on a single node. When data needs to be used or audited, multi-dimensional verification is performed using blockchain metadata and local / IPFS stored data.

Images