Internet of Things gateway collaborative management system based on edge computing

Abstract

The invention belongs to the technical field of edge computing, and discloses an Internet of Things gateway collaborative management system based on edge computing, which comprises a resource virtualization unit used for deploying a protocol independence abstract engine in a gateway cluster, analyzing and adapting various Internet of Things protocols, constructing a proprietary protocol conversion matrix, obtaining standardized equipment attribute data, and storing the standardized equipment attribute data in a server; establishing an equipment shadow model based on the standardized equipment attribute data; the edge collaborative scheduling unit is used for outputting panoramic state data through the equipment shadow model, abstracting the gateway cluster into a tough topology directed graph based on the panoramic state data by adopting an edge computing task scheduling algorithm, and coordinating the gateway cluster; the intelligent load balancing unit is used for monitoring the gateway cluster calculation load and the network transmission load at the same time, and predicting the load imbalance rate according to the gateway cluster calculation load and the network transmission load; the efficient, flexible and intelligent cooperative management of the Internet of Things gateway cluster is realized.

Description

Technical Field

[0001] The present invention relates to the field of edge computing technology, and more specifically, to an Internet of Things gateway collaborative management system based on edge computing. Background Art

[0002] The patent with patent publication number CN115631636A discloses an Internet of Things data fusion and collaborative control management system based on an edge computing gateway, which relates to the field of edge computing technology. A data collection module is set up to monitor in real time the violations of running red lights and speeding in road traffic; and the monitoring screen is saved in the edge data storage module in each area; an edge data processing module is set up to identify the human feature data and vehicle feature data in the violations; a regional data storage module is set up to pre-save the identity information and vehicle information of the city’s permanent residents; a regional data query module is set up to query the real identity of the person corresponding to the human feature data and vehicle feature data in the city or across cities; and the problem of slow processing speed caused by the huge amount of traffic violation data processing is solved.

[0003] The existing IoT gateway collaborative management system has the following main problems: Due to the dynamic state of gateway nodes, network conditions, and the frequency of failures, the coordination and management between gateways in the existing technology becomes complicated. Especially in the case of large-scale gateway clusters, it is difficult to effectively adjust the network topology to adapt to the actual operating environment. When there are a large number of gateways, their states, network conditions, and fault information are difficult to manage in a unified manner, especially when the system becomes larger, coordination becomes very troublesome. Many existing solutions fail to fully consider the resilience of the network, especially when faced with equipment failures, network fluctuations, etc., and cannot be optimized and adjusted in time, resulting in poor system stability and reliability. Most systems do not take resilience into account, which means that when the system faces equipment failures, network delays or other problems, it cannot make timely adjustments, resulting in poor system stability. Existing technologies are often static and cannot adjust network topology in real time according to dynamic factors such as node status, network traffic, and fault information. Many existing solutions are fixed and cannot adjust the layout of gateways according to changes in equipment or network status, resulting in inflexible systems. The gateway node evaluation methods used in many solutions are too simple and lack comprehensive indicators such as the node's historical failure rate and task execution stability, resulting in inaccurate evaluation results, which in turn affects the overall coordination and management of gateways. When evaluating gateways, many solutions simply look at whether the nodes are healthy, but do not consider other key factors such as the node's historical failure rate and task execution stability, which makes the accuracy of gateway evaluation relatively low. Many existing methods rely on a single gateway node to evaluate its own effectiveness, which may affect the judgment of the entire system due to local failures or false alarms. Some solutions only consider the historical failure rate of the node or the stability of task execution, but lack comprehensive evaluation and cannot judge the reliability of the node in an all-round way. If there is a large deviation in the effectiveness score reported by a gateway node, traditional methods may not be able to detect the unreliability of the node in time, resulting in abnormal nodes in the network cannot be identified and eliminated in time. Many existing methods do not consider the dynamic changes of nodes, and lack an effective mechanism to deal with the reliability differences between nodes, resulting in some unstable gateways still being considered valid nodes.

[0004] In view of this, the present invention proposes an IoT gateway collaborative management system based on edge computing to solve the above problems. Summary of the invention

[0005] In order to overcome the above-mentioned defects of the prior art and to achieve the above-mentioned purpose, the present invention provides the following technical solution: an IoT gateway collaborative management system based on edge computing, comprising: Resource virtualization unit, used to deploy protocol-independent abstraction engines in gateway clusters, parse and adapt multiple IoT protocols, build proprietary protocol conversion matrices, obtain standardized device attribute data, and build device shadow models based on standardized device attribute data; The edge collaborative scheduling unit outputs panoramic status data through the device shadow model, adopts the edge computing task scheduling algorithm, abstracts the gateway cluster into a resilient topology directed graph based on the panoramic status data, and coordinates the gateway cluster; An intelligent load balancing unit, which is used to monitor the gateway cluster computing load and the network transmission load at the same time, and predict the load imbalance rate according to the gateway cluster computing load and the network transmission load; The gateway topology management unit presets a load imbalance rate threshold. If the load imbalance rate reaches the preset load imbalance rate threshold, the elastic load transfer algorithm is used to smoothly transfer the load, automatically reconfigure the gateway connection, and balance the load of each gateway; The operation and maintenance interaction management unit, based on the vue.js framework, provides a cross-platform gateway management interface and supports access and interaction from mobile and PC terminals.

[0006] Preferably, the method for parsing and adapting multiple IoT protocols includes: Deploy a protocol-independent abstract engine in the gateway cluster and integrate multiple IoT protocol adapter modules inside the protocol-independent abstract engine; A plug-in architecture is used to assist the integration of IoT protocol adapter modules. When a device is connected to the gateway, the gateway automatically identifies the IoT protocol to which the device belongs, and calls the corresponding IoT protocol adapter module to decode the original data packets of different protocols and extract the device attribute data of different protocols. Construct a protocol conversion layer. After parsing is completed, the parsed device attribute data of different protocols are input into the protocol conversion layer, converted into a standardized unified data format, and standardized device attribute data is obtained and stored in a preset standardized device attribute database; the standardized device attribute data includes device identification data, data acquisition timestamp, device data value, device status data, device location data and device configuration data; Deploy a proprietary protocol conversion matrix to store data formats and parameter conversion rules between different protocols. Parameter conversion rules include data unit conversion, data type conversion, data format conversion, command mapping, and data range adjustment. Use a dynamic loading mechanism to subsequently add or adjust parameter conversion rules. Through the proprietary protocol conversion matrix, map standardized device attribute data to different IoT protocols.

[0007] Preferably, the method of subsequently adding or adjusting parameter conversion rules using a dynamic loading mechanism includes: Continuously monitor the update of parameter conversion rules. When the parameter conversion rules are updated, the gateway management interface sends a notification and automatically triggers the reloading of the parameter conversion rules. When the new parameter conversion rules are loaded, the IoT protocol adapter module automatically performs format check and compatibility verification, and applies the new parameter conversion rules. When the parsed device attribute data of different protocols enters the protocol conversion layer, the system converts the data according to the latest parameter conversion rules. The system stores and manages historical parameter conversion rules every n periods of time. When any new parameter conversion rule is abnormal, it automatically rolls back to the historical parameter conversion rule version.

[0008] Preferably, the method for acquiring the device shadow model includes: Create a device shadow model for each device. The device shadow model includes three core modules, including the state storage layer, metadata layer and synchronization control layer. The state storage layer stores the latest state of the device, the metadata layer stores the static data of the device, and the synchronization control layer realizes two-way state synchronization between the device and the device shadow. The device reports the state to update the shadow, and the gateway management interface issues cloud commands, which are sent to the device through the device shadow. When the device reports its status, the device shadow model updates the reported field and records the timestamp. The cloud modifies the desired field through the gateway management interface and issues an instruction, which is converted into the protocol format supported by the device through the IoT protocol adapter module. The device shadow model achieves two-way status synchronization through reported and desired. When the device status is inconsistent with the cloud instruction, the system adopts a strategy to make adjustments, and the device status with the latest timestamp is used by default. If the device is offline, the desired status modified in the cloud will be temporarily stored in the device shadow model, and will be automatically synchronized and executed after the device is reconnected. A RESTful API interface is provided to query the device status in real time. When a new device is connected, a new device shadow model is automatically created. The device shadow model is used as the data source of the digital twin to output panoramic status data.

[0009] Preferably, the panoramic status data includes equipment static data, dynamic operation status data, protocol context data and health score data.

[0010] Preferably, the method of abstracting the gateway cluster into a resilient topology directed graph based on the panoramic status data and coordinating the gateway cluster includes: Obtain the panoramic status data output by the device shadow model of each gateway, and build a gateway node set and a gateway node attribute table based on the panoramic status data. The device static data, dynamic operation status data, protocol context data and health risk indicator data of each gateway node are recorded through the gateway node attribute table; according to the node attribute table, each gateway node is connected through weighted directed edges to generate an initial topology directed graph. The circles of the directed edges of the initial topology directed graph are automatically adjusted based on the transmission delay, bandwidth utilization and health score data between nodes; introduce a resilience coefficient calculation model, and calculate the resilience coefficient of each gateway node based on the initial topology directed graph. The resilience coefficient is obtained by weighted comprehensive evaluation of gateway node redundancy, number of critical paths and load balancing capability; The calculation of gateway node redundancy is based on the gateway node connection redundancy ratio of the initial topology directed graph. The gateway node redundancy is calculated by evaluating the number of alternative paths for each gateway node and the effectiveness of the gateway node. The number of alternative paths for the gateway node is traversed through the initial topology directed graph through a breadth-first search to find all paths in the initial topology directed graph that meet the preset alternative path screening rules, and define them as gateway node alternative paths. The preset alternative path screening rules include three screening threshold rules, and the three screening threshold rules include that the alternative path transmission delay is less than the preset alternative path transmission delay threshold, the bandwidth utilization is less than the preset bandwidth utilization threshold, and the health score is greater than or equal to the preset health score threshold. The judgment of the critical path is based on the minimum cut theory. By calculating the maximum gateway traffic path of the initial topology directed graph and analyzing the minimum cut contribution value of each gateway node in the path transmission, the path with the greatest impact on the connectivity of the initial topology directed graph is selected as the critical path; the evaluation of load balancing capability is based on the computing load and network traffic distribution between gateway nodes, and a discrete load balancing factor is used to measure the load balancing degree of the topology structure; The initial topology directed graph is optimized and adjusted according to the resilience coefficient, and a threshold for the number of critical paths is preset. When the number of screened critical paths reaches the preset threshold, the screening is stopped and redundant connections of gateway nodes are automatically added to finally obtain a resilient topology directed graph.

[0011] Preferably, the method for obtaining the validity of the gateway node includes: The effectiveness of the gateway node is calculated by the historical failure rate and task execution stability of the gateway node. The historical failure times F and the total running time U of any gateway node within the preset time T are recorded. The historical failure times F within the preset time T are divided by the total running time U to obtain the historical failure rate H. Count the total number of tasks C completed and the number of failed tasks Ft of any gateway node within the preset time T, and divide the difference between the total number of tasks C completed within the preset time T and the number of failed tasks Ft by the total number of completed tasks C to obtain the task execution stability S; combine the historical failure rate H and the task execution stability S to obtain the gateway node effectiveness V=a1∙(1-H)+a2∙S; where a1 represents the historical failure rate weight factor; a2 represents the task execution stability weight factor; The introduction of a distributed consensus mechanism enables gateways to verify each other's reliability and obtain the final gateway node validity.

[0012] Preferably, the method for obtaining the final gateway node validity includes: It is assumed that each gateway node reports its own historical failure rate H and task execution stability S every m periods of time, and preliminarily calculates the self-effectiveness score of each gateway node. However, it is stipulated that it is not directly submitted to the central gateway node, but cross-validated with each gateway node's own subordinate gateway node; the self-effectiveness score of each gateway node is Vci=a1∙(1-Hi)+a2∙Si; where Vci represents the self-effectiveness score of the i-th gateway node; Hi represents the historical failure rate of the i-th gateway node; Si represents the task execution stability of the i-th gateway node; i represents the index of the node; Gateway node i selects M subordinate gateway nodes (such as the nearest 3 to 5 on the initial topology directed graph), and sends its own effectiveness score to the subordinate gateway nodes through the Gossip protocol transmission. The other M subordinate gateway nodes respectively calculate the actual failure rate of gateway node i. The method for obtaining the actual failure rate includes: recording the number of failures Fi observed by the subordinate gateway node and the duration Ui of the observation of the subordinate gateway node, dividing the number of failures Fi observed by the subordinate gateway node by the duration Ui of the observation of the subordinate gateway node to obtain the actual failure rate Gi; combining the actual failure rate with the task execution stability Qi of gateway node i observed by the subordinate gateway node to obtain the actual gateway node effectiveness Ki=a1∙(1-Gi)+a2∙Qi; The actual gateway node validity Ki calculated by all slave gateway nodes is voted, and the value closest to the median is taken as the transition actual gateway node validity Ji; through the RAFT consensus mechanism, a leader gateway node and the corresponding slave gateway node are elected, and the validity score of each gateway node is added to the sum of the validity scores reported to the leader gateway node by all slave gateway nodes, and then divided by the total number of gateways to obtain the final global consistent validity score; A preset reporting validity score deviation threshold is set. If it is found that the deviation between the validity score reported by any gateway node and the validity score reported by the subordinate gateway node is greater than or equal to the preset reporting validity score deviation threshold, the gateway node is marked as a suspicious gateway node, and the credibility factor bi of the suspicious gateway node is calculated; A credibility factor threshold is preset. If the credibility factor of any gateway node is less than the preset credibility factor threshold, the validity score reported by the gateway node is ignored. By introducing consensus weight and credibility factor, the final gateway node validity is obtained.

[0013] Preferably, the method for predicting the load imbalance rate includes: Train the load imbalance rate prediction model. The input data of the model is the historical monitoring gateway cluster computing load and network transmission load, and the output label of the model is the load imbalance rate. The load imbalance rate prediction model is a ridge regression model. Define the loss function of the model and use the mean square error loss function to measure the difference between the predicted load imbalance rate and the actual load imbalance rate. Use the trained load imbalance rate prediction model to predict the current gateway cluster computing load and network transmission load to obtain the load imbalance rate.

[0014] Preferably, the method for balancing the load of each gateway includes: The elastic load transfer algorithm balances the load by adjusting task allocation and reconfiguring gateway communication connections to transfer tasks from high-load gateways to low-load gateways; preset transfer mode rules, including task migration, connection redistribution and service migration; automatically reconfigure the connection between gateways, change the task allocation, service access point or protocol adaptation method of the high-load gateway; A feedback mechanism is set up. Once the load transfer is completed, the system will automatically continue to monitor the load changes of each gateway and feedback the effect of the load transfer to the gateway management interface. If a new load imbalance occurs, the gateway management interface will immediately send an early warning message to the mobile and PC terminals.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The present invention improves the adaptive ability of the gateway cluster in the face of equipment failures, communication delays and load fluctuations by optimizing the topology and introducing resilience coefficient calculation; the network can automatically adjust according to actual conditions, avoiding the vulnerability of static topology in traditional technologies; and through more accurate gateway node effectiveness evaluation, the overall stability of the system and node reliability are improved. When a node fails, the system can adjust quickly to ensure smooth data transmission; the system can dynamically optimize according to multiple factors such as the actual operating status of the gateway cluster, transmission delays, bandwidth utilization, etc., avoiding resource waste or overload problems caused by information lag or static configuration in traditional IoT gateway management; through automated network optimization and redundant path adjustment, it reduces reliance on manual intervention, reduces operation and maintenance costs, and improves the automation level of the system; Through cross-validation between multiple gateway nodes, global misjudgment caused by errors in a single node is avoided. The effectiveness evaluation of each node combines information from different nodes, reducing the probability of false positives and false negatives. When the effectiveness score reported by a node deviates greatly, the system promptly detects abnormal nodes through the credibility factor, and removes or corrects them according to the weight adjustment mechanism, enhancing the system's ability to cope with abnormal situations. The consensus mechanism and weighted voting allow the influence of each node to be dynamically adjusted according to its stability and participation, ensuring the system's adaptability in different network environments. Even if some nodes have problems, the system can automatically adjust to maintain overall efficient operation. Through transparent cross-validation and consensus mechanisms, the evaluation process of all nodes can be verified by other nodes, the credibility and transparency of the system are improved, and the dependence on single-point data is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a schematic diagram of the structure of the Internet of Things gateway collaborative management system based on edge computing of the present invention; Figure 2 A flow chart of the method for coordinating a gateway cluster provided by the present invention; Figure 3 It is a flow chart of the collaborative management method of Internet of Things gateways based on edge computing of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0018] Embodiment 1 See also Figure 1 and Figure 2 As shown, Embodiment 1 further illustrates the IoT gateway collaborative management system based on edge computing proposed by the present invention, including: With the rapid development of IoT technology, more and more devices and sensors are connected to the Internet through IoT gateways, which has promoted the intelligent transformation of various industries. As a bridge between devices and cloud platforms, IoT gateways undertake important communication, data processing and network management functions. In order to ensure the stability and efficiency of IoT systems, large-scale deployment of gateway clusters needs to implement intelligent collaborative management and effective fault tolerance mechanisms.

[0019] However, existing IoT gateway management systems often have the following technical problems when facing large-scale gateway clusters: The problem of insufficient reliability assessment of gateway nodes. Most traditional gateway node assessment methods only rely on the status of a single node, such as failure rate, task completion status and other indicators. They lack the ability to conduct comprehensive assessments from multiple dimensions, which can easily lead to inaccurate assessment results, thus affecting the stability and reliability of the entire gateway cluster.

[0020] Single point failure and data inconsistency problems. Existing technologies usually rely on centralized nodes or single point data for management, which leads to serious single point failure problems. If a central node or a key node fails, it may affect the stability and operating efficiency of the entire system. In addition, due to the large changes in the dynamic state of the gateway node, the single point data may not be able to reflect the actual operating status of the entire system in real time, resulting in data inconsistency and system instability.

[0021] Insufficient dynamic adjustment capability of network topology. In large-scale IoT deployment, the load and network status of gateway nodes often change dynamically. It is difficult for existing gateway management systems to perform real-time topology optimization and load balancing based on changes in network conditions. The lack of an effective dynamic adjustment mechanism makes it easy for gateway clusters to experience bottlenecks or performance degradation when facing network fluctuations, node failures, or uneven loads.

[0022] Lack of coordination and redundancy design between nodes. Although many IoT gateway systems have certain redundancy designs, most redundancy mechanisms fail to fully consider the coordination between nodes. The self-management and redundancy strategies of each gateway node often cannot effectively coordinate with other nodes, resulting in the system being unable to quickly make reasonable adjustments when facing failures or load changes.

[0023] Insufficient node effectiveness evaluation and anomaly detection. In existing systems, the evaluation of node effectiveness mainly relies on static indicators, such as failure rate and task execution stability, and lacks a mechanism for mutual verification between nodes. When some gateway nodes have false reports or cannot provide real and valid data, traditional methods are difficult to detect and handle anomalies in a timely manner, which in turn affects the healthy operation of the entire system.

[0024] In order to effectively solve the above problems, the present invention proposes an IoT gateway collaborative management system based on edge computing, including: Resource virtualization unit, used to deploy protocol-independent abstraction engines in gateway clusters, parse and adapt multiple IoT protocols, build proprietary protocol conversion matrices, obtain standardized device attribute data, and build device shadow models based on standardized device attribute data; The edge collaborative scheduling unit outputs panoramic status data through the device shadow model, adopts the edge computing task scheduling algorithm, abstracts the gateway cluster into a resilient topology directed graph based on the panoramic status data, and coordinates the gateway cluster; An intelligent load balancing unit, which is used to monitor the gateway cluster computing load and the network transmission load at the same time, and predict the load imbalance rate according to the gateway cluster computing load and the network transmission load; The gateway topology management unit presets a load imbalance rate threshold. If the load imbalance rate reaches the preset load imbalance rate threshold, the elastic load transfer algorithm is used to smoothly transfer the load, automatically reconfigure the gateway connection, and balance the load of each gateway; The operation and maintenance interaction management unit, based on the vue.js framework, provides a cross-platform gateway management interface and supports access and interaction from mobile and PC terminals.

[0025] Methods for parsing and adapting various IoT protocols include: Deploy a protocol-independent abstract engine in the gateway cluster and integrate multiple IoT protocol (such as MQTT, CoAP, HTTP, Modbus, OPC UA, Zigbee, LoRaWAN, BACnet, etc.) adapter modules inside the protocol-independent abstract engine; A plug-in architecture is used to assist the integration of IoT protocol adapter modules. For example, the plug-in architecture includes an MQTT adapter (subscribes to or publishes MQTT topics and parses payloads), a Modbus adapter (reads register data and converts it to a standard format), and a Zigbee adapter (parses Zigbee device data packets). When a device is connected to the gateway, the gateway automatically identifies the IoT protocol to which the device belongs and calls the corresponding IoT protocol adapter module to decode the original data packets of different protocols and extract the device attribute data of different protocols. Build a protocol conversion layer. After parsing, input the parsed device attribute data of different protocols into the protocol conversion layer and convert them into a standardized unified data format (the standardized unified data format adopts JSON, Protobuf, Avro and other formats, and provides field definition standards, such as device ID, timestamp, data type, etc.), obtain standardized device attribute data, and store them in a preset standardized device attribute database; standardized device attribute data includes device identification data, data acquisition timestamp, device data value, device status data, device location data and device configuration data; Deploy a proprietary protocol conversion matrix to store data formats and parameter conversion rules between different protocols. Parameter conversion rules include data unit conversion, data type conversion, data format conversion, command mapping, and data range adjustment. Use a dynamic loading mechanism to subsequently add or adjust parameter conversion rules. Through the proprietary protocol conversion matrix, map standardized device attribute data to different IoT protocols.

[0026] Methods for subsequently adding or adjusting parameter conversion rules using a dynamic loading mechanism include: Continuously monitor the update of parameter conversion rules, for example, through file system monitoring, message queues (such as Kafka or RabbitMQ) or database trigger mechanisms (such as Redis subscription or publishing mechanisms). When the parameter conversion rules are updated, the gateway management interface issues a notification and automatically triggers the reloading of the parameter conversion rules. When the new parameter conversion rules are loaded, the IoT protocol adapter module automatically performs format checks and compatibility verifications. For example, the JSON Schema verification mechanism can be used to ensure that the format of the rules is correct and detect whether there is a conflict with existing rules to avoid affecting the normal communication of the device due to incorrect conversion rules. And apply new parameter conversion rules. When the parsed device attribute data of different protocols enters the protocol conversion layer, the system will convert the data according to the latest parameter conversion rules; for example, if the temperature data storage method of a certain protocol changes (such as from integer storage to floating point number), the system will automatically apply the new rules for corresponding conversion to ensure the uniformity of data format. The system stores and manages historical parameter conversion rules every n periods of time. When any new parameter conversion rule is abnormal, it automatically rolls back to the historical parameter conversion rule version.

[0027] Methods for obtaining device shadow models include: Create a device shadow model for each device. The device shadow model includes three core modules, including the state storage layer, metadata layer and synchronization control layer. The state storage layer stores the latest state of the device, the metadata layer stores the static data of the device, and the synchronization control layer realizes two-way state synchronization between the device and the device shadow. The device reports the state to update the shadow, and the gateway management interface issues cloud commands, which are sent to the device through the device shadow. When the device reports its status, the device shadow model updates the reported field. Reported is a reflection of the actual status of the device, indicating the latest data (such as temperature value, switch status, power, etc.) reported by the device through the sensor or its own logic and recording the timestamp. The cloud modifies the desired field through the gateway management interface and issues instructions. Desired is a control instruction from the cloud or user to the device, indicating the target state that the device is expected to achieve (such as setting the target temperature, shutting down the device, etc.). The issued instructions are converted into the protocol format supported by the device through the IoT protocol adapter module. The device shadow model realizes two-way status synchronization through reported and desired. When the device status (reported) is inconsistent with the cloud instruction (desired), the system adopts a strategy to make adjustments. By default, the device status with the latest timestamp shall prevail. If the device is offline, the desired status modified by the cloud will be temporarily stored in the device shadow model, and will be automatically synchronized and executed after the device is reconnected. A RESTful API interface is provided to query the device status in real time. When a new device is connected, a new device shadow model is automatically created. The device shadow model is used as the data source of the digital twin to output the panoramic status data.

[0028] Panoramic status data includes device static data, dynamic operation status data, protocol context data, and health score data; Static device data includes device identification data (device unique ID, such as MAC address or serial number), device type data (sensor, actuator, gateway, and edge server), protocol type data (a list of supported protocols, such as Modbus, MQTT, and CoAP), and hardware specification data; hardware specification data includes computing power (such as the equivalent number of CPU cores), storage capacity (in GB), and sensor accuracy (such as the accuracy range of the temperature sensor is ±0.5°C); Dynamic operation status data includes the computing load, network status and connection status of the device; the computing load of the device includes CPU utilization and memory usage; the network status includes communication delay with adjacent nodes, network traffic distribution and network bandwidth usage; the connection status includes online status, offline status, Boolean value and last heartbeat timestamp;

[0029] The protocol context data includes the active protocol, data mapping rules (mapping of protocol fields to common models, e.g. Modbus registers to MQTT topics), and protocol conversion efficiency (additional delay for protocol conversion).

[0030] The gateway cluster is abstracted into a resilient topology directed graph based on the panoramic status data. The method for coordinating the gateway cluster includes: Obtain the panoramic status data output by the device shadow model of each gateway, and build a gateway node set and a gateway node attribute table based on the panoramic status data. The device static data, dynamic operation status data, protocol context data and health risk indicator data of each gateway node are recorded through the gateway node attribute table; according to the node attribute table, each gateway node is connected through weighted directed edges to generate an initial topology directed graph. The circles of the directed edges of the initial topology directed graph are automatically adjusted based on the transmission delay, bandwidth utilization and health score data between nodes; introduce a resilience coefficient calculation model, and calculate the resilience coefficient of each gateway node based on the initial topology directed graph. The resilience coefficient is obtained by weighted comprehensive evaluation of gateway node redundancy, number of critical paths and load balancing capability; The calculation of gateway node redundancy is based on the gateway node connection redundancy ratio of the initial topology directed graph. The gateway node redundancy is calculated by evaluating the number of alternative paths for each gateway node and the effectiveness of the gateway node. The number of alternative paths for the gateway node is traversed through the initial topology directed graph through a breadth-first search to find all paths in the initial topology directed graph that meet the preset alternative path screening rules, and define them as gateway node alternative paths. The preset alternative path screening rules include three screening threshold rules, and the three screening threshold rules include that the alternative path transmission delay is less than the preset alternative path transmission delay threshold, the bandwidth utilization is less than the preset bandwidth utilization threshold, and the health score is greater than or equal to the preset health score threshold. The judgment of the critical path is based on the minimum cut theory. By calculating the maximum gateway traffic path of the initial topology directed graph and analyzing the minimum cut contribution value of each gateway node in the path transmission, the path with the greatest impact on the connectivity of the initial topology directed graph is selected as the critical path; the evaluation of load balancing capability is based on the computing load and network traffic distribution between gateway nodes, and a discrete load balancing factor is used to measure the load balancing degree of the topology structure; The initial topology directed graph is optimized and adjusted according to the resilience coefficient, and a threshold for the number of critical paths is preset. When the number of screened critical paths reaches the preset threshold, the screening is stopped and redundant connections of gateway nodes are automatically added to finally obtain a resilient topology directed graph.

[0031] Methods for obtaining the validity of a gateway node include: The effectiveness of the gateway node is calculated by the historical failure rate and task execution stability of the gateway node. The historical failure times F and the total running time U of any gateway node within the preset time T are recorded. The historical failure times F within the preset time T are divided by the total running time U to obtain the historical failure rate H. Count the total number of tasks completed C and the number of failed tasks Ft of any gateway node within the preset time T, and subtract the difference between the total number of completed tasks C and the number of failed tasks Ft within the preset time T, and divide it by the total number of completed tasks C to obtain the task execution stability S; combine the historical failure rate H and the task execution stability S to obtain the gateway node effectiveness V=a1∙(1-H)+a2∙S; where a1 represents the historical failure rate weight factor, which controls the degree of influence of the historical failure rate on the gateway node effectiveness; a2 represents the task execution stability weight factor, which controls the degree of influence of the task execution stability on the gateway node effectiveness; the higher the gateway node effectiveness V, the more reliable the gateway node is, and it can be used as a high-redundancy gateway node; according to the expert experience method, the value range of a1 and a2 is (0,1]; The following problems existing in the prior art are solved: Complex collaborative management of gateway nodes: Due to factors such as the dynamic state of gateway nodes, network conditions, and the frequency of faults, coordination and management between gateways becomes complex. Especially in the case of large-scale gateway clusters, it is difficult to effectively adjust the network topology to adapt to the actual operating environment. When there are a large number of gateways, their states, network conditions, and fault information are difficult to manage uniformly, especially when the system becomes larger, and coordination becomes very troublesome. Lack of resilience optimization: Many existing solutions fail to fully consider network resilience, especially when faced with equipment failures, network fluctuations and other problems, and cannot make timely optimization adjustments, resulting in poor system stability and reliability. Most systems do not take resilience into account, which means that when faced with equipment failures, network delays or other problems, the system cannot make timely adjustments, resulting in poor system stability. Inability to adapt to dynamic changes: Existing technologies are often static and cannot adjust network topology in real time based on dynamic factors such as node status, network traffic, and fault information. Many existing solutions are fixed and cannot adjust the layout of gateways based on changes in device or network status, resulting in inflexible systems. The problem of lack of detail in gateway node effectiveness assessment: The gateway node assessment method adopted by many solutions is too simple, and lacks comprehensive indicators such as the node's historical failure rate and task execution stability, resulting in inaccurate assessment results, which in turn affects the overall gateway coordination and management; when evaluating the gateway, many solutions simply check whether the node is healthy, but do not consider other key factors such as the node's historical failure rate and task execution stability, which makes the gateway assessment less accurate; The innovation of this solution lies in the following aspects: Topology optimization driven by panoramic status data: The solution uses the panoramic status data provided by the device shadow model (not only the status of the device, but also protocol information, health data, etc.) to establish the gateway topology. In this way, the status of the gateway can be more comprehensively understood and the overall network structure can be optimized.

[0032] Introducing resilience coefficient and critical path analysis: By calculating the resilience coefficient and critical path and combining it with the evaluation of load balancing capabilities, the gateway topology is optimized. This not only focuses on the connectivity of the network topology, but also considers redundancy and load distribution, greatly enhancing the robustness and flexibility of the system and making the entire network more reliable. Dynamic redundancy and alternative path screening: By evaluating the redundancy of gateway nodes and the number of alternative paths, combined with screening rules in multiple dimensions such as transmission delay, bandwidth utilization and health score, the problem of single redundant path selection in existing technologies is solved, so that the network can recover quickly when a node fails; if a gateway fails, the network can automatically select an alternative path to ensure the connectivity and stability of the system; Node effectiveness comprehensive evaluation model: By combining historical failure rates and task execution stability, a more comprehensive gateway node effectiveness evaluation model is established, which can more accurately reflect the reliability of nodes, enhance the fault tolerance of gateway clusters, and avoid the one-sidedness of simply looking at the health status; Compared with the prior art, the beneficial effects are: By optimizing the topology and introducing resilience coefficient calculation, the adaptive ability of the gateway cluster in the face of device failures, communication delays and load fluctuations is improved; the network can automatically adjust according to actual conditions, avoiding the fragility of static topology in traditional technologies; Through more accurate evaluation of gateway node effectiveness, the overall stability of the system and node reliability are improved. When a node fails, the system can quickly adjust to ensure smooth data transmission; The system can dynamically optimize based on the actual operating status of the gateway cluster, transmission delay, bandwidth utilization and other factors, avoiding the resource waste or overload problems caused by information lag or static configuration in traditional IoT gateway management; Through automated network optimization and redundant path adjustment, the reliance on manual intervention is reduced, operation and maintenance costs are reduced, and the automation level of the system is improved; Here we consider that the traditional gateway node effectiveness calculation method relies on a centralized server to collect the historical failure rate and task stability of each gateway. However, if the data is tampered with or the central node fails, it will affect the accuracy of the evaluation results. To solve this problem, a distributed consensus mechanism is introduced to enable gateways to verify each other's reliability and obtain the final gateway node effectiveness; ensure that the data is true and reliable, and prevent individual malicious gateway nodes from forging failure rate data, thereby improving the credibility of the evaluation.

[0033] The final method for obtaining the validity of the gateway node includes: It is assumed that each gateway node reports its own historical failure rate H and task execution stability S every m periods of time, and preliminarily calculates the self-effectiveness score of each gateway node. However, it is stipulated that it is not directly submitted to the central gateway node, but cross-validated with each gateway node's own subordinate gateway node; the self-effectiveness score of each gateway node is Vci=a1∙(1-Hi)+a2∙Si; where Vci represents the self-effectiveness score of the i-th gateway node; Hi represents the historical failure rate of the i-th gateway node; Si represents the task execution stability of the i-th gateway node; i represents the index of the node; Gateway node i selects M subordinate gateway nodes (such as the nearest 3 to 5 on the initial topology directed graph), and sends its own effectiveness score to the subordinate gateway nodes through the Gossip protocol transmission. The other M subordinate gateway nodes respectively calculate the actual failure rate of gateway node i. The method for obtaining the actual failure rate includes: recording the number of failures Fi observed by the subordinate gateway node and the duration Ui of the observation of the subordinate gateway node, dividing the number of failures Fi observed by the subordinate gateway node by the duration Ui of the observation of the subordinate gateway node to obtain the actual failure rate Gi; combining the actual failure rate with the task execution stability Qi of gateway node i observed by the subordinate gateway node to obtain the actual gateway node effectiveness Ki=a1∙(1-Gi)+a2∙Qi; The actual gateway node validity Ki calculated by all slave gateway nodes is voted, and the value closest to the median is taken as the transition actual gateway node validity Ji; through the RAFT consensus mechanism, a leader gateway node and the corresponding slave gateway node (the slave gateway node is the neighbor node of each gateway node) are elected, and the sum of the validity scores reported to the leader gateway node by all slave gateway nodes is added to the validity score of each gateway node, and then divided by the total number of gateways to obtain the final global consistent validity score; A preset reporting validity score deviation threshold is set. If the deviation between the validity score reported by any gateway node and the validity score reported by the subordinate gateway node is greater than or equal to the preset reporting validity score deviation threshold, the gateway node is marked as a suspicious gateway node, and the credibility factor bi of the suspicious gateway node is calculated. ;in, Represents the parameter of the control credibility factor, which is determined according to the expert experience method. The value range of is (0,1]; Indicates the final global consistent validity score; the lower the credibility, the less trustworthy the gateway node is; The credibility factor threshold is preset. If the credibility factor of any gateway node is less than the preset credibility factor threshold, the validity score reported by the gateway node is ignored. By introducing consensus weight and credibility factor, the final gateway node validity is obtained. ;in, Represents the consensus weight of the slave gateway node, which is used to measure the impact of different slave gateway nodes on the final score and is determined based on expert experience. The value range of is (0,1]; Indicates the subordinate gateway node of the suspicious gateway node Credibility factor; Represents the validity score reported by slave gateway node j to the leader gateway node.

[0034] The following problems that are common in existing IoT gateway node effectiveness evaluation methods are solved: Single point of failure problem: Many existing methods rely on a single gateway node to evaluate their own effectiveness, which may affect the judgment of the entire system due to local failures or false alarms.

[0035] Lack of multi-angle evaluation: Some solutions only consider the historical failure rate of nodes or the stability of task execution, but lack comprehensive evaluation and cannot judge the reliability of nodes from all aspects.

[0036] Insensitivity to node anomalies: If there is a large deviation in the validity score reported by a gateway node, traditional methods may not be able to detect the unreliability of the node in time, resulting in the inability to identify and eliminate abnormal nodes in the network in a timely manner.

[0037] Lack of dynamic adjustment mechanism: Many existing methods do not consider the dynamic changes of nodes, and lack an effective mechanism to deal with the reliability differences between nodes, resulting in some unstable gateways still being considered valid nodes.

[0038] The innovation of this solution lies in the following aspects: By cross-validating each gateway node with multiple slave nodes, the calculation of the validity score no longer relies on single-point data, but is comprehensively evaluated through feedback from multiple nodes, avoiding the single-point failure problem of traditional methods. The Gossip protocol makes the transmission and verification of information more efficient.

[0039] By introducing the credibility factor, the reliability of the gateway node can be better evaluated. When there is a large deviation in the validity score reported by a node, the system can promptly detect and mark the node as suspicious, thereby ensuring the healthy operation of the entire network.

[0040] Through the RAFT consensus mechanism, the system can ensure that the final validity score is calculated by multiple gateway nodes, thereby avoiding the error impact of single-point data and improving the consistency and reliability of the network.

[0041] When calculating the final effectiveness score, a consensus weight mechanism is introduced so that the influence of subordinate nodes can be dynamically adjusted according to their credibility and participation, further improving the accuracy of the evaluation.

[0042] The beneficial effects compared with the prior art are: The accuracy and stability of the system are improved, and the global misjudgment caused by a single node error is avoided through cross-validation between multiple gateway nodes. The effectiveness evaluation of each node combines information from different nodes, reducing the probability of false positives and false negatives.

[0043] The system's anti-interference ability has been enhanced. When the validity score reported by a node deviates greatly, the system can promptly detect abnormal nodes through the credibility factor and eliminate or correct them according to the weight adjustment mechanism, thus enhancing the system's ability to deal with abnormal situations.

[0044] The consensus mechanism and weighted voting allow the influence of each node to be dynamically adjusted according to its stability and participation, ensuring the system's adaptability in different network environments. Even if some nodes have problems, the system can automatically adjust to maintain overall efficient operation.

[0045] Through transparent cross-validation and consensus mechanisms, the evaluation process of all nodes can be verified by other nodes, the credibility and transparency of the system are improved, and the dependence on single-point data is reduced.

[0046] Methods for predicting load imbalance ratio include: Train the load imbalance rate prediction model. The input data of the model is the historical monitoring gateway cluster computing load and network transmission load, and the output label of the model is the load imbalance rate. The load imbalance rate prediction model is a ridge regression model. Define the loss function of the model and use the mean square error loss function to measure the difference between the predicted load imbalance rate and the actual load imbalance rate. Use the trained load imbalance rate prediction model to predict the current gateway cluster computing load and network transmission load to obtain the load imbalance rate.

[0047] Methods for balancing the load of each gateway include: The elastic load transfer algorithm balances the load by adjusting task allocation and reconfiguring gateway communication connections, transferring tasks from high-load gateways to low-load gateways; preset transfer mode rules, including task migration, connection redistribution and service migration; task migration means migrating some ongoing computing tasks from one gateway to another; connection redistribution means adjusting the data flow between gateways at the network layer to ensure that high-load gateways reduce data transmission and allocate more traffic to low-load gateways; service migration means migrating some services or functions from one gateway node to other nodes to balance computing pressure; automatically reconfigure connections between gateways, change the task allocation, service access point or protocol adaptation method of high-load gateways; for example, a high-load gateway can temporarily stop receiving new connection requests, or direct new requests to other gateways through a load balancer; A feedback mechanism is set up. Once the load transfer is completed, the system will automatically continue to monitor the load changes of each gateway and feedback the effect of the load transfer to the gateway management interface. If a new load imbalance occurs, the gateway management interface will immediately send an early warning message to the mobile and PC terminals.

[0048] The preset load imbalance rate threshold is set by the staff. By collecting different load imbalance rates, the average value of multiple load imbalance rates is taken as the preset load imbalance rate threshold. Similarly, the preset alternative path transmission delay threshold, preset bandwidth utilization threshold, preset health score threshold, preset critical path quantity threshold, preset reporting validity score deviation threshold and preset credibility factor threshold are set.

[0049] This embodiment improves the adaptive ability of the gateway cluster in the face of equipment failures, communication delays, and load fluctuations by optimizing the topology and introducing resilience coefficient calculation; the network can automatically adjust according to actual conditions, avoiding the vulnerability of static topology in traditional technologies; and through more accurate gateway node effectiveness evaluation, the overall stability of the system and node reliability are improved. When a node fails, the system can quickly adjust to ensure smooth data transmission; the system can dynamically optimize according to multiple factors such as the actual operating status of the gateway cluster, transmission delays, and bandwidth utilization, avoiding resource waste or overload problems caused by information lag or static configuration in traditional IoT gateway management; through automated network optimization and redundant path adjustment, it reduces reliance on manual intervention, reduces operation and maintenance costs, and improves the automation level of the system; Through cross-validation between multiple gateway nodes, global misjudgment caused by errors in a single node is avoided. The effectiveness evaluation of each node combines information from different nodes, reducing the probability of false positives and false negatives. When the effectiveness score reported by a node deviates greatly, the system promptly detects abnormal nodes through the credibility factor, and removes or corrects them according to the weight adjustment mechanism, enhancing the system's ability to cope with abnormal situations. The consensus mechanism and weighted voting allow the influence of each node to be dynamically adjusted according to its stability and participation, ensuring the system's adaptability in different network environments. Even if some nodes have problems, the system can automatically adjust to maintain overall efficient operation. Through transparent cross-validation and consensus mechanisms, the evaluation process of all nodes can be verified by other nodes, the credibility and transparency of the system are improved, and the dependence on single-point data is reduced.

[0050] Embodiment 2 See also Figure 3 As shown, the part not described in detail in this embodiment is described in Example 1, and a collaborative management method for an Internet of Things gateway based on edge computing is provided, including: S1. Deploy a protocol-independent abstract engine in the gateway cluster, parse and adapt multiple IoT protocols, build a proprietary protocol conversion matrix, obtain standardized device attribute data, and establish a device shadow model based on the standardized device attribute data; S2. Output panoramic status data through the device shadow model, adopt the edge computing task scheduling algorithm, abstract the gateway cluster into a resilient topology directed graph based on the panoramic status data, and coordinate the gateway cluster; S3. Monitor the gateway cluster computing load and network transmission load simultaneously, and predict the load imbalance rate based on the gateway cluster computing load and network transmission load; S4, preset a load imbalance rate threshold. If the load imbalance rate reaches the preset load imbalance rate threshold, the load is smoothly transferred through the elastic load transfer algorithm, and the gateway connection is automatically reconfigured to balance the load of each gateway; S5. Based on the vue.js framework, it provides a cross-platform gateway management interface and supports access and interaction from mobile and PC terminals.

[0051] Since the electronic device introduced in this embodiment is an electronic device used to implement the Internet of Things gateway collaborative management system based on edge computing in the embodiment of this application, based on the Internet of Things gateway collaborative management system based on edge computing introduced in the embodiment of this application, the technical personnel of this field can understand the specific implementation of the electronic device of this embodiment and its various variations, so how the electronic device implements the method in the embodiment of this application is not introduced in detail here. As long as the technical personnel of this field implement the electronic device adopted by the Internet of Things gateway collaborative management system based on edge computing in the embodiment of this application, it belongs to the scope of protection of this application.

[0052] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters and thresholds in the formula are set by technicians in this field according to actual conditions.

[0053] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technical users in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. The IoT gateway collaborative management system based on edge computing is characterized by: include: Resource virtualization unit, used to deploy protocol-independent abstraction engines in gateway clusters, parse and adapt multiple IoT protocols, build proprietary protocol conversion matrices, obtain standardized device attribute data, and build device shadow models based on standardized device attribute data; The edge collaborative scheduling unit outputs panoramic status data through the device shadow model, adopts the edge computing task scheduling algorithm, abstracts the gateway cluster into a resilient topology directed graph based on the panoramic status data, and coordinates the gateway cluster; An intelligent load balancing unit, which is used to monitor the gateway cluster computing load and the network transmission load at the same time, and predict the load imbalance rate according to the gateway cluster computing load and the network transmission load; The gateway topology management unit presets a load imbalance rate threshold. If the load imbalance rate reaches the preset load imbalance rate threshold, the elastic load transfer algorithm is used to smoothly transfer the load, automatically reconfigure the gateway connection, and balance the load of each gateway; The operation and maintenance interaction management unit, based on the vue.js framework, provides a cross-platform gateway management interface and supports access and interaction from mobile and PC terminals.

2. The IoT gateway collaborative management system based on edge computing according to claim 1 is characterized in that: The method for parsing and adapting multiple IoT protocols includes: Deploy a protocol-independent abstract engine in the gateway cluster and integrate multiple IoT protocol adapter modules inside the protocol-independent abstract engine; A plug-in architecture is used to assist the integration of IoT protocol adapter modules. When a device is connected to the gateway, the gateway automatically identifies the IoT protocol to which the device belongs, and calls the corresponding IoT protocol adapter module to decode the original data packets of different protocols and extract the device attribute data of different protocols. Construct a protocol conversion layer. After parsing is completed, the parsed device attribute data of different protocols are input into the protocol conversion layer, converted into a standardized unified data format, and standardized device attribute data is obtained and stored in a preset standardized device attribute database; the standardized device attribute data includes device identification data, data acquisition timestamp, device data value, device status data, device location data and device configuration data; Deploy a proprietary protocol conversion matrix to store data formats and parameter conversion rules between different protocols. Parameter conversion rules include data unit conversion, data type conversion, data format conversion, command mapping, and data range adjustment. Use a dynamic loading mechanism to subsequently add or adjust parameter conversion rules. Through the proprietary protocol conversion matrix, map standardized device attribute data to different IoT protocols.

3. The IoT gateway collaborative management system based on edge computing according to claim 2 is characterized in that: The method of using the dynamic loading mechanism to subsequently add or adjust parameter conversion rules includes: Continuously monitor the update of parameter conversion rules. When the parameter conversion rules are updated, the gateway management interface sends a notification and automatically triggers the reloading of the parameter conversion rules. When the new parameter conversion rules are loaded, the IoT protocol adapter module automatically performs format check and compatibility verification, and applies the new parameter conversion rules. When the parsed device attribute data of different protocols enters the protocol conversion layer, the system converts the data according to the latest parameter conversion rules. The system stores and manages historical parameter conversion rules every n periods of time. When any new parameter conversion rule is abnormal, it automatically rolls back to the historical parameter conversion rule version.

4. The IoT gateway collaborative management system based on edge computing according to claim 3 is characterized in that: The method for obtaining the device shadow model includes: Create a device shadow model for each device. The device shadow model includes three core modules, including the state storage layer, metadata layer and synchronization control layer. The state storage layer stores the latest state of the device, the metadata layer stores the static data of the device, and the synchronization control layer realizes two-way state synchronization between the device and the device shadow. The device reports the state to update the shadow, and the gateway management interface issues cloud commands, which are sent to the device through the device shadow. When the device reports its status, the device shadow model updates the reported field and records the timestamp. The cloud modifies the desired field through the gateway management interface and issues an instruction, which is converted into the protocol format supported by the device through the IoT protocol adapter module. The device shadow model achieves two-way status synchronization through reported and desired. When the device status is inconsistent with the cloud instruction, the system adopts a strategy to make adjustments, and the device status with the latest timestamp is used by default. If the device is offline, the desired status modified in the cloud will be temporarily stored in the device shadow model, and will be automatically synchronized and executed after the device is reconnected. A RESTful API interface is provided to query the device status in real time. When a new device is connected, a new device shadow model is automatically created. The device shadow model is used as the data source of the digital twin to output panoramic status data.

5. The IoT gateway collaborative management system based on edge computing according to claim 4 is characterized in that: The panoramic status data includes device static data, dynamic operation status data, protocol context data and health score data.

6. The IoT gateway collaborative management system based on edge computing according to claim 5 is characterized in that: The method for abstracting the gateway cluster into a resilient topology directed graph based on the panoramic status data and coordinating the gateway cluster includes: Obtain the panoramic status data output by the device shadow model of each gateway, and build a gateway node set and a gateway node attribute table based on the panoramic status data. The device static data, dynamic operation status data, protocol context data and health risk indicator data of each gateway node are recorded through the gateway node attribute table; according to the node attribute table, each gateway node is connected through weighted directed edges to generate an initial topology directed graph. The circles of the directed edges of the initial topology directed graph are automatically adjusted based on the transmission delay, bandwidth utilization and health score data between nodes; introduce a resilience coefficient calculation model, and calculate the resilience coefficient of each gateway node based on the initial topology directed graph. The resilience coefficient is obtained by weighted comprehensive evaluation of gateway node redundancy, number of critical paths and load balancing capability; The calculation of gateway node redundancy is based on the gateway node connection redundancy ratio of the initial topology directed graph. The gateway node redundancy is calculated by evaluating the number of alternative paths for each gateway node and the effectiveness of the gateway node. The number of alternative paths for the gateway node is traversed through the initial topology directed graph through a breadth-first search to find all paths in the initial topology directed graph that meet the preset alternative path screening rules, and define them as gateway node alternative paths. The preset alternative path screening rules include three screening threshold rules, and the three screening threshold rules include that the alternative path transmission delay is less than the preset alternative path transmission delay threshold, the bandwidth utilization is less than the preset bandwidth utilization threshold, and the health score is greater than or equal to the preset health score threshold. The judgment of the critical path is based on the minimum cut theory. By calculating the maximum gateway traffic path of the initial topology directed graph and analyzing the minimum cut contribution value of each gateway node in the path transmission, the path with the greatest impact on the connectivity of the initial topology directed graph is selected as the critical path; the evaluation of load balancing capability is based on the computing load and network traffic distribution between gateway nodes, and a discrete load balancing factor is used to measure the load balancing degree of the topology structure; The initial topology directed graph is optimized and adjusted according to the resilience coefficient, and a threshold for the number of critical paths is preset. When the number of screened critical paths reaches the preset threshold, the screening is stopped and redundant connections of gateway nodes are automatically added to finally obtain a resilient topology directed graph.

7. The IoT gateway collaborative management system based on edge computing according to claim 6 is characterized in that: The method for obtaining the validity of the gateway node includes: The effectiveness of the gateway node is calculated by the historical failure rate and task execution stability of the gateway node. The historical failure times F and the total running time U of any gateway node within the preset time T are recorded. The historical failure times F within the preset time T are divided by the total running time U to obtain the historical failure rate H. Count the total number of tasks C completed and the number of failed tasks Ft of any gateway node within the preset time T, and divide the difference between the total number of tasks C completed within the preset time T and the number of failed tasks Ft by the total number of completed tasks C to obtain the task execution stability S; combine the historical failure rate H and the task execution stability S to obtain the gateway node effectiveness V=a1∙(1-H)+a2∙S; where a1 represents the historical failure rate weight factor; a2 represents the task execution stability weight factor; The introduction of a distributed consensus mechanism enables gateways to verify each other's reliability and obtain the final gateway node validity.

8. The Internet of Things gateway collaborative management system based on edge computing according to claim 7 is characterized in that: The method for obtaining the final gateway node validity includes: It is assumed that each gateway node reports its own historical failure rate H and task execution stability S every m periods of time, and preliminarily calculates the self-effectiveness score of each gateway node. However, it is stipulated that it is not directly submitted to the central gateway node, but cross-validated with each gateway node's own subordinate gateway node; the self-effectiveness score of each gateway node is Vci=a1∙(1-Hi)+a2∙Si; where Vci represents the self-effectiveness score of the i-th gateway node; Hi represents the historical failure rate of the i-th gateway node; Si represents the task execution stability of the i-th gateway node; i represents the index of the node; Gateway node i selects M subordinate gateway nodes (such as the nearest 3 to 5 on the initial topology directed graph), and sends its own effectiveness score to the subordinate gateway nodes through the Gossip protocol transmission. The other M subordinate gateway nodes respectively calculate the actual failure rate of gateway node i. The method for obtaining the actual failure rate includes: recording the number of failures Fi observed by the subordinate gateway node and the duration Ui of the observation of the subordinate gateway node, dividing the number of failures Fi observed by the subordinate gateway node by the duration Ui of the observation of the subordinate gateway node to obtain the actual failure rate Gi; combining the actual failure rate with the task execution stability Qi of gateway node i observed by the subordinate gateway node to obtain the actual gateway node effectiveness Ki=a1∙(1-Gi)+a2∙Qi; The actual gateway node validity Ki calculated by all slave gateway nodes is voted, and the value closest to the median is taken as the transition actual gateway node validity Ji; through the RAFT consensus mechanism, a leader gateway node and the corresponding slave gateway node are elected, and the validity score of each gateway node is added to the sum of the validity scores reported to the leader gateway node by all slave gateway nodes, and then divided by the total number of gateways to obtain the final global consistent validity score; A preset reporting validity score deviation threshold is set. If it is found that the deviation between the validity score reported by any gateway node and the validity score reported by the subordinate gateway node is greater than or equal to the preset reporting validity score deviation threshold, the gateway node is marked as a suspicious gateway node, and the credibility factor bi of the suspicious gateway node is calculated; A credibility factor threshold is preset. If the credibility factor of any gateway node is less than the preset credibility factor threshold, the validity score reported by the gateway node is ignored. By introducing consensus weight and credibility factor, the final gateway node validity is obtained.

9. The Internet of Things gateway collaborative management system based on edge computing according to claim 8 is characterized in that: The method for predicting the load imbalance rate includes: Train the load imbalance rate prediction model. The input data of the model is the historical monitoring gateway cluster computing load and network transmission load, and the output label of the model is the load imbalance rate. The load imbalance rate prediction model is a ridge regression model. Define the loss function of the model and use the mean square error loss function to measure the difference between the predicted load imbalance rate and the actual load imbalance rate. Use the trained load imbalance rate prediction model to predict the current gateway cluster computing load and network transmission load to obtain the load imbalance rate.

10. The Internet of Things gateway collaborative management system based on edge computing according to claim 9, characterized in that: The method for balancing the load of each gateway includes: The elastic load transfer algorithm balances the load by adjusting task allocation and reconfiguring gateway communication connections to transfer tasks from high-load gateways to low-load gateways; preset transfer mode rules, including task migration, connection redistribution and service migration; automatically reconfigure the connection between gateways, change the task allocation, service access point or protocol adaptation method of the high-load gateway; A feedback mechanism is set up. Once the load transfer is completed, the system will automatically continue to monitor the load changes of each gateway and feedback the effect of the load transfer to the gateway management interface. If a new load imbalance occurs, the gateway management interface will immediately send an early warning message to the mobile and PC terminals.

Images