A fault-tolerant method, device, and equipment based on the Internet of Things and a storage medium

Abstract

The application discloses a kind of based on the fault-tolerant method, device and equipment of Internet of Things equipment of Hong Meng and storage medium, the method is by when monitoring equipment passes through the connection authentication request of monitoring network to the same type of new entry equipment is initiated by, based on the local update of multi-edge Internet of Things equipment of Hong Meng operating system Equipment information table independently maintained;Control edge Internet of Things equipment is authenticated each device to other devices sends heartbeat information package, and receives the heartbeat information package sent by other devices, determine the working state of the monitored device in equipment information table, to complete monitoring work;When the working state of the monitored device in equipment information table exists exception, according to the fault type corresponding fault handling process, can realize the efficient fault tolerance of overall monitoring scene, can be flexibly deployed to the scene of multiple Internet of Things equipment, reduces edge device inspection manpower cost, accelerates switching time, reduces the risk of data loss.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a fault-tolerant method, apparatus, device, and storage medium for IoT devices based on HarmonyOS. Background Technology

[0002] IoT devices are typically deployed in complex and ever-changing environments and often need to operate for extended periods, making fault tolerance and reliability crucial. In water conservancy monitoring scenarios, a single dam typically requires multiple devices to perform monitoring tasks with diverse requirements. Traditional fault tolerance mechanisms usually involve backing up the primary and backup devices, allowing the backup device to immediately take over if the primary device fails. However, this approach has the following drawbacks: backup devices typically need to have identical hardware and software configurations to the primary device, resulting in high costs; when the primary device fails, the backup device needs to take over, requiring a switching time that can disrupt normal operation; and backup devices usually need to synchronize with the primary device, necessitating data resynchronization when the backup device takes over, which carries the risk of data loss. Summary of the Invention

[0003] The main objective of this invention is to provide a fault-tolerant method, apparatus, device, and storage medium for IoT devices based on HarmonyOS, aiming to solve the technical problems in the prior art where traditional fault-tolerant mechanisms rely on backup devices, which are costly, require data resynchronization, have long switching times, and pose a risk of data loss.

[0004] In a first aspect, the present invention provides a fault-tolerant method for IoT devices based on HarmonyOS, the fault-tolerant method for IoT devices based on HarmonyOS comprising the following steps:

[0005] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table.

[0006] The system controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receives heartbeat information packets sent by other devices. Based on the heartbeat information packets, the system determines the working status of the monitored device in the device information table to complete the monitoring work.

[0007] When the working status of the monitored equipment in the equipment information table is abnormal, the corresponding fault handling process shall be carried out according to the fault type, and the daily workflow shall be restarted after the handling is completed.

[0008] Optionally, before the multi-edge IoT device based on the HarmonyOS updates its independently maintained device information table locally when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the fault tolerance method for IoT devices based on HarmonyOS further includes:

[0009] When multi-edge IoT devices based on the HarmonyOS operating system are performing daily operations, monitor whether there are similar devices online in the current network.

[0010] After detecting a new device of the same type being powered on, the device registers with the network layer via Bluetooth and establishes a connection between the network layer and the new device.

[0011] Obtain the current device access status and perform the device authentication process based on the current device access status.

[0012] Optionally, the step of obtaining the current device access status and performing a device authentication process based on the current device access status includes:

[0013] Determine whether there is target device information matching the network information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system;

[0014] If the target device information exists in the local device information table, determine that the current device access status is the original device being powered on again, and update the local device information table according to the re-established connection;

[0015] If the target device information exists in the local device information table, the current device access status is determined to be a new device access status;

[0016] After the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

[0017] Optionally, the step of the original device in the multi-edge IoT devices sending an authentication request to the new device and then entering the device authentication process includes:

[0018] Obtain the token information of the original device sent by the newly entered device to the multi-edge IoT device. The token information is the information corresponding to the unique token generated by the newly entered device according to the preset password and MD5 salting method.

[0019] The original device is controlled to verify the token information. If the token information verification fails, the current process is terminated directly, and an error connection information is reported to the server.

[0020] When the token information is verified, an access permission and the device's own resource information are sent to the newly entered device, and the device waits for the newly entered device to reply with resource information.

[0021] Optionally, when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table, including:

[0022] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates the independently maintained device information table.

[0023] Optionally, the step of controlling each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receiving heartbeat information packets sent by other devices, and determining the working status of the monitored device in the device information table based on the heartbeat information packets, in order to complete the monitoring work, includes:

[0024] Based on the local communication signals collected at regular intervals, the working status of sensors, and the memory information stored in each device, a heartbeat information packet is generated. The device controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and to receive heartbeat information packets sent by other devices.

[0025] The heartbeat information packet is parsed to obtain the working status of each monitored device in the device information table.

[0026] Optionally, when the working status of the monitored device in the device information table is abnormal, a corresponding fault handling procedure is performed according to the fault type, and the daily workflow is restarted after the handling is completed, including:

[0027] When the working status of the monitored equipment in the equipment information table is abnormal, the fault type corresponding to the current abnormality is determined;

[0028] When the fault type is abnormal communication signal, the abnormal communication device is powered off and restarted, and the device status of the abnormal communication device is reread.

[0029] When the abnormal communication device returns to normal operation, the fault handling process ends, the error information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts.

[0030] If the abnormal communication device is still abnormal, the sensor data within the preset monitoring period is organized according to the monitoring task, the sensor data is encapsulated into a message, and the encapsulated data message and the proxy work request are sent to the connectable device in the device information table.

[0031] When the fault type is sensor malfunction, the abnormal sensor device is powered off and restarted. If the sensor status is still abnormal after restarting, the sensor malfunction message is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0032] When the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0033] Secondly, to achieve the above objectives, the present invention also proposes a fault-tolerant device for IoT devices based on HarmonyOS, the fault-tolerant device for IoT devices based on HarmonyOS comprising:

[0034] The information table update module is used to locally update the independently maintained device information table of the multi-edge IoT device based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved.

[0035] The monitoring module is used to control each authenticated device in the edge IoT device to send heartbeat information packets to other devices, and to receive heartbeat information packets sent by other devices. Based on the heartbeat information packets, it determines the working status of the monitored device in the device information table to complete the monitoring work.

[0036] The fault handling module is used to perform corresponding fault handling procedures according to the fault type when the working status of the monitored equipment in the equipment information table is abnormal, and to restart the daily workflow after the handling is completed.

[0037] Thirdly, to achieve the above objectives, the present invention also proposes an edge IoT device fault-tolerant device based on the HarmonyOS operating system. The edge IoT device fault-tolerant device based on the HarmonyOS operating system includes: a memory, a processor, and a HarmonyOS-based IoT device fault-tolerant program stored on the memory and executable on the processor. The HarmonyOS-based IoT device fault-tolerant program is configured to implement the steps of the HarmonyOS-based IoT device fault-tolerant method described above.

[0038] Fourthly, to achieve the above objectives, the present invention also proposes a storage medium storing a fault-tolerant program for IoT devices based on HarmonyOS, wherein when the fault-tolerant program for IoT devices based on HarmonyOS is executed by a processor, it implements the steps of the fault-tolerant method for IoT devices based on HarmonyOS as described above.

[0039] This invention proposes a fault-tolerant method for IoT devices based on HarmonyOS. When a monitoring device initiates a connection authentication request to a new, similar device via a monitoring network, the multi-edge IoT devices, based on the HarmonyOS operating system, locally update their independently maintained device information tables. The method controls each authenticated edge IoT device to send heartbeat packets to other devices and receive heartbeat packets from other devices. Based on these heartbeat packets, the working status of the monitored devices in the device information tables is determined to complete the monitoring work. When an abnormality is found in the working status of a monitored device in the device information tables, a corresponding fault handling process is implemented according to the fault type. After handling, the daily workflow restarts. This method enables mutual supervision among multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the communication basis. It has low memory footprint and low power consumption, greatly improving the reliability of monitoring work in harsh environments, reducing the manpower cost of edge device inspection, accelerating switchover time, reducing the risk of data loss, and improving the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention;

[0041] Figure 2 This is a flowchart illustrating the first embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0042] Figure 3 This is a flowchart illustrating the second embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0043] Figure 4 This is a flowchart illustrating the third embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0044] Figure 5 This is a flowchart illustrating the fourth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0045] Figure 6 This is a flowchart illustrating the fifth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0046] Figure 7 This is a flowchart illustrating the sixth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0047] Figure 8 This is a functional block diagram of the first embodiment of the fault-tolerant device for IoT devices based on HarmonyOS according to the present invention.

[0048] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0050] The solution of this invention mainly involves: when a connection authentication request initiated by a monitoring device to a new device of the same type via a monitoring network is approved, the multi-edge IoT devices based on the HarmonyOS operating system locally update their independently maintained device information tables; controlling each authenticated device in the edge IoT devices to send heartbeat packets to other devices and receive heartbeat packets sent by other devices, determining the working status of the monitored devices in the device information table based on the heartbeat packets to complete the monitoring work; when the working status of the monitored devices in the device information table is abnormal, performing corresponding fault handling procedures according to the fault type, and restarting the daily workflow after the handling is completed. It enables mutual supervision among multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the basis for communication. It has a small memory footprint and low power consumption, which greatly improves the reliability of monitoring work in harsh environments, reduces the manpower cost of edge device inspection, speeds up the switching time, reduces the risk of data loss, and improves the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system. It solves the technical problems of traditional fault tolerance mechanisms relying on backup devices, which have high backup device costs, require data resynchronization, have long switching times, and pose a risk of data loss.

[0051] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention.

[0052] like Figure 1As shown, the device may include: a processor 1001, such as a CPU; a communication bus 1002; a user interface 1003; a network interface 1004; and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0053] Those skilled in the art will understand that Figure 1 The device structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0054] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating device, a network communication module, a user interface module, and a fault-tolerant program for IoT devices based on HarmonyOS.

[0055] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and performs the following operations:

[0056] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table.

[0057] The system controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receives heartbeat information packets sent by other devices. Based on the heartbeat information packets, the system determines the working status of the monitored device in the device information table to complete the monitoring work.

[0058] When the working status of the monitored equipment in the equipment information table is abnormal, the corresponding fault handling process shall be carried out according to the fault type, and the daily workflow shall be restarted after the handling is completed.

[0059] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0060] When multi-edge IoT devices based on the HarmonyOS operating system are performing daily operations, monitor whether there are similar devices online in the current network.

[0061] After detecting a new device of the same type being powered on, the device registers with the network layer via Bluetooth and establishes a connection between the network layer and the new device.

[0062] Obtain the current device access status and perform the device authentication process based on the current device access status.

[0063] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0064] Determine whether there is target device information matching the network information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system;

[0065] If the target device information exists in the local device information table, determine that the current device access status is the original device being powered on again, and update the local device information table according to the re-established connection;

[0066] If the target device information exists in the local device information table, the current device access status is determined to be a new device access status;

[0067] After the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

[0068] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0069] Obtain the token information of the original device sent by the newly entered device to the multi-edge IoT device. The token information is the information corresponding to the unique token generated by the newly entered device according to the preset password and MD5 salting method.

[0070] The original device is controlled to verify the token information. If the token information verification fails, the current process is terminated directly, and an error connection information is reported to the server.

[0071] When the token information is verified, an access permission and the device's own resource information are sent to the newly entered device, and the device waits for the newly entered device to reply with resource information.

[0072] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0073] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates the independently maintained device information table.

[0074] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0075] Based on the local communication signals collected at regular intervals, the working status of sensors, and the memory information stored in each device, a heartbeat information packet is generated. The device controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and to receive heartbeat information packets sent by other devices.

[0076] The heartbeat information packet is parsed to obtain the working status of each monitored device in the device information table.

[0077] The device of this invention calls the fault-tolerant program for IoT devices based on HarmonyOS stored in memory 1005 through processor 1001, and also performs the following operations:

[0078] When the working status of the monitored equipment in the equipment information table is abnormal, the fault type corresponding to the current abnormality is determined;

[0079] When the fault type is abnormal communication signal, the abnormal communication device is powered off and restarted, and the device status of the abnormal communication device is reread.

[0080] When the abnormal communication device returns to normal operation, the fault handling process ends, the error information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts.

[0081] If the abnormal communication device is still abnormal, the sensor data within the preset monitoring period is organized according to the monitoring task, the sensor data is encapsulated into a message, and the encapsulated data message and the proxy work request are sent to the connectable device in the device information table.

[0082] When the fault type is sensor malfunction, the abnormal sensor device is powered off and restarted. If the sensor status is still abnormal after restarting, the sensor malfunction message is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0083] When the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0084] This embodiment, through the above-described scheme, updates the independently maintained device information table locally on multiple edge IoT devices based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is successful. It controls each authenticated edge IoT device to send heartbeat packets to other devices and receives heartbeat packets from other devices, determining the working status of the monitored device in the device information table based on the heartbeat packets to complete the monitoring work. When an abnormality is found in the working status of the monitored device in the device information table, a corresponding fault handling process is performed according to the fault type, and the daily workflow restarts after the handling is completed. This enables mutual supervision of multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the communication basis, resulting in small memory footprint and low power consumption. This significantly improves the reliability of monitoring work in harsh environments, reduces the manpower cost of edge device inspection, speeds up switchover time, reduces the risk of data loss, and improves the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0085] Based on the above hardware structure, an embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed.

[0086] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention.

[0087] In the first embodiment, the fault-tolerant method for IoT devices based on HarmonyOS includes the following steps:

[0088] Step S10: When the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS locally updates the independently maintained device information table.

[0089] It should be noted that the monitoring device can perform connection authentication for new devices. When the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the device information table can be updated locally based on the HarmonyOS operating system for multiple IoT devices, that is, the independently maintained device information table is updated locally.

[0090] Step S20: Control each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receive heartbeat information packets sent by other devices. Determine the working status of the monitored device in the device information table based on the heartbeat information packets to complete the monitoring work.

[0091] It is understood that the authenticated devices in the edge IoT device control send heartbeat packets to other devices and receive heartbeat packets sent by other devices. The authenticated devices, while performing daily monitoring work, also act as both monitors and monitored in the network. By sending heartbeat packets to other devices and receiving monitoring from other devices, and by receiving heartbeat information tables from other devices, the monitoring work is completed. The working status of the monitored devices in the device information table is determined based on the heartbeat packets.

[0092] Step S30: When the working status of the monitored device in the device information table is abnormal, perform the corresponding fault handling procedure according to the fault type, and restart the daily workflow after the handling is completed.

[0093] It should be understood that when analyzing the working status, if there is an abnormality in the working status of the monitored equipment in the equipment information table, the corresponding fault handling process can be carried out according to the fault type corresponding to the abnormality, and the daily workflow can be restarted after the handling is completed.

[0094] This embodiment, through the above-described scheme, updates the independently maintained device information table locally on multiple edge IoT devices based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is successful. It controls each authenticated edge IoT device to send heartbeat packets to other devices and receives heartbeat packets from other devices, determining the working status of the monitored device in the device information table based on the heartbeat packets to complete the monitoring work. When an abnormality is found in the working status of the monitored device in the device information table, a corresponding fault handling process is performed according to the fault type, and the daily workflow restarts after the handling is completed. This enables mutual supervision of multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the communication basis, resulting in small memory footprint and low power consumption. This significantly improves the reliability of monitoring work in harsh environments, reduces the manpower cost of edge device inspection, speeds up switchover time, reduces the risk of data loss, and improves the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0095] Furthermore, Figure 3 This is a flowchart illustrating the second embodiment of the fault-tolerant method for IoT devices based on HarmonyOS according to the present invention. Figure 3 As shown, based on the first embodiment, a second embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed. In this embodiment, step S10, the fault-tolerant method for IoT devices based on HarmonyOS, further includes the following steps:

[0096] Step S01: When multi-edge IoT devices based on the HarmonyOS operating system are performing daily operations, monitor whether there are any similar devices online in the current network.

[0097] It should be noted that while the original devices within the network are performing their daily operations, they also monitor whether similar devices are going online in the network. That is, while multi-edge IoT devices based on the HarmonyOS operating system are performing their daily operations, they monitor whether similar devices are going online in the current network.

[0098] Step S02: After detecting a new device of the same type being powered on, register with the network layer via Bluetooth to establish a connection between the network layer and the new device.

[0099] Understandably, after a new device is powered on, it registers with the network layer via Bluetooth to establish a connection between the network layer and the device. That is, after detecting a new device of the same type being powered on, it registers with the network layer via Bluetooth to establish a connection between the network layer and the new device. After the original device detects that a new device is online, it sends a connection request to the new device, and then enters the connection processing flow.

[0100] Step S03: Obtain the current device access status and perform the device authentication process based on the current device access status.

[0101] It should be understood that after obtaining the current access status of the device, the device authentication process can be carried out based on the current access status of the device.

[0102] This embodiment, through the above-described scheme, monitors whether there are any similar devices online in the current network when multiple edge IoT devices based on the HarmonyOS are performing daily operations; after detecting a new device of the same type being powered on, it registers with the network layer via Bluetooth to establish a connection between the network layer and the new device; obtains the current device access status, and performs a device authentication process based on the current device access status, which can quickly perform the device authentication process and improve the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS.

[0103] Furthermore, Figure 4 This is a flowchart illustrating the third embodiment of the fault-tolerant method for IoT devices based on HarmonyOS of the present invention. Figure 4 As shown, based on the second embodiment, a third embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed. In this embodiment, step S03 specifically includes the following steps:

[0104] Step S031: Determine whether there is target device information matching the network information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system.

[0105] It should be noted that after the connection is established, the local device information table is checked based on the network information of the newly added device, that is, to determine whether there is target device information matching the network information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system.

[0106] Step S032: When the target device information exists in the local device information table, determine that the current device access status is the original device power-on status, and update the local device information table according to the re-established connection.

[0107] It is understandable that if the original device is powered on again, the local device information table will be updated based on the newly established connection, and then the normal workflow will resume. That is, if the target device information exists in the local device information table, it can be determined that the current device access status is that the original device is powered on again, and the local device information table can be updated based on the newly established connection.

[0108] Step S033: When the target device information exists in the local device information table, determine that the current device access status is a new device access status.

[0109] It should be understood that when the target device information exists in the local device information table, the current device access status can be determined to be a new device access status. If it is a new connection established by the new device, the original device sends an authentication request to the new device and then enters the device authentication process.

[0110] Step S034: After the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

[0111] It is understandable that the original device sends a connection authentication request to the new device, and then enters the authentication connection process, that is, the original device in the multi-edge IoT device sends an authentication request to the new device and then enters the device authentication process.

[0112] Furthermore, step S034 includes the following steps:

[0113] Obtain the token information of the original device sent by the newly entered device to the multi-edge IoT device. The token information is the information corresponding to the unique token generated by the newly entered device according to the preset password and MD5 salting method.

[0114] The original device is controlled to verify the token information. If the token information verification fails, the current process is terminated directly, and an error connection information is reported to the server.

[0115] When the token information is verified, an access permission and the device's own resource information are sent to the newly entered device, and the device waits for the newly entered device to reply with resource information.

[0116] It should be noted that the new device will read the set password locally, generate a unique token using the MD5 salting method, send the token information to the original device, and wait for the authentication result. After receiving the token information, the original device will verify it. If the verification fails, the process will end directly and report the connection error information to the server. If the original device's token verification is successful, it will send the access permission and its own device resource information to the new device and wait for the new device to reply with resource information. After receiving the access request from the original device, the new device will generate a local device information table, update the information table according to the received resource information from the original device, organize its own resources, and send them to the original device.

[0117] This embodiment, through the above-described scheme, determines whether target device information matching the network information exists in the local device information table of a multi-edge IoT device based on the HarmonyOS operating system; if the target device information exists in the local device information table, it determines that the current device access status is the original device re-powered on, and updates the local device information table according to the re-established connection; if the target device information exists in the local device information table, it determines that the current device access status is the new device access status; after the original device in the multi-edge IoT device sends an authentication request to the new device, it enters the device authentication process, which quickly performs the device authentication process, improving the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0118] Furthermore, Figure 5 This is a flowchart illustrating the fourth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS of the present invention. Figure 5 As shown, based on the first embodiment, a fourth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed. In this embodiment, step S10 specifically includes the following steps:

[0119] Step S11: When the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is successful, the multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates the independently maintained device information table.

[0120] It should be noted that when a monitoring device initiates a connection authentication request to a new device of the same type through the monitoring network and the request is approved, the multi-edge IoT device based on the HarmonyOS operating system receives the resource information of the new device and updates its independently maintained device information table. Generally, after receiving the access application from the original device, the new device can generate a corresponding local device information table, update the information table according to the received resource information of the original device, and organize its own resources and send them to the original device; after receiving the resource information of the new device, the original device updates its local device information table.

[0121] This embodiment, through the above-described scheme, enables multi-edge IoT devices based on the HarmonyOS operating system to update their independently maintained device information tables by receiving the resource information of the newly added device from the monitoring device when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved. This allows for rapid updates to the device information tables and improves the fault tolerance speed and efficiency of edge IoT devices based on the HarmonyOS operating system.

[0122] Furthermore, Figure 6 This is a flowchart illustrating the fifth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS of the present invention. Figure 6 As shown, based on the first embodiment, a fifth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed. In this embodiment, step S20 specifically includes the following steps:

[0123] Step S21: Generate a heartbeat information packet based on the local communication signal collected at regular intervals, the working status of the sensor, and the memory information stored in each device. Control each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receive heartbeat information packets sent by other devices.

[0124] It should be noted that heartbeat information packets are generated based on the local communication signals collected at regular intervals, the working status of sensors, and the memory information stored in each device. This controls the authenticated devices in the edge IoT device to send heartbeat information packets to other devices and to receive heartbeat information packets sent by other devices.

[0125] Step S22: Parse the heartbeat information packet to obtain the working status of each monitored device in the device information table.

[0126] Understandably, after receiving the heartbeat information packets from the devices in the local device information table, the device performs parsing work, and after parsing the heartbeat information packets, obtains the status information of each monitored device.

[0127] This embodiment, through the above-described scheme, generates heartbeat information packets based on periodically collected local communication signals, sensor operating status, and storage memory information of each device. It controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receive heartbeat information packets sent by other devices. The heartbeat information packets are parsed to obtain the operating status of each monitored device in the device information table. This enables mutual supervision of multiple IoT devices in the edge IoT device monitoring scenario, improving the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0128] Furthermore, Figure 7 This is a flowchart illustrating the sixth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS of the present invention. Figure 7 As shown, based on the first embodiment, a sixth embodiment of the fault-tolerant method for IoT devices based on HarmonyOS is proposed. In this embodiment, step S30 specifically includes the following steps:

[0129] Step S31: When the working status of the monitored device in the device information table is abnormal, determine the fault type corresponding to the current abnormality.

[0130] It should be noted that when the working status of the monitored equipment in the device information table is abnormal, the fault type corresponding to the current abnormality can be determined.

[0131] Step S32: When the fault type is abnormal communication signal, control the abnormal communication device to power off and restart, and reread the device status of the abnormal communication device.

[0132] It is understandable that when the fault type is abnormal communication signal, the abnormal communication device can be powered off and restarted, and the device status of the abnormal communication device can be read again.

[0133] Step S33: When the abnormal communication device returns to normal working status, end the fault handling process, assemble the error information into a message according to the preset protocol and send it to the server gateway, and restart the daily workflow.

[0134] It should be understood that when the abnormal communication device returns to normal operation, the fault handling process can be terminated, and the error information can be assembled into a message according to a preset protocol and sent to the server gateway, and the daily workflow can be restarted.

[0135] Step S34: If the abnormal communication device is still abnormal, organize the sensor data within the preset monitoring period according to the monitoring task, encapsulate the sensor data into a message, and send the encapsulated data message and proxy work request to the connectable device in the device information table.

[0136] It is understandable that when the abnormal communication device is still abnormal, the sensor data within the preset monitoring period is organized according to the monitoring task, and then the sensor data is encapsulated into a message. The encapsulated data message and the proxy work request are sent to the connectable device in the device information table.

[0137] Step S35: When the fault type is sensor abnormality, control the abnormal sensor device to power off and restart. If the sensor status is still abnormal after restarting, assemble the sensor abnormality message into a message according to the preset protocol and send it to the server gateway, and restart the daily workflow.

[0138] It should be understood that when the fault type is sensor malfunction, the malfunctioning sensor device can be powered off and restarted. If the sensor status is still abnormal after restarting, the sensor malfunction message will be assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow will restart.

[0139] Step S36: When the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0140] It is understood that when the fault type is storage or memory abnormality, the storage or memory abnormality information can be assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow can be restarted.

[0141] In the implementation, the original device waits to monitor similar devices. When a new device registers and enters the network, the original device checks the status of the new device. If the new device exists in the device information table, it updates the device information table. If the new device does not exist, it initiates an authentication request to the new device. After receiving the authentication request, the new device generates a token using the set password and MD5 salting method and sends it back to the original device to wait for the verification result. If the verification fails, the original device reports the device information to the server and ends the authentication process. If the verification succeeds, it sends an access application and its own device resource information to the new device. After receiving the access application, the new device receives the resource information from the original device, generates its own device information table, organizes the device resource information, and sends it to the original device. After receiving the information, the original device updates its device information table and then enters the daily workflow. All devices periodically send heartbeat information to the devices in the device information table and wait to receive heartbeat information from other devices. If the heartbeat information indicates that the device is working normally, it returns to the daily workflow. If the heartbeat information indicates that the device is working abnormally, it enters the fault handling process and then returns to the daily workflow.

[0142] The specific steps are explained below:

[0143] A1. While performing its daily operations, the original device within the network monitors for the online presence of similar devices. Upon powering on a new device, it registers with the network layer via Bluetooth, establishing a connection between the network layer and the device. After detecting a new device online, the original device sends a connection request to it. The connection processing then proceeds as follows:

[0144] A11. After the connection is established, check the local device information table based on the network information of the new device to determine whether the new device is the same as the original device that has been powered on again.

[0145] A12. If the original device is powered on again, update the local device information table according to the newly established connection, and then re-enter the daily workflow (see A3 for specific steps);

[0146] A13. If it is a new connection established by a newly entered device, the original device will send an authentication request to the newly entered device and then enter the device authentication process;

[0147] A2. The original device sends a connection authentication request to the new device, and then begins the authentication connection process. A2 specifically includes the following sub-steps:

[0148] A21. For a newly installed device, the system reads the set password locally, generates a unique token using the MD5 salting method, sends the token information to the original device, and waits for the authentication result.

[0149] A22. After receiving the token information, the original device performs verification. If the verification fails, the process ends directly and the error connection information is reported to the server.

[0150] A23. If the original device's token verification is successful, send the access permission and its own device resource information to the new device, and wait for the new device to reply with resource information;

[0151] A23. After receiving the access application from the original equipment, the new equipment generates a local equipment information table, updates the information table according to the received resource information of the original equipment, organizes its own resources and sends them to the original equipment.

[0152] A24. After receiving the resource information of the new device, the original device updates the local device information table, and then the new device and the original device enter the daily workflow (see A3 for specific steps);

[0153] A3. The equipment enters its daily workflow, and its main tasks include:

[0154] A31. Timed sensor data acquisition: According to the set monitoring task, the corresponding data is collected at regular intervals, and the preliminary processing and threshold judgment of the collected data are completed. If the threshold judgment is exceeded, the additional reporting work is initiated (see A33 for specific steps).

[0155] A32. Scheduled data reporting: Organize the data collected in the set time period, package it according to the standard protocol and report it to the server, and send heartbeat packets to the server at regular intervals;

[0156] A33. Emergency Reporting: When the data collected by the sensor exceeds the set threshold, the collected data is encapsulated according to the reporting format and sent to the server as an emergency report.

[0157] A34. Generate heartbeat information periodically. While completing the monitoring work, periodically collect local 4G communication signals, sensor working status and device storage and memory information, generate heartbeat messages, send heartbeat messages to the device stored in the local device information, and wait to receive heartbeat messages before entering the fault detection process (see A4 for specific steps).

[0158] A4. After receiving the heartbeat information packet from the device in the local device information table, the device performs parsing to obtain the status information of the monitored device, mainly including:

[0159] A41.4G signal strength: If the 4G signal strength of the monitored device cannot meet the communication requirements between the device and the server, the fault handling process will be initiated (see A51 to A53 for specific steps).

[0160] A42. Sensor operating status: If the sensor operating status of the monitored device is abnormal, or the collected data is abnormal, the fault handling process will be initiated (see A51 for specific steps).

[0161] A43. Monitoring device storage and memory information. If a memory or storage space alarm is triggered, the fault handling termination process will begin (see A6 for specific steps).

[0162] A44. After completing the parsing of the heartbeat information packet, if the corresponding content is normal, update the monitoring information of the corresponding device in the local device information table. At the same time, check the local device information table to find if there are any devices that have not been updated for a long time. If so, proceed to the fault handling process (see A54 for specific steps).

[0163] A45. After completing the fault detection work, if the equipment is normal, restart the daily work process (see A3 for details);

[0164] A5. If the monitored equipment is in an abnormal state, the fault handling procedure will be initiated, and corresponding operations will be performed according to different abnormal states. Specific details include:

[0165] A51. The corresponding device is powered off and restarted. After the power off and restart operation is completed, the status of the corresponding device is read again. If the device returns to normal working status, the device ends the fault handling and restarts the daily workflow. If the device working status is still abnormal, the device type is determined. If the problem is with the 4G signal, A52 is started, and other devices start A53.

[0166] The A52.4G communication module still has problems. According to the monitoring task, it organizes the sensor data collected during the monitoring period, completes the message encapsulation work according to the standard protocol, and then sends the proxy work request and the encapsulated data message to the connectable devices in the local device information table.

[0167] A53. After troubleshooting the equipment, proceed to the troubleshooting completion process (see A6 for details). A54. If a device has not been updated for an extended period, the original device will send a reconnection request to the unupdated device.

[0168] A55. If the unupdated device is still online and can receive reconnection requests, repeat step A4;

[0169] A56. If the monitoring equipment does not receive repeated information from outdated devices for an extended period of time, update the local device information table and then proceed with the fault handling termination process (see A6 for specific steps).

[0170] A6. Fault Handling Completion Procedure. The specific process is as follows:

[0171] A61. Assemble the specific error information into a message according to the set protocol and send it to the server gateway;

[0172] A62. Continuously repeat the A3 workflow.

[0173] This embodiment, through the above scheme, determines the fault type corresponding to the current abnormality when the working status of the monitored device in the device information table is abnormal; when the fault type is communication signal abnormality, the abnormal communication device is controlled to power off and restart, and the device status of the abnormal communication device is reread; when the abnormal communication device returns to normal working status, the fault handling process ends, the error information is assembled into a message according to a preset protocol and sent to the server gateway, and the daily workflow restarts; when the abnormal communication device is still abnormal, sensor data within a preset monitoring period is organized according to the monitoring task, the sensor data is encapsulated into a message, and the encapsulated data message and proxy work request are sent to the connectable device in the device information table; when the fault type is sensor abnormality, the abnormal sensor device is controlled to power off and restart, and the device status of the abnormal communication device is reread. If the sensor status remains abnormal after restarting, the sensor abnormality message is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts. If the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts. This enables mutual supervision of multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the communication basis, with small memory footprint and low power consumption, greatly improving the reliability of monitoring work in harsh environments, reducing the manpower cost of edge device inspection, speeding up switchover time, reducing the risk of data loss, and improving the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0174] Accordingly, the present invention further provides a fault-tolerant device for Internet of Things devices based on HarmonyOS.

[0175] Reference Figure 8 , Figure 8 This is a functional block diagram of the first embodiment of the fault-tolerant device for IoT devices based on HarmonyOS according to the present invention.

[0176] In the first embodiment of the fault-tolerant device for IoT devices based on HarmonyOS of the present invention, the fault-tolerant device for IoT devices based on HarmonyOS includes:

[0177] The information table update module 10 is used to locally update the independently maintained device information table of the multi-edge IoT device based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved.

[0178] The monitoring module 20 is used to control each authenticated device in the edge IoT device to send heartbeat information packets to other devices, and to receive heartbeat information packets sent by other devices. Based on the heartbeat information packets, it determines the working status of the monitored device in the device information table to complete the monitoring work.

[0179] The fault handling module 30 is used to perform corresponding fault handling procedures according to the fault type when the working status of the monitored equipment in the equipment information table is abnormal, and restart the daily workflow after the handling is completed.

[0180] The information table update module 10 is also used to monitor whether there are any devices of the same type online in the current network when the multi-edge IoT devices based on the HarmonyOS operating system are performing daily work; after detecting that a new device of the same type is powered on, it registers with the network layer via Bluetooth to establish a connection between the network layer and the new device; obtains the current device access status, and performs a device authentication process based on the current device access status.

[0181] The information table update module 10 is further configured to determine whether there is target device information matching the network information in the local device information table of the multi-edge IoT device based on the HarmonyOS operating system; when the target device information exists in the local device information table, the current device access status is determined to be the original device power-on status, and the local device information table is updated according to the re-established connection; when the target device information exists in the local device information table, the current device access status is determined to be the new device access status; after the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

[0182] The information table update module 10 is further configured to obtain the token information of the original device sent by the new device to the multi-edge IoT devices, wherein the token information is the information corresponding to the unique token generated by the new device according to the preset password and MD5 salting method; control the original device to verify the token information, and if the token information verification fails, directly end the current process and report the error connection information to the server; if the token information verification passes, send the access permission and its own device resource information to the new device, and wait for the new device to reply with resource information.

[0183] The information table update module 10 is also used to update the independently maintained device information table when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is successful. The multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates it.

[0184] The monitoring module 20 is also used to generate heartbeat information packets based on the local communication signals collected periodically, the working status of sensors, and the memory information stored in each device; control each authenticated device in the edge IoT device to send heartbeat information packets to other devices; and receive heartbeat information packets sent by other devices; and parse the heartbeat information packets to obtain the working status of each monitored device in the device information table.

[0185] The monitoring module 20 is further configured to: determine the fault type corresponding to the current abnormality when the working status of the monitored device in the device information table is abnormal; control the abnormal communication device to power off and restart when the fault type is communication signal abnormality, and reread the device status of the abnormal communication device; end the fault handling process when the abnormal communication device returns to normal working status, assemble the error information into a message according to a preset protocol and send it to the server gateway, and restart the daily workflow; when the abnormal communication device is still abnormal, organize the sensor data within a preset monitoring period according to the monitoring task, encapsulate the sensor data into a message, and send the encapsulated data message and proxy work request to the connectable device in the device information table; control the abnormal sensor device to power off and restart when the sensor status is still abnormal after restarting, assemble the sensor abnormal message into a message according to the preset protocol and send it to the server gateway, and restart the daily workflow; and assemble the storage or memory abnormal information into a message according to the preset protocol and send it to the server gateway, and restart the daily workflow when the fault type is storage or memory abnormality.

[0186] The steps for implementing each functional module of the fault-tolerant device for IoT devices based on HarmonyOS can be referred to in the various embodiments of the fault-tolerant method for IoT devices based on HarmonyOS of the present invention, and will not be repeated here.

[0187] Furthermore, this embodiment of the invention also proposes a storage medium storing a fault-tolerant program for IoT devices based on HarmonyOS. When the fault-tolerant program for IoT devices based on HarmonyOS is executed by a processor, it performs the following operations:

[0188] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table.

[0189] The system controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receives heartbeat information packets sent by other devices. Based on the heartbeat information packets, the system determines the working status of the monitored device in the device information table to complete the monitoring work.

[0190] When the working status of the monitored equipment in the equipment information table is abnormal, the corresponding fault handling process shall be carried out according to the fault type, and the daily workflow shall be restarted after the handling is completed.

[0191] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0192] When multi-edge IoT devices based on the HarmonyOS operating system are performing daily operations, monitor whether there are similar devices online in the current network.

[0193] After detecting a new device of the same type being powered on, the device registers with the network layer via Bluetooth and establishes a connection between the network layer and the new device.

[0194] Obtain the current device access status and perform the device authentication process based on the current device access status.

[0195] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0196] Determine whether there is target device information matching the network information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system;

[0197] If the target device information exists in the local device information table, determine that the current device access status is the original device being powered on again, and update the local device information table according to the re-established connection;

[0198] If the target device information exists in the local device information table, the current device access status is determined to be a new device access status;

[0199] After the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

[0200] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0201] Obtain the token information of the original device sent by the newly entered device to the multi-edge IoT device. The token information is the information corresponding to the unique token generated by the newly entered device according to the preset password and MD5 salting method.

[0202] The original device is controlled to verify the token information. If the token information verification fails, the current process is terminated directly, and an error connection information is reported to the server.

[0203] When the token information is verified, an access permission and the device's own resource information are sent to the newly entered device, and the device waits for the newly entered device to reply with resource information.

[0204] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0205] When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates the independently maintained device information table.

[0206] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0207] Based on the local communication signals collected at regular intervals, the working status of sensors, and the memory information stored in each device, a heartbeat information packet is generated. The device controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and to receive heartbeat information packets sent by other devices.

[0208] The heartbeat information packet is parsed to obtain the working status of each monitored device in the device information table.

[0209] Furthermore, when the HarmonyOS-based IoT device fault-tolerant program is executed by the processor, it also performs the following operations:

[0210] When the working status of the monitored equipment in the equipment information table is abnormal, the fault type corresponding to the current abnormality is determined;

[0211] When the fault type is abnormal communication signal, the abnormal communication device is powered off and restarted, and the device status of the abnormal communication device is reread.

[0212] When the abnormal communication device returns to normal operation, the fault handling process ends, the error information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts.

[0213] If the abnormal communication device is still abnormal, the sensor data within the preset monitoring period is organized according to the monitoring task, the sensor data is encapsulated into a message, and the encapsulated data message and the proxy work request are sent to the connectable device in the device information table.

[0214] When the fault type is sensor malfunction, the abnormal sensor device is powered off and restarted. If the sensor status is still abnormal after restarting, the sensor malfunction message is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0215] When the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

[0216] This embodiment, through the above-described scheme, updates the independently maintained device information table locally on multiple edge IoT devices based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is successful. It controls each authenticated edge IoT device to send heartbeat packets to other devices and receives heartbeat packets from other devices, determining the working status of the monitored device in the device information table based on the heartbeat packets to complete the monitoring work. When an abnormality is found in the working status of the monitored device in the device information table, a corresponding fault handling process is performed according to the fault type, and the daily workflow restarts after the handling is completed. This enables mutual supervision of multiple IoT devices in edge IoT device monitoring scenarios, thereby achieving efficient fault tolerance for the overall monitoring scenario. It can be flexibly deployed in scenarios with multiple IoT devices, using a lightweight application layer protocol as the communication basis, resulting in small memory footprint and low power consumption. This significantly improves the reliability of monitoring work in harsh environments, reduces the manpower cost of edge device inspection, speeds up switchover time, reduces the risk of data loss, and improves the speed and efficiency of fault tolerance for edge IoT devices based on the HarmonyOS operating system.

[0217] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0218] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0219] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A fault-tolerant method for IoT devices based on HarmonyOS, characterized in that, The fault-tolerant method for IoT devices based on HarmonyOS includes: When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table. The system controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and receives heartbeat information packets sent by other devices. Based on the heartbeat information packets, the system determines the working status of the monitored device in the device information table to complete the monitoring work. When the working status of the monitored equipment in the equipment information table is abnormal, the corresponding fault handling process shall be carried out according to the fault type, and the daily workflow shall be restarted after the handling is completed. The fault-tolerant method for IoT devices based on HarmonyOS further includes the following: Before the multi-edge IoT device based on HarmonyOS locally updates its independently maintained device information table when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the method also includes the following: When multi-edge IoT devices based on the HarmonyOS operating system are performing daily operations, monitor whether there are similar devices online in the current network. After detecting a new device of the same type being powered on, the device registers with the network layer via Bluetooth and establishes a connection between the network layer and the new device. Obtain the current device access status and perform the device authentication process based on the current device access status.

2. The fault-tolerant method for IoT devices based on HarmonyOS as described in claim 1, characterized in that, The process of obtaining the current device access status and performing device authentication based on the current device access status includes: Determine whether there is target device information in the local device information table of multi-edge IoT devices based on the HarmonyOS operating system that matches the network information of the newly added device; If the target device information exists in the local device information table, determine that the current device access status is the original device being powered on again, and update the local device information table according to the re-established connection; If the target device information exists in the local device information table, the current device access status is determined to be a new device access status; After the original device in the multi-edge IoT device sends an authentication request to the new device, the device authentication process begins.

3. The fault-tolerant method for IoT devices based on HarmonyOS as described in claim 2, characterized in that, The process of sending an authentication request from the original device in the multi-edge IoT devices to the new device and then entering the device authentication process includes: Obtain the token information of the original device sent by the newly entered device to the multi-edge IoT device. The token information is the information corresponding to the unique token generated by the newly entered device according to the preset password and MD5 salting method. The original device is controlled to verify the token information. If the token information verification fails, the current process is terminated directly, and an error connection information is reported to the server. When the token information is verified, an access permission and the device's own resource information are sent to the newly entered device, and the device waits for the newly entered device to reply with resource information.

4. The fault-tolerant method for IoT devices based on HarmonyOS as described in claim 1, characterized in that, When the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system locally updates its independently maintained device information table, including: When a connection authentication request initiated by a monitoring device to a new device of the same type through the monitoring network is approved, the multi-edge IoT device based on the HarmonyOS operating system receives the new device resource information fed back by the new device and updates the independently maintained device information table.

5. The fault-tolerant method for IoT devices based on HarmonyOS as described in claim 1, characterized in that, The control system manages each authenticated device in the edge IoT device to send heartbeat packets to other devices and receives heartbeat packets from other devices. Based on the heartbeat packets, it determines the operating status of the monitored device in the device information table to complete the monitoring work, including: Based on the locally collected communication signals, sensor operating status, and memory information stored in each device, a heartbeat information packet is generated. The device controls each authenticated device in the edge IoT device to send heartbeat information packets to other devices and to receive heartbeat information packets sent by other devices. The heartbeat information packet is parsed to obtain the working status of each monitored device in the device information table.

6. The fault-tolerant method for IoT devices based on HarmonyOS as described in claim 1, characterized in that, When the working status of the monitored equipment in the equipment information table is abnormal, a corresponding fault handling procedure is performed according to the fault type, and the daily workflow is restarted after the handling is completed, including: When the working status of the monitored equipment in the equipment information table is abnormal, the fault type corresponding to the current abnormality is determined; When the fault type is abnormal communication signal, the abnormal communication device is powered off and restarted, and the device status of the abnormal communication device is reread. When the abnormal communication device returns to normal operation, the fault handling process ends, the error information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow restarts. If the abnormal communication device is still abnormal, the sensor data within the preset monitoring period is organized according to the monitoring task, the sensor data is encapsulated into a message, and the encapsulated data message and the proxy work request are sent to the connectable device in the device information table. When the fault type is sensor malfunction, the abnormal sensor device is powered off and restarted. If the sensor status is still abnormal after restarting, the sensor malfunction message is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted. When the fault type is storage or memory abnormality, the storage or memory abnormality information is assembled into a message according to the preset protocol and sent to the server gateway, and the daily workflow is restarted.

7. A fault-tolerant device for IoT devices based on HarmonyOS, characterized in that, The fault-tolerant device for IoT devices based on HarmonyOS includes: The information table update module is used to locally update the independently maintained device information table of the multi-edge IoT device based on the HarmonyOS operating system when the connection authentication request initiated by the monitoring device to a new device of the same type through the monitoring network is approved. The monitoring module is used to control each authenticated device in the edge IoT device to send heartbeat information packets to other devices, and to receive heartbeat information packets sent by other devices. Based on the heartbeat information packets, it determines the working status of the monitored device in the device information table to complete the monitoring work. The fault handling module is used to perform corresponding fault handling procedures according to the fault type when the working status of the monitored equipment in the equipment information table is abnormal, and restart the daily workflow after the handling is completed. The information table update module is also used to monitor whether there are any devices of the same type online in the current network when the multi-edge IoT devices based on the HarmonyOS operating system are performing daily work; after detecting that a new device of the same type has been powered on, it registers with the network layer via Bluetooth to establish a connection between the network layer and the new device; obtains the current device access status, and performs a device authentication process based on the current device access status.

8. A fault-tolerant edge IoT device based on the HarmonyOS operating system, characterized in that, The edge IoT device fault-tolerant device based on the HarmonyOS operating system includes: a memory, a processor, and a HarmonyOS-based IoT device fault-tolerant program stored on the memory and executable on the processor. The HarmonyOS-based IoT device fault-tolerant program is configured to implement the steps of the HarmonyOS-based IoT device fault-tolerant method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a fault-tolerant program for IoT devices based on HarmonyOS. When the processor executes the fault-tolerant program for IoT devices based on HarmonyOS, it implements the steps of the fault-tolerant method for IoT devices based on HarmonyOS as described in any one of claims 1 to 6.

Images