Internet of Things gateway cluster self-healing method and system based on smart contract

Abstract

The invention discloses an Internet of Things gateway cluster self-healing method and system based on a smart contract, belongs to the technical field of Internet of Things gateways, and aims to solve the technical problem of how to overcome the defects of long switching delay, dependence on manual intervention and lack of credible collaboration in an existing gateway fault-tolerant scheme. According to the technical scheme, automatic detection, task dynamic migration and routing real-time updating when gateway faults occur are achieved, it is ensured that the service interruption time is smaller than one second, and the method comprises the steps that a plurality of Internet of Things gateways form a distributed cluster through a Mesh network, and each Internet of Things gateway collects the health state of the Internet of Things gateway in real time; a block chain consensus mechanism is adopted to write the health state into a non-tampering distributed account book, and data credibility is ensured; a fault self-healing intelligent contract is preset, and when any one of the Internet of Things gateways stops reporting due to power failure or fault, the contract automatically triggers the fault self-healing intelligent contract, that is, adjacent healthy Internet of Things gateways with low load are screened, and access equipment of the fault Internet of Things gateway is averagely distributed to candidate gateways.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things gateway, in particular to an Internet of Things gateway cluster self-healing method and system based on smart contract. BACKGROUND

[0002] In the Internet of Things system, the gateway is the core hub connecting the perception layer device and the network layer, and its running stability directly determines the availability of the entire system. At present, the fault-tolerant schemes commonly used in industrial scenarios mainly include the following two types:

[0003] ① Single gateway redundant backup scheme: deploy two master and standby gateways, manually switch to the standby gateway when the master gateway fails. This scheme has the problems of long switching delay (usually more than 5 minutes) and high cost of manual intervention, which cannot meet the real-time requirements of "service interruption time <1 second" in industrial production.

[0004] ② Static cluster management scheme: distribute device data to fixed gateways through pre-set routing tables, when a gateway fails, rely on cloud servers to recalculate the routing and issue to the cluster, the whole process is greatly affected by network delay, and the real-time health status of the gateway (such as CPU load, bandwidth utilization) is not considered, which easily leads to secondary failure of healthy gateways due to overload.

[0005] The existing technology focuses on fault detection of single gateway (such as hardware failure alarm, data packet loss monitoring) or static resource allocation, and does not involve the fusion design of "dynamic self-healing based on real-time health status" and "blockchain trusted collaboration", which cannot solve the problems of "self-healing delay" and "lack of trust" in distributed scenarios.

[0006] Therefore, how to overcome the defects of long switching delay, reliance on manual intervention and lack of trusted collaboration in existing gateway fault-tolerant schemes, realize automatic detection, dynamic task migration and real-time routing update when the gateway fails, and ensure that the service interruption time is less than 1 second is a technical problem to be solved at present. SUMMARY

[0007] The technical task of the present application is to provide an Internet of Things gateway cluster self-healing method and system based on smart contract, to solve the problem of how to overcome the defects of long switching delay, reliance on manual intervention and lack of trusted collaboration in existing gateway fault-tolerant schemes, realize automatic detection, dynamic task migration and real-time routing update when the gateway fails, and ensure that the service interruption time is less than 1 second.

[0008] The technical task of the present application is achieved in the following way: an Internet of Things gateway cluster self-healing method based on smart contract, which is specifically as follows:

[0009] A plurality of Internet of Things gateways form a distributed cluster in a Mesh network, and each Internet of Things gateway collects its own health status in real time;

[0010] By employing a blockchain consensus mechanism (such as PBFT), health status is written into an immutable distributed ledger to ensure data trustworthiness;

[0011] A pre-set fault self-healing smart contract is set up. When any IoT gateway stops reporting its status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract. This means that adjacent healthy IoT gateways with low load are selected, the access devices of the faulty IoT gateway are evenly distributed to the candidate gateways, and the cluster routing table is updated synchronously to guide the devices to switch seamlessly.

[0012] Preferably, each IoT gateway, as a Mesh node, has the following functions:

[0013] ① Connect to sensing layer devices (such as sensors and controllers) to achieve data acquisition and protocol conversion;

[0014] ② Establish wireless or wired Mesh links with adjacent IoT gateways to support data forwarding and status interaction;

[0015] ③ It has a built-in light blockchain node that participates in cluster consensus and state storage.

[0016] Even better, each IoT gateway is equipped with a health status monitoring module. The health status monitoring module is used to monitor and report monitoring data in real time. The monitoring data is synchronized to all IoT gateways in the distributed cluster through heartbeat packets of the Mesh network (every 100ms interval), ensuring that each gateway node has real-time knowledge of the overall health status of the distributed cluster.

[0017] The monitoring data includes hardware status, operating status, and fault indicators.

[0018] Hardware status includes CPU load (sampling frequency 1 time / second), memory utilization, and network bandwidth utilization.

[0019] Operating status includes device access volume, data forwarding success rate, and protocol conversion latency;

[0020] Fault indicators include abnormal states such as power outage, network outage, and hardware failure (e.g., RF module failure).

[0021] More preferably, the blockchain consensus mechanism employs a Byzantine fault-tolerant consensus algorithm, writing the health status of the IoT gateway into the blockchain ledger in key-value format, as follows:

[0022] Each IoT gateway acts as a light node in the blockchain, packaging locally collected health status data into status blocks.

[0023] Three consensus nodes are randomly elected in the distributed cluster to perform consistency verification on the status blocks reported by each IoT gateway; the consistency verification includes verifying whether the CPU load data is within a reasonable range.

[0024] Once the verification is successful, the status block is written into the distributed ledger and cannot be tampered with, ensuring the credibility of the health status data.

[0025] More specifically, the triggering conditions for a fault-healing smart contract are as follows:

[0026] No health status report was detected from any of the specified IoT gateways in the blockchain ledger for three consecutive heartbeat cycles (300ms in total);

[0027] Any IoT gateway can report a hardware failure or an overload condition with bandwidth utilization exceeding 95%.

[0028] More preferably, the execution process of a fault-healing smart contract is as follows;

[0029] (1) Fault location: The ID, geographical location (preset in the gateway initialization information) and list of connected devices of the faulty gateway are confirmed through the blockchain ledger;

[0030] (2) Health gateway screening: Query the health status of adjacent gateways in the distributed cluster and screen out candidate gateways whose CPU load is lower than the first preset threshold and whose bandwidth utilization is lower than the second preset threshold; where adjacent gateways refer to Mesh link distance ≤ 2 hops;

[0031] (3) Task allocation: According to the load balancing principle, the access devices of the faulty gateway are evenly distributed to the candidate gateways. For example, when the faulty gateway is connected to 20 sensors, it is allocated to 2 candidate gateways (each of which takes over 10 sensors).

[0032] Command issuance: The device takeover command is issued to the candidate gateway through the Mesh network. The content of the device takeover command includes the protocol type and data acquisition frequency configuration information of the access device.

[0033] More preferably, after receiving the device takeover command, the candidate gateway performs the following operations:

[0034] (1) Automatically update the local routing table and add the IP address and data forwarding rules of the managed device;

[0035] (2) Broadcast the updated routing table to all gateways in the distributed cluster via routing synchronization packets to ensure consistency of data forwarding paths;

[0036] (3) Send a connection switching command to the managed device to guide the device to switch from the faulty gateway to the new gateway. The switching process adopts a seamless handshake mechanism to avoid data loss.

[0037] A smart contract-based self-healing system for IoT gateway clusters, which implements the aforementioned smart contract-based self-healing method for IoT gateway clusters; the system includes:

[0038] The gateway cluster module is used to form a distributed cluster of multiple IoT gateways in a Mesh network. Each IoT gateway collects its own health status in real time through the health status monitoring module. The health status monitoring module is deployed in each IoT gateway to monitor and report monitoring data in real time. The monitoring data is synchronized to all IoT gateways in the distributed cluster through heartbeat packets (every 100ms) in the Mesh network, ensuring that each gateway node has real-time knowledge of the overall health status of the distributed cluster.

[0039] The blockchain consensus module is used to write the health status into an immutable distributed ledger using a blockchain consensus mechanism (such as PBFT) to ensure data trustworthiness.

[0040] The smart contract self-healing module is used to preset a fault self-healing smart contract. When any IoT gateway stops reporting its status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract. This means selecting adjacent healthy IoT gateways with low load, distributing the access devices of the faulty IoT gateway evenly to the candidate gateways, and synchronously updating the cluster routing table to guide the devices to switch seamlessly.

[0041] The route update module is used to synchronize routing information and update the local routing table.

[0042] An electronic device includes: a memory and at least one processor;

[0043] The memory contains computer programs;

[0044] The at least one processor executes the computer program stored in the memory, causing the at least one processor to perform the self-healing method for IoT gateway clusters based on smart contracts as described above.

[0045] A computer-readable storage medium storing a computer program that can be executed by a processor to implement the self-healing method for IoT gateway clusters based on smart contracts as described above.

[0046] The self-healing method and system for IoT gateway clusters based on smart contracts of the present invention have the following advantages:

[0047] (i) The total time for the fault self-healing process of this invention is 4.8 seconds, and the service interruption time is 0.9 seconds, which far meets the requirement of "interruption time < 1 second" for workshop production; after GW-002 and GW-004 take over the equipment, the CPU load rises to 58% and 62% respectively (still within the safe threshold), and the bandwidth utilization rises to 68% and 72%, without overload.

[0048] (II) This invention solves the problems of "long switching delay, reliance on manual intervention, and lack of trusted collaboration" in existing IoT gateway fault tolerance solutions. It provides a distributed gateway cluster self-healing protocol, which realizes automatic detection, dynamic task migration and real-time route update when the gateway fails through the distributed architecture of the Mesh network and the trusted consensus mechanism of the blockchain. It ensures that the business interruption time is less than 1 second and is suitable for scenarios with extremely high requirements for gateway stability and business continuity, such as industrial IoT and smart factories. It can realize rapid self-healing and seamless task migration when the gateway fails.

[0049] (III) This invention requires a centralized control server. Through distributed communication of the Mesh network, trusted storage of blockchain, and automated execution of smart contracts, it can achieve millisecond-level fault detection, quickly complete task migration and route updates, greatly shorten business interruption time, improve cluster resource utilization, significantly reduce hardware costs, and effectively ensure the stable operation of the Internet of Things system. Attached Figure Description

[0050] The invention will be further described below with reference to the accompanying drawings.

[0051] Appendix Figure 1 This is a schematic diagram of the structure of a smart contract-based IoT gateway cluster self-healing system.

[0052] Appendix Figure 2 This is a schematic diagram of the self-healing process of a smart factory workshop gateway cluster. Detailed Implementation

[0053] The self-healing method and system for IoT gateway clusters based on smart contracts of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0054] Example 1:

[0055] This embodiment provides a self-healing method for IoT gateway clusters based on smart contracts, as detailed below:

[0056] S1. Multiple IoT gateways are arranged into a distributed cluster using a Mesh network, and each IoT gateway collects its own health status in real time.

[0057] S2. Employ blockchain consensus mechanisms (such as PBFT) to write health status into an immutable distributed ledger, ensuring data trustworthiness;

[0058] S3. Pre-set fault self-healing smart contract: When any IoT gateway stops reporting status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract, which selects adjacent healthy IoT gateways with low load, distributes the access devices of the faulty IoT gateway evenly to the candidate gateways, and synchronously updates the cluster routing table to guide the devices to switch seamlessly.

[0059] In this embodiment, each IoT gateway, acting as a Mesh node, has the following functions:

[0060] ① Connect to sensing layer devices (such as sensors and controllers) to achieve data acquisition and protocol conversion;

[0061] ② Establish wireless or wired Mesh links with adjacent IoT gateways to support data forwarding and status interaction;

[0062] ③ It has a built-in light blockchain node that participates in cluster consensus and state storage.

[0063] In this embodiment, a health status monitoring module is deployed in each IoT gateway. The health status monitoring module is used to monitor and report monitoring data in real time. The monitoring data is synchronized to all IoT gateways in the distributed cluster through heartbeat packets of the Mesh network (every 100ms interval), ensuring that each gateway node has real-time knowledge of the overall health status of the distributed cluster.

[0064] The monitoring data includes hardware status, operating status, and fault indicators.

[0065] Hardware status includes CPU load (sampling frequency 1 time / second), memory utilization, and network bandwidth utilization.

[0066] Operating status includes device access volume, data forwarding success rate, and protocol conversion latency;

[0067] Fault indicators include abnormal states such as power outage, network outage, and hardware failure (e.g., RF module failure).

[0068] In this embodiment, step S2 uses a Byzantine fault-tolerant consensus algorithm to write the health status of the IoT gateway into the blockchain ledger in key-value format, as follows:

[0069] S201. Each IoT gateway acts as a light node in the blockchain, packaging locally collected health status data into status blocks.

[0070] S202. Three consensus nodes are randomly elected in the distributed cluster to perform consistency verification on the status blocks reported by each IoT gateway; the consistency verification includes verifying whether the CPU load data is within a reasonable range.

[0071] S203. After the verification is passed, the status block is written into the distributed ledger and cannot be tampered with, ensuring the credibility of the health status data.

[0072] The specific triggering conditions for the fault self-healing smart contract in step S2 of this embodiment are as follows:

[0073] ① No health status report was detected from any of the specified IoT gateways in the blockchain ledger for three consecutive heartbeat cycles (300ms in total);

[0074] ② Any IoT gateway reports a hardware failure or an overload state with bandwidth utilization >95%.

[0075] The specific execution process of the fault self-healing smart contract in step S3 of this embodiment is as follows:

[0076] (1) Fault location: The ID, geographical location (preset in the gateway initialization information) and list of connected devices of the faulty gateway are confirmed through the blockchain ledger;

[0077] (2) Health gateway screening: Query the health status of adjacent gateways in the distributed cluster and screen out candidate gateways whose CPU load is lower than the first preset threshold and whose bandwidth utilization is lower than the second preset threshold; where adjacent gateways refer to Mesh link distance ≤ 2 hops;

[0078] (3) Task allocation: According to the load balancing principle, the access devices of the faulty gateway are evenly distributed to the candidate gateways. For example, when the faulty gateway is connected to 20 sensors, it is allocated to 2 candidate gateways (each of which takes over 10 sensors).

[0079] Command issuance: The device takeover command is issued to the candidate gateway through the Mesh network. The content of the device takeover command includes the protocol type and data acquisition frequency configuration information of the access device.

[0080] In this embodiment, after receiving the device takeover command, the candidate gateway performs the following operations:

[0081] (1) Automatically update the local routing table and add the IP address and data forwarding rules of the managed device;

[0082] (2) Broadcast the updated routing table to all gateways in the distributed cluster via routing synchronization packets to ensure consistency of data forwarding paths;

[0083] (3) Send a connection switching command to the managed device to guide the device to switch from the faulty gateway to the new gateway. The switching process adopts a seamless handshake mechanism to avoid data loss.

[0084] Example 2:

[0085] Taking the "Smart Factory Workshop Gateway Cluster" as an example, as shown in the attached document...Figure 2 As shown, the self-healing process of the IoT gateway cluster is as follows:

[0086] (I) Cluster Deployment: In a car parts production workshop, 5 IoT gateways are deployed, forming a cluster through a wireless Mesh network (2.4GHz band, transmission rate 150Mbps). Each gateway connects to 15 devices (including temperature sensors and vibration sensors). The following parameters are preset during gateway initialization:

[0087] Gateway ID: GW-001-GW-005;

[0088] Geographic location: Coordinates within the workshop (e.g., GW-001 is located at workstation 1 in area A);

[0089] Blockchain light node configuration: 3 PBFT consensus nodes, heartbeat interval 100ms.

[0090] (ii) Fault Trigger: When GW-003 fails due to an unexpected power outage, the health status monitoring modules of other gateways in the cluster do not receive the status report from GW-003 for three consecutive heartbeat cycles (300ms), triggering the smart contract self-healing process.

[0091] (III) Self-healing execution, as detailed below:

[0092] ① Fault location: The smart contract retrieved the list of access devices for GW-003 (15 devices, including 8 temperature sensors and 7 vibration sensors) from the blockchain ledger, and found that the adjacent gateways were GW-002 (Mesh link 1 hop) and GW-004 (Mesh link 1 hop);

[0093] ②Health Gateway Filtering: Query the real-time health status of GW-002 and GW-004:

[0094] GW-002: CPU load 45%, bandwidth utilization 55%, meeting the criteria of "CPU < 60%, bandwidth < 70%";

[0095] GW-004: CPU load 50%, bandwidth utilization 60%, meets the requirements;

[0096] ③ Task allocation: The smart contract allocates the 15 devices of GW-003 to GW-002 (which manages 7 temperature sensors) and GW-004 (which manages 8 vibration sensors + PLC controller);

[0097] ④ Route update: After receiving the command, GW-002 and GW-004 complete the local routing table update within 1 second and broadcast the route synchronization packet through the Mesh network. All gateways in the cluster complete the route synchronization within 2 seconds.

[0098] ⑤ Device switching: GW-002 and GW-004 send a "connection switching command" to the managed device. The device completes the connection switching within 1.5 seconds, during which only 1 frame of data is lost (data recovery rate 99.8%).

[0099] Example 3:

[0100] As attached Figure 1 As shown, this embodiment provides a smart contract-based self-healing system for an IoT gateway cluster. This system is used to implement the smart contract-based self-healing method for an IoT gateway cluster as described in Embodiment 1. The system includes:

[0101] The gateway cluster module is used to form a distributed cluster of multiple IoT gateways in a Mesh network. Each IoT gateway collects its own health status in real time through the health status monitoring module.

[0102] The blockchain consensus module is used to write the health status into an immutable distributed ledger using a blockchain consensus mechanism (such as PBFT) to ensure data trustworthiness.

[0103] The smart contract self-healing module is used to preset a fault self-healing smart contract. When any IoT gateway stops reporting its status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract. This means selecting adjacent healthy IoT gateways with low load, distributing the access devices of the faulty IoT gateway evenly to the candidate gateways, and synchronously updating the cluster routing table to guide the devices to switch seamlessly.

[0104] The route update module is used to synchronize routing information and update the local routing table.

[0105] In this embodiment, the gateway cluster architecture design is as follows:

[0106] N (N≥3) IoT gateways are connected to form a distributed cluster via a mesh network. Each gateway, as a mesh node, has the following functions:

[0107] ① Connect to sensing layer devices (such as sensors and controllers) to achieve data acquisition and protocol conversion;

[0108] ② Establish wireless / wired Mesh links with adjacent gateways to support data forwarding and status interaction;

[0109] ③ It has a built-in light blockchain node that participates in cluster consensus and state storage.

[0110] In this embodiment, each gateway is equipped with a health status monitoring module to monitor and report the following parameters in real time:

[0111] Hardware status: CPU load (sampling frequency 1 time / second), memory utilization, network bandwidth utilization;

[0112] Operating status: number of connected devices, data forwarding success rate, protocol conversion latency;

[0113] Fault indicators: abnormal states such as power failure, network failure, and hardware failure (e.g., RF module failure).

[0114] Monitoring data is synchronized to all gateways within the cluster via "heartbeat packets" (every 100ms interval) from the Mesh network, ensuring that each node has real-time access to the overall health status of the cluster.

[0115] In this embodiment, the blockchain consensus module employs a Byzantine fault-tolerant consensus algorithm, writing the gateway health status into the blockchain ledger in key-value format. The specific process is as follows:

[0116] ① Each gateway acts as a light node in the blockchain, packaging locally collected health status data into "status blocks";

[0117] ② Three "consensus nodes" are randomly elected in the cluster to perform consistency verification on the status blocks reported by each gateway (such as verifying whether the CPU load data is within a reasonable range);

[0118] ③ After verification, the status block is written into the distributed ledger and cannot be tampered with, ensuring the credibility of the health status data.

[0119] The smart contract self-healing module in this embodiment is pre-set with a "fault self-healing smart contract", which is automatically executed when the following triggering conditions are met:

[0120] ① No health status report was detected from a certain gateway in the blockchain ledger for three consecutive heartbeat cycles (300ms in total);

[0121] ② A gateway reports an overload status of "hardware failure" or "bandwidth utilization > 95%".

[0122] The smart contract execution process in this implementation is as follows:

[0123] ① Fault location: Confirm the ID, geographical location (preset in the gateway initialization information), and list of connected devices of the faulty gateway through the blockchain ledger;

[0124] ②Health Gateway Filtering: Query the health status of adjacent gateways within the cluster (Mesh link distance ≤ 2 hops) and filter out candidate gateways with "CPU load below the first preset threshold and bandwidth utilization below the second preset threshold";

[0125] ③ Task allocation: According to the "load balancing" principle, the access devices of the faulty gateway are evenly distributed to the candidate gateways. For example, when the faulty gateway is connected to 20 sensors, it is allocated to 2 candidate gateways (each of which takes over 10 sensors).

[0126] ④ Command issuance: Issue "device takeover command" to candidate gateways through the Mesh network, which includes configuration information such as the protocol type and data acquisition frequency of the access device.

[0127] In this embodiment, after receiving the "device takeover command", the candidate gateway performs the following operations:

[0128] ① Automatically update the local routing table, adding the IP address and data forwarding rules of the managed device;

[0129] ② The updated routing table is broadcast to all gateways in the cluster via a "routing synchronization packet" to ensure consistency of data forwarding paths;

[0130] ③ Send a "connection switching command" to the managed device to guide the device to switch from the faulty gateway to the new gateway. The switching process adopts a "seamless handshake" mechanism to avoid data loss.

[0131] Example 4:

[0132] This embodiment also provides an electronic device, including: a memory and a processor;

[0133] The memory stores the instructions executed by the computer.

[0134] The processor executes computer execution instructions stored in the memory, causing the processor to execute the smart contract-based IoT gateway cluster self-healing method in any embodiment of the present invention.

[0135] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0136] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0137] Example 5:

[0138] This embodiment also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the smart contract-based IoT gateway cluster self-healing method according to any embodiment of the present invention. Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0139] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0140] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0141] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0142] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A self-healing method for an IoT gateway cluster based on smart contracts, characterized in that, The method is as follows: Multiple IoT gateways are arranged into a distributed cluster using a Mesh network, with each IoT gateway collecting its own health status in real time. The health status is written into an immutable distributed ledger using a blockchain consensus mechanism, ensuring data trustworthiness; A pre-set fault self-healing smart contract is set up. When any IoT gateway stops reporting its status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract. This means that adjacent healthy IoT gateways with low load are selected, the access devices of the faulty IoT gateway are evenly distributed to the candidate gateways, and the cluster routing table is updated synchronously to guide the devices to switch seamlessly.

2. The self-healing method for IoT gateway clusters based on smart contracts according to claim 1, characterized in that, Each IoT gateway, acting as a Mesh node, has the following functions: ① Connect to the sensing layer devices to achieve data acquisition and protocol conversion; ② Establish wireless or wired Mesh links with adjacent IoT gateways to support data forwarding and status interaction; ③ It has a built-in light blockchain node that participates in cluster consensus and state storage.

3. The self-healing method for IoT gateway clusters based on smart contracts according to claim 1 or 2, characterized in that, Each IoT gateway is equipped with a health status monitoring module. The health status monitoring module is used to monitor and report monitoring data in real time. The monitoring data is synchronized to all IoT gateways in the distributed cluster through heartbeat packets of the Mesh network, ensuring that each gateway node has real-time knowledge of the overall health status of the distributed cluster. The monitoring data includes hardware status, operating status, and fault indicators. Hardware status includes CPU load, memory utilization, and network bandwidth utilization; Operating status includes device access volume, data forwarding success rate, and protocol conversion latency; Fault indicators include abnormal states such as power outage, network outage, and hardware failure.

4. The self-healing method for IoT gateway clusters based on smart contracts according to claim 3, characterized in that, The blockchain consensus mechanism employs a Byzantine fault-tolerant consensus algorithm, writing the health status of IoT gateways into the blockchain ledger in key-value format, as follows: Each IoT gateway acts as a light node in the blockchain, packaging locally collected health status data into status blocks. Three consensus nodes are randomly elected in the distributed cluster to perform consistency verification on the status blocks reported by each IoT gateway; the consistency verification includes verifying whether the CPU load data is within a reasonable range. Once the verification is successful, the status block is written into the distributed ledger and cannot be tampered with, ensuring the credibility of the health status data.

5. The self-healing method for IoT gateway clusters based on smart contracts according to claim 4, characterized in that, The specific triggering conditions for the fault-healing smart contract are as follows: The blockchain ledger has not detected any health status report from any of the specified IoT gateways for three consecutive heartbeat cycles. Any IoT gateway can report a hardware failure or an overload condition with bandwidth utilization exceeding 95%.

6. The self-healing method for IoT gateway clusters based on smart contracts according to claim 5, characterized in that, The execution process of the fault-healing smart contract is as follows: (1) Fault location: The ID, geographical location and list of connected devices of the faulty gateway are confirmed through the blockchain ledger; (2) Health gateway screening: Query the health status of adjacent gateways in the distributed cluster and screen out candidate gateways whose CPU load is lower than the first preset threshold and whose bandwidth utilization is lower than the second preset threshold; where adjacent gateways refer to Mesh link distance ≤ 2 hops; (3) Task allocation: According to the load balancing principle, the access devices of the faulty gateway are evenly distributed to the candidate gateways; Command issuance: The device takeover command is issued to the candidate gateway through the Mesh network. The content of the device takeover command includes the protocol type and data acquisition frequency configuration information of the access device.

7. The self-healing method for IoT gateway clusters based on smart contracts according to claim 6, characterized in that, After receiving the device takeover command, the candidate gateway performs the following operations: (1) Automatically update the local routing table and add the IP address and data forwarding rules of the managed device; (2) Broadcast the updated routing table to all gateways in the distributed cluster via routing synchronization packets to ensure consistency of data forwarding paths; (3) Send a connection switching command to the managed device to guide the device to switch from the faulty gateway to the new gateway. The switching process adopts a seamless handshake mechanism to avoid data loss.

8. A self-healing system for an IoT gateway cluster based on smart contracts, characterized in that, This system is used to implement the smart contract-based self-healing method for IoT gateway clusters as described in any one of claims 1 to 7; the system includes: The gateway cluster module is used to form a distributed cluster of multiple IoT gateways in a Mesh network. Each IoT gateway collects its own health status in real time through the health status monitoring module. The health status monitoring module is deployed in each IoT gateway to monitor and report monitoring data in real time. The monitoring data is synchronized to all IoT gateways in the distributed cluster through heartbeat packets of the Mesh network, ensuring that each gateway node has real-time knowledge of the overall health status of the distributed cluster. The blockchain consensus module is used to write the health status into an immutable distributed ledger using the blockchain consensus mechanism, ensuring data trustworthiness. The smart contract self-healing module is used to preset a fault self-healing smart contract. When any IoT gateway stops reporting its status due to power failure or malfunction, the contract automatically triggers the fault self-healing smart contract. This means selecting adjacent healthy IoT gateways with low load, distributing the access devices of the faulty IoT gateway evenly to the candidate gateways, and synchronously updating the cluster routing table to guide the devices to switch seamlessly. The route update module is used to synchronize routing information and update the local routing table.

9. An electronic device, characterized in that, include: Memory and at least one processor; The memory contains computer programs; The at least one processor executes the computer program stored in the memory, causing the at least one processor to perform the smart contract-based IoT gateway cluster self-healing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed by a processor to implement the smart contract-based self-healing method for IoT gateway clusters as described in any one of claims 1 to 7.

Images