Offline fault diagnosis method, device and electronic equipment for Internet of Things equipment

Abstract

The present application provides an offline fault diagnosis method, device and electronic device for IoT devices. The embodiment of the present application diagnoses offline faults of IoT devices based on a fault diagnosis decision tree model, which can automatically, intelligently, accurately and timely analyze the root cause of the device offline fault, helping users to quickly learn about the health status of the device, find out the cause and respond in time.

Description

Technical Field

[0001] The present application relates to Internet of Things technology, and in particular to an offline fault diagnosis method, device and electronic device for Internet of Things equipment. Background Art

[0002] In IoT applications, IoT devices often experience offline failures during operation. Taking the IoT device as a camera as an example, the offline failure can be manifested as: power failure, network disconnection, continuous restart due to device bitstream format problems, and duplicate IP address planning segments.

[0003] However, once an IoT device fails offline, it often requires a lot of manpower and time to troubleshoot and locate the problem, which makes troubleshooting time-consuming and difficult. Summary of the invention

[0004] The present application provides an offline fault diagnosis method, apparatus and electronic device for an IoT device to avoid problems caused by manual troubleshooting and locating when an IoT device has an offline fault.

[0005] The present invention provides an offline fault diagnosis method for an IoT device, the method comprising:

[0006] When it is detected that the target IoT device is offline, firstly obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model; the target point is the point associated with the target IoT device;

[0007] When the current online state of the target point is online, the fault diagnosis decision tree model is used to diagnose that the preliminary fault cause causing the target IoT device to go offline is the fault of the target IoT device, and then a feature vector required for verifying the preliminary fault cause through the fault diagnosis decision tree model is obtained, and the first target fault cause causing the target IoT device to go offline is determined by analyzing the feature vector through the fault diagnosis decision tree model;

[0008] When the current online status of the target point is offline, the current online status of the target power point required for further offline fault diagnosis by the fault diagnosis decision tree model is obtained, and the target power point is the power point associated with the target point; the second target fault cause causing the target Internet of Things device to go offline is determined by analyzing the current online status of the target power point through the fault diagnosis decision tree model.

[0009] The present application also provides an offline fault diagnosis device for an IoT device, the device comprising:

[0010] A data acquisition unit is used to first obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model when detecting that the target IoT device is offline; the target point is a point associated with the target IoT device;

[0011] a fault diagnosis unit, configured to, when the current online state of the target point is online, diagnose that the preliminary fault cause causing the target IoT device to be offline is a fault of the target IoT device by using the fault diagnosis decision tree model, and then trigger the data acquisition unit to obtain a feature vector required for verifying the preliminary fault cause by using the fault diagnosis decision tree model; and

[0012] Analyzing the feature vector by the fault diagnosis decision tree model to determine the first target fault cause that causes the target IoT device to go offline; and

[0013] When the current online status of the target point is offline, the data acquisition unit is triggered to obtain the current online status of the target power point required for the fault diagnosis decision tree model to further perform offline fault diagnosis. The target power point is the power point associated with the target point, and the current online status of the target power point is analyzed by the fault diagnosis decision tree model to determine the second target fault cause that caused the target Internet of Things device to go offline.

[0014] The embodiment of the present application also provides an electronic device. The electronic device includes: a processor and a machine-readable storage medium;

[0015] The machine-readable storage medium stores machine-executable instructions that can be executed by the processor;

[0016] The processor is used to execute machine executable instructions to implement the steps of the above disclosed method.

[0017] It can be seen from the above technical solutions that the embodiment of the present application diagnoses offline faults of IoT devices based on the fault diagnosis decision tree model, which can realize automatic, intelligent, accurate and timely analysis of the root causes of device offline faults, helping users to quickly understand the health status of the device, find out the cause, and respond in time.

[0018] Furthermore, in this embodiment, the offline faults of IoT devices can be intelligently and automatically diagnosed through the fault diagnosis decision tree model, which can improve work efficiency, effectively reduce the manpower input of operation and maintenance personnel, reduce operation and maintenance costs, and is of great significance for resource planning. It also reduces the safety or reputation losses caused by unsatisfactory operation and maintenance during key activities. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0020] Figure 1 A flow chart of the method provided in the embodiment of the present application;

[0021] Figure 2 A schematic diagram of a fault diagnosis decision tree model provided in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of the association between the IoT device, point, and power supply point provided in the embodiment of the present application;

[0023] Figure 4 A schematic diagram of a power point within X meters of a target point provided in an embodiment of the present application;

[0024] Figure 5 A structural diagram of a device provided in an embodiment of the present application;

[0025] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0027] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0028] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and understandable, the technical solutions in the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings.

[0029] The embodiment of the present application generates a fault diagnosis decision tree model by integrating multidimensional data based on expert experience learned from historical fault work orders, and performs offline fault diagnosis on the fault that occurs when the IoT device is offline at time T, so that the operation and maintenance personnel can effectively "control" the health status of the IoT device within the (-∞,T] time interval in its life cycle. Optionally, the above multidimensional data, such as the online status of the IoT device, the online status of the target point associated with the IoT device, the online status of the target power point associated with the target point, the power supply notification, the number of normal / abnormal power points within X meters of the target point, the number of network disconnections / power outages in historical work orders, the number of status changes on the day, the amount of captured data, VQD results, video recording results, etc., are not specifically limited in this embodiment. The following is combined with Figure 1 Describe the method provided in the embodiments of the present application;

[0030] See also Figure 1 , Figure 1 The method flow chart provided in the embodiment of the present application. As an embodiment, Figure 1 The method shown is applied to an IoT device management platform or a backend server, etc., and is not specifically limited in this embodiment.

[0031] like Figure 1 As shown, the process may include the following steps:

[0032] Step 101, when it is detected that the target IoT device is offline, first obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model.

[0033] As described above, the embodiment of the present application generates a fault diagnosis decision tree model by integrating multi-dimensional data and following a decision tree algorithm through expert experience learned based on historical fault work orders. Figure 2 The fault diagnosis decision tree model is shown by example. The following will describe how to generate the fault diagnosis decision tree model by example, which will not be described here.

[0034] After the fault diagnosis decision tree model is established, it is applied to this step 101. The fault diagnosis decision tree model can be analyzed first, and it is found that when the target IoT device is detected to be offline, the current online status of the target point needs to be obtained first. In this embodiment, the target point is the point associated with the target IoT device. Here, the so-called point refers to the deployment location of the IoT device, such as the pole set at the intersection (it should be noted that multiple different IoT devices can be deployed on a pole), etc., which is not specifically limited in this embodiment. Based on this, as described in step 101, when the target IoT device is currently detected to be offline, the current online status of the target point associated with the target IoT device is first obtained.

[0035] Optionally, in one example, the current online status of the target point associated with the target IoT device can be determined by the following steps: determining all IoT devices associated with the target point (at least including the above-mentioned target IoT device); when the current online status of at least one IoT device associated with the target point is online, determining the current online status of the target point is online; otherwise, determining the current online status of the target point is offline. Figure 3 As shown, for example, devices D1...Di are distributed in point P1, wherein one of the devices D1...Di is a target IoT device, and point P1 is the target point. If all devices D1...Di are offline, then the target point, i.e., point P1, is considered offline. On the contrary, if at least one of the devices D1...Di is online, then the target point, i.e., point P1, is considered online.

[0036] After the current online status of the target point is obtained, the following step 102 is performed.

[0037] Step 102, identifying the current online status of the target point as online or offline, if it is online, executing step 103, if it is offline, executing step 104.

[0038] Step 103, diagnose the preliminary fault cause that causes the target IoT device to go offline as a target IoT device fault through the fault diagnosis decision tree model, then obtain the feature vector required to verify the preliminary fault cause through the fault diagnosis decision tree model, and determine the first target fault cause that causes the target IoT device to go offline by analyzing the feature vector through the fault diagnosis decision tree model.

[0039] This step 103 is executed when it is determined that the current online state of the target point is online. When the current online state of the target point is online, it also means that the area where the target IoT device is located is normal, and if the target IoT device is offline at this time, it is likely that the target IoT device itself is faulty, so the preliminary fault cause that causes the target IoT device to be offline is diagnosed as a target IoT device fault through the fault diagnosis decision tree model. As for whether the preliminary fault cause diagnosed is the real target fault cause, it is also necessary to verify the preliminary fault cause through the fault diagnosis decision tree model. By analyzing the fault diagnosis decision tree model, it is necessary to obtain the feature vector required for verifying the preliminary fault cause through the fault diagnosis decision tree model.

[0040] Optionally, in this embodiment, the feature vector may include: a first sub-vector. The first sub-vector includes at least: the number of state changes of the target IoT device within a specified historical period, and the workload of the target IoT device within the specified historical period when the number of state changes is less than or equal to a first set number threshold.

[0041] In this embodiment, the above-mentioned number of state changes includes the number of changes from online to offline, and from offline to online. Optionally, in this embodiment, the online state of the target IoT device (including online or offline, for example, online is represented by "1", and offline is represented by "0") is collected periodically or regularly. Based on this, the above-mentioned number of state changes can be calculated based on the online state of the target IoT device collected at each collection point (i.e., timestamp) within the specified historical time period (including online or offline, for example, online is represented by "1", and offline is represented by "0"), and finally the number of state changes of the above-mentioned target IoT device within the specified historical time period is obtained.

[0042] In this embodiment, the workload is specifically the amount of data generated when the target IoT device works during the specified historical duration. For example, when the target IoT device is a camera, the workload may be the amount of captured data.

[0043] Optionally, in this embodiment, the feature vector may also be a second sub-vector. In one example, the second sub-vector includes at least: the number of state changes of the target IoT device within a specified historical period, and the working condition of the target IoT device within the specified historical period when the number of state changes is greater than or equal to a second set number threshold.

[0044] Among them, the number of state changes is described above and will not be repeated here. As for the working condition, it is specifically the data generated when the target IoT device works during the above-specified historical duration. For example, when the target IoT device is a camera, the working condition is the video quality of the recorded video (which can be obtained by merging and calculating the video recorded within the specified historical duration).

[0045] It should be noted that, in this embodiment, the second set number threshold is greater than the first set number threshold, for example, the first set number threshold is 0, and the second set number threshold is 10. In addition, it should be noted that in the above description, the specified historical duration can be set according to actual needs, such as setting it to the past day.

[0046] Based on the above description that the feature vector is the first sub-vector, the first target fault cause that causes the target IoT device to go offline can be determined by analyzing the feature vector through the fault diagnosis decision tree model in step 103, including: analyzing whether the workload of the target IoT device in the first sub-vector within the specified historical time length is greater than the workload threshold according to the fault diagnosis decision tree model. Once it is analyzed that the workload of the target IoT device within the specified historical time length is greater than the workload threshold, such as 0, it means that the target IoT device is not faulty at this time, and it may be a service link failure connected to the target IoT device. Based on this, it can be determined that the first target fault cause is a service link failure connected to the target IoT device. If the workload of the target IoT device within the specified historical time length is less than or equal to the workload threshold, such as the workload is equal to 0, in this case, it can be further determined that the first target fault cause is indeed a target IoT device failure. Finally, when the feature vector is the first sub-vector, the first target fault cause that causes the target IoT device to go offline is determined.

[0047] Similarly, when the feature vector is the second sub-vector, the above step 103 may include analyzing the feature vector through the fault diagnosis decision tree model to determine the first target fault cause that causes the target IoT device to go offline, including: analyzing whether the working condition of the target IoT device in the second sub-vector within the specified historical time period is a normal working condition according to the fault diagnosis decision tree model. Once the working condition of the target IoT device within the specified historical time period is analyzed to be a normal working condition, it means that the target IoT device has no fault at this time and can continue to work. The reason for going offline may be that the IP address of the target IoT device conflicts with the IP address of other IoT devices. Based on this, it can be determined that the first target fault cause is that the IP address of the target IoT device conflicts with the IP address of other IoT devices. If it is analyzed that the working condition of the target IoT device within the specified historical time period is an abnormal working condition such as video recording interruption, in this case, it means that the target IoT device has no fault at this time and can continue to work. The reason for going offline, combined with the above abnormal working conditions such as video recording interruption, can be inferred that the network link of the target IoT device is unstable. Based on this, it can be directly determined that the first target fault cause is the unstable network link of the target IoT device. Finally, when the feature vector is the second sub-vector, the first target fault cause causing the target IoT device to go offline is determined.

[0048] Step 104, obtain the current online status of the target power point required for further offline fault diagnosis by the fault diagnosis decision tree model, and analyze the current online status of the target power point through the fault diagnosis decision tree model to determine the second target fault cause that caused the target IoT device to go offline.

[0049] This step 104 is performed when it is determined that the current online status of the target point is offline. When the current online status of the target point is offline, it also means that all IoT devices in the target point may have the same offline fault cause, such as Figure 3 The point P1 shown is offline, then the devices D1...Di in the point P1 may have the same offline fault cause. As for the specific offline fault cause, it is necessary to obtain the current online status of the target power point required for further offline fault diagnosis by the fault diagnosis decision tree model. In this embodiment, the target power point is the power point associated with the target point. Here, the so-called power point is a component such as a power supply that supplies power to the Internet of Things devices deployed at a point within a specified distance, and this embodiment does not specifically limit it.

[0050] As an embodiment, the current online status of the target power point can be determined by the following steps: determine all points associated with the target power point (at least including the target point), and when the current online status of at least one point associated with the target power point is online, determine the current online status of the target power point as online; otherwise, determine the current online status of the target power point as offline. Figure 3 As shown, power point E1 supplies power to all devices in points P1...Pj, then points P1...Pj are considered to be associated with power point E1. If the above-mentioned target point is one of points P1...Pj, then power point E1 is the target power point. If points P1...Pj are all offline, then the target power point, i.e., power point E1, is considered to be offline. Conversely, if at least one of points P1...Pj is online, then the target power point, i.e., power point E1, is considered to be online.

[0051] Optionally, in this embodiment, when analyzing the current online status of the target power point through the fault diagnosis decision tree model in the above step 104 to determine the second target fault cause that causes the target IoT device to go offline, it is necessary to subdivide the current online status of the target power point into online or offline.

[0052] Among them, when the current online status of the target power point is online, if there are no other power points within the set distance of X meters of the target point, the historical fault work order records of the target IoT device are analyzed through the fault diagnosis decision tree model to determine the above-mentioned second target fault cause that caused the target IoT device to go offline.

[0053] Here, if the current online status of the target power point is online, and there are no other power points within the set distance X meters of the target point, the fault diagnosis decision tree model can be used to analyze the historical fault work order records of the target IoT device to determine the above-mentioned second target fault cause that caused the target IoT device to go offline.

[0054] Optionally, analyzing the historical fault work order records of the target IoT device through a fault diagnosis decision tree model to determine the second target fault cause that causes the target IoT device to go offline may include:

[0055] The fault diagnosis decision tree model is used to analyze the historical fault work order records of the target IoT device (specifically, the power outage faults in each historical fault work order record can be aggregated to obtain the number of power outages, and the network disconnection faults in each historical fault work order record can be aggregated to obtain the number of network disconnections). After that, if it is determined based on the historical fault work order record that the above-mentioned number of power outages is greater than the above-mentioned number of network disconnections, the second target fault cause is determined to be power outage. If it is determined based on the historical fault work order record that the number of power outages is less than the number of network disconnections, the second target fault cause is determined to be network disconnection. If it is determined based on the historical fault work order record that the number of power outages is equal to the number of network disconnections, the second target fault cause is determined to be power outage and / or network disconnection (that is, the proportion of power outages and network disconnections is equal, and both may occur). When it is finally determined that the current online status of the target power point is online, how to determine the above-mentioned second target fault cause if there are no other power points within the set distance of X meters of the target point at this time.

[0056] Of course, if the current online status of the target power point is online, and there are other power points within the set distance of X meters from the target point, the fault diagnosis decision tree model can be used to further analyze the number of normal power points and the number of abnormal power points within the set distance of X meters from the target point, and the fault diagnosis decision tree model can be used to analyze the number of normal power points and the number of abnormal power points to determine the second target fault cause. For example, if the fault diagnosis decision tree model analyzes that the number of normal power points is greater than the number of abnormal power points, the second target fault cause is determined to be power outage; if the fault diagnosis decision tree model analyzes that the number of normal power points is less than the number of abnormal power points, the second target fault cause is determined to be network disconnection; if the fault diagnosis decision tree model analyzes that the number of normal power points is equal to the number of abnormal power points, the second target fault cause is determined to be network disconnection and / or power outage.

[0057] In this embodiment, the number of normal power points refers to the number of power points that are within X meters of the target point and are online (which can be obtained by merging the target point and the associated information of the power points), and the number of abnormal power points refers to the number of power points that are within X meters of the target point and are offline (which can be obtained by merging the target point and the associated information of the power points). Figure 4The example shows the power points within the X-meter range of the target point (taking point P1 as the target point). Generally, since the positions of points and IoT devices such as cameras are fixed after installation, the number of points whose longitude and latitude coordinates fall within the X-meter range of the target point can be expanded as much as possible when setting X, and the number of normal power points and abnormal power points within the range can be calculated. Optionally, X can be the optimal value of the probability distribution obtained by continuous training of the KNN algorithm.

[0058] The above describes how to determine the second target fault cause that causes the target IoT device to go offline when the current online state of the target power point is online. The following describes how to determine the second target fault cause that causes the target IoT device to go offline when the current online state of the target power point is offline:

[0059] In this embodiment, if the current online state of the target power point is offline, then in step 104, the second target fault cause causing the target IoT device to go offline is determined by analyzing whether the target IoT device is within the obtained power outage range through the fault diagnosis decision tree model. In this embodiment, the power outage range can be obtained based on municipal construction power outage data.

[0060] Optionally, in this embodiment, analyzing whether the target IoT device is within the obtained power outage range by using a fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline may include:

[0061] Through the fault diagnosis decision tree model analysis, if the target IoT device is within the above power outage range, then the second target fault cause is directly determined to be power outage. Otherwise,

[0062] By analyzing the fault diagnosis decision tree model, the number of normal power points and the number of abnormal power points within the set distance X meters of the target point are further obtained, and the number of normal power points and the number of abnormal power points are as described above; the number of normal power points and the number of abnormal power points are analyzed by the fault diagnosis decision tree model to determine the second target fault cause. For example, if the fault diagnosis decision tree model analyzes that the number of normal power points is greater than the number of abnormal power points, the second target fault cause is determined to be power outage; if the fault diagnosis decision tree model analyzes that the number of normal power points is less than the number of abnormal power points, the second target fault cause is determined to be network disconnection; if the fault diagnosis decision tree model analyzes that the number of normal power points is equal to the number of abnormal power points, the second target fault cause is determined to be network disconnection and / or power outage. When it is finally determined that the current online status of the target power point is offline, how to determine the above-mentioned second target fault cause.

[0063] So far, completed Figure 1 The process shown.

[0064] pass Figure 1As can be seen from the process shown, the embodiment of the present application diagnoses offline faults of IoT devices based on a fault diagnosis decision tree model, which can realize automatic, intelligent, accurate and timely analysis of the root causes of device offline faults, helping users to quickly understand the health status of the device, find out the cause, and respond in time.

[0065] Furthermore, in this embodiment, the offline faults of IoT devices can be intelligently and automatically diagnosed through the fault diagnosis decision tree model, which can improve work efficiency, effectively reduce the manpower input of operation and maintenance personnel, reduce operation and maintenance costs, and is of great significance for resource planning. It also reduces the safety or reputation losses caused by unsatisfactory operation and maintenance during key activities.

[0066] It should be noted that, although the first target fault cause and the second target fault cause are both called targets, they should be suspected to be accurate. They are called targets here just for the convenience of description. In order to more accurately determine the root cause of the fault, when any of the first target fault cause and the second target fault cause is determined, manual verification can also be performed.

[0067] It should be noted that, as described above, in this embodiment, the fault diagnosis decision tree model is obtained based on the continuously accumulated expert experience (also known as the knowledge base) and combined with the actual site conditions and the decision tree algorithm, such as Figure 2 The fault diagnosis decision tree model shown in Figure 1 is a fault diagnosis decision tree model. In the specific implementation, the fault diagnosis decision tree model is such as Figure 2 The model shown can be transformed into the fault diagnosis decision tree model design matrix shown in Table 1:

[0068]

[0069]

[0070]

[0071] Table 1

[0072] In Table 1 above, the above power outage and network disconnection probabilities are general values ​​given by expert experience, that is, general rules. This rule can be applied and has a certain accuracy, but the accuracy can be improved. In addition, in Table 1, " / " means not considered.

[0073] The fault diagnosis decision tree model provided in the embodiment of the present application is described below:

[0074] First, aggregate the sample data:

[0075] In this embodiment, the aggregated sample data is not limited to the data shown in Table 2, which is only an example. As shown in Table 2, in one example, the device factor of the IoT device, such as the device online status data, is a key feature, and other factors such as the remaining spatial domain factor are optional features, which can be regarded as one of the optional embodiments.

[0076]

[0077]

[0078] Table 2

[0079] Afterwards, the collected sample data is preprocessed to convert it into a form from which the status indicator can be easily extracted. For example, the preprocessing here includes denoising, removing outliers, and deleting missing values, which are not specifically limited in this embodiment.

[0080] Afterwards, the pre-processed sample data are classified to obtain Tables 3 to 7. Tables 3 to 7 are respectively the power supply archive data table, the point status data table, the equipment status table, the historical status table, and the power outage notification data table.

[0081]

[0082]

[0083] Table 3

[0084]

[0085] Table 4

[0086]

[0087]

[0088] Table 5

[0089]

[0090] Table 6

[0091]

[0092] Table 7

[0093] After that, the data in Tables 3 to 7 are merged and calculated to obtain the feature vector table shown in Table 8:

[0094]

[0095] Table 8

[0096] In the above Tables 5 and 8, the resource identifier identifies a unique IoT device.

[0097] Afterwards, the above-mentioned fault diagnosis decision tree model is established through the continuous accumulation of expert experience (also known as expert knowledge base, expert rules) and combined with actual on-site conditions. Figure 2 The fault diagnosis decision tree model shown in the figure. By establishing a fault diagnosis decision tree model, offline fault diagnosis of IoT devices can be completed. For example, when an IoT device goes offline, the fault diagnosis decision tree model is used to analyze the cause of its offline fault, such as power supply failure, link failure, device failure, etc.

[0098] It should be noted that, in this embodiment, the above-mentioned fault diagnosis decision tree model can also be improved through feedback by continuously collecting on-site operation data, so that the fault diagnosis decision tree model is more accurate.

[0099] In addition, optionally, the KNN algorithm training is used to verify the diagnostic accuracy of the fault causes such as power outage and network disconnection diagnosed by the fault diagnosis decision tree model.

[0100] The following is a description of a specific application:

[0101] Table 9 shows the fault causes of each IoT device diagnosed by the fault diagnosis decision tree model:

[0102] Table 9

[0103] In Table 9, the resource identifier identifies a unique IoT device.

[0104] It can be seen from Table 9 that the fault diagnosis decision tree model can automatically, intelligently, accurately and timely analyze the root cause of the offline failure of IoT devices, so as to help users quickly understand the health status of the equipment, find out the cause and respond in time.

[0105] The method provided in the embodiment of the present application is described above. The device provided in the embodiment of the present application is described below:

[0106] See also Figure 5 , Figure 5 This is a diagram of the device structure provided in the embodiment of the present application. Figure 5 As shown, the device may include:

[0107] A data acquisition unit is used to first obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model when detecting that the target IoT device is offline; the target point is a point associated with the target IoT device;

[0108] a fault diagnosis unit, configured to, when the current online state of the target point is online, diagnose that the preliminary fault cause causing the target IoT device to be offline is a fault of the target IoT device by using the fault diagnosis decision tree model, and then trigger the data acquisition unit to obtain a feature vector required for verifying the preliminary fault cause by using the fault diagnosis decision tree model; and

[0109] Analyzing the feature vector by the fault diagnosis decision tree model to determine the first target fault cause that causes the target IoT device to go offline; and

[0110] When the current online status of the target point is offline, the data acquisition unit is triggered to obtain the current online status of the target power point required for the fault diagnosis decision tree model to further perform offline fault diagnosis. The target power point is the power point associated with the target point, and the current online status of the target power point is analyzed by the fault diagnosis decision tree model to determine the second target fault cause that caused the target Internet of Things device to go offline.

[0111] Optionally, the current online status of the target point is determined by the following steps:

[0112] Determine all IoT devices associated with the target point, wherein all IoT devices include at least the target IoT device;

[0113] When the current online state of at least one Internet of Things device associated with the target point is online, the current online state of the target point is determined to be online; otherwise, the current online state of the target point is determined to be offline.

[0114] Optionally, the feature vector includes:

[0115] A first sub-vector, the first sub-vector at least includes: the number of state changes of the target IoT device within a specified historical period, and the workload of the target IoT device within the specified historical period when the number of state changes is less than or equal to a first set number threshold; the number of state changes includes the number of changes from online to offline and from offline to online; when the target IoT device is a camera, the workload is the amount of captured data; or,

[0116] The second sub-vector at least includes: the number of state changes of the target IoT device within the specified historical time period, and the working status of the target IoT device within the specified historical time period when the number of state changes is greater than or equal to a second set number threshold, wherein when the target IoT device is a camera, the working status is the video quality of the recorded video; the second set number threshold is greater than the first set number threshold.

[0117] Optionally, analyzing the feature vector by the fault diagnosis decision tree model to determine the first target fault cause causing the target Internet of Things device to go offline includes:

[0118] When it is analyzed according to the fault diagnosis decision tree model that the workload of the target IoT device in the first sub-vector within the specified historical time period is greater than the workload threshold, it is determined that the first target fault cause is a service link failure to which the target IoT device is connected; otherwise, it is determined that the first target fault cause is a failure of the target IoT device; or,

[0119] When it is analyzed according to the fault diagnosis decision tree model that the working condition of the target Internet of Things device in the second sub-vector within the specified historical period is a normal working condition, it is determined that the first target fault cause is that the IP address of the target Internet of Things device conflicts with the IP addresses of other Internet of Things devices; otherwise, it is determined that the first target fault cause is that the network link of the target Internet of Things device is unstable.

[0120] Optionally, the current online status of the target power point is determined by the following steps:

[0121] Determine all points associated with the target power point, wherein all points at least include the target point;

[0122] When the current online state of at least one point associated with the target power point is online, the current online state of the target power point is determined to be online; otherwise, the current online state of the target power point is determined to be offline.

[0123] Optionally, analyzing the current online state of the target power point by using the fault diagnosis decision tree model to determine the second target fault cause causing the target Internet of Things device to go offline includes:

[0124] When the current online state of the target power point is offline, analyzing whether the target IoT device is within the obtained power outage range through the fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline;

[0125] When the current online status of the target power point is online, if there are no other power points within the set distance X meters of the target point, the historical fault work order records of the target Internet of Things device are analyzed by the fault diagnosis decision tree model to determine the second target fault cause that caused the target Internet of Things device to go offline.

[0126] Optionally, the above-mentioned analyzing the historical fault work order records of the target IoT device through a fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline includes:

[0127] Analyze the historical fault work order records of the target IoT device through the fault diagnosis decision tree model;

[0128] If the number of power outages determined according to the historical fault work order records is greater than the number of network outages, the second target fault cause is determined to be a power outage. If the number of power outages determined according to the historical fault work order records is less than the number of network outages, the second target fault cause is determined to be a network outage. If the number of power outages determined according to the historical fault work order records is equal to the number of network outages, the second target fault cause is determined to be a power outage and / or a network outage.

[0129] Optionally, the above-mentioned analyzing whether the target IoT device is within the obtained power outage range by the fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline includes:

[0130] By analyzing the target IoT device through the fault diagnosis decision tree model, it is determined that the second target fault cause is a power outage. Otherwise,

[0131] By analyzing the fault diagnosis decision tree model, the number of normal power points and the number of abnormal power points within the set distance X meters of the target point are further obtained. The number of normal power points refers to the number of power points within the range of X meters of the target point and whose online status is online, and the number of abnormal power points refers to the number of power points within the range of X meters of the target point and whose online status is offline;

[0132] The fault diagnosis decision tree model is used to analyze the number of normal power supply points and the number of abnormal power supply points to determine the cause of the second target fault.

[0133] Optionally, the analyzing the number of normal power points and the number of abnormal power points through the fault diagnosis decision tree model to determine the second target fault cause includes:

[0134] If it is analyzed through the fault diagnosis decision tree model that the number of normal power points is greater than the number of abnormal power points, then it is determined that the second target fault cause is a power outage;

[0135] If it is analyzed through the fault diagnosis decision tree model that the number of normal power points is less than the number of abnormal power points, then it is determined that the second target fault cause is network disconnection;

[0136] If it is analyzed through the fault diagnosis decision tree model that the number of normal power supply points is equal to the number of abnormal power supply points, it is determined that the second target fault cause is network disconnection and / or power outage.

[0137] So far, completed Figure 5 Structural description of the device shown.

[0138] The present application also provides Figure 5 The hardware structure of the device shown. Figure 6 , Figure 6 This is a structural diagram of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0139] Based on the same application concept as the above method, an embodiment of the present application also provides a machine-readable storage medium, on which a number of computer instructions are stored. When the computer instructions are executed by a processor, the method disclosed in the above example of the present application can be implemented.

[0140] Exemplarily, the above-mentioned machine-readable storage medium can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as CD, DVD, etc.), or similar storage medium, or a combination thereof.

[0141] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0142] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0143] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0144] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0145] Moreover, these computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0146] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0147] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for offline fault diagnosis of an Internet of Things device, characterized in that: The method includes: When it is detected that the target IoT device is offline, firstly obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model; the target point is the point associated with the target IoT device; When the current online state of the target point is online, the fault diagnosis decision tree model is used to diagnose that the preliminary fault cause causing the target IoT device to go offline is the fault of the target IoT device, and then a feature vector required for verifying the preliminary fault cause through the fault diagnosis decision tree model is obtained, and the first target fault cause causing the target IoT device to go offline is determined by analyzing the feature vector through the fault diagnosis decision tree model; When the current online status of the target point is offline, the current online status of the target power point required for the fault diagnosis decision tree model to further perform offline fault diagnosis is obtained, and the target power point is the power point associated with the target point; the second target fault cause causing the target IoT device to go offline is determined by analyzing the current online status of the target power point through the fault diagnosis decision tree model; Wherein, the feature vector includes: A first sub-vector, wherein the first sub-vector at least includes: the number of state changes of the target IoT device within a specified historical period, and the workload of the target IoT device within the specified historical period when the number of state changes is less than or equal to a first set number threshold; the number of state changes includes the number of changes from online to offline and from offline to online; or, A second sub-vector, wherein the second sub-vector at least includes: the number of state changes of the target IoT device within a specified historical period, and the working status of the target IoT device within the specified historical period when the number of state changes is greater than or equal to a second set number threshold; the second set number threshold is greater than the first set number threshold.

2. The method according to claim 1, characterized in that The current online status of the target point is determined by the following steps: Determine all IoT devices associated with the target point, wherein all IoT devices include at least the target IoT device; When the current online state of at least one Internet of Things device associated with the target point is online, the current online state of the target point is determined to be online; otherwise, the current online state of the target point is determined to be offline.

3. The method according to claim 1, characterized in that When the target IoT device is a camera, the workload is the amount of captured data, and the working condition is the video quality of the recorded video.

4. The method according to claim 1, characterized in that: The determining of the first target fault cause causing the target IoT device to go offline by analyzing the feature vector through the fault diagnosis decision tree model includes: When it is analyzed according to the fault diagnosis decision tree model that the workload of the target IoT device in the first sub-vector within the specified historical time period is greater than the workload threshold, it is determined that the first target fault cause is a service link failure to which the target IoT device is connected; otherwise, it is determined that the first target fault cause is a failure of the target IoT device; or, When it is analyzed according to the fault diagnosis decision tree model that the working condition of the target Internet of Things device in the second sub-vector within the specified historical period is a normal working condition, it is determined that the first target fault cause is that the IP address of the target Internet of Things device conflicts with the IP addresses of other Internet of Things devices; otherwise, it is determined that the first target fault cause is that the network link of the target Internet of Things device is unstable.

5. The method according to claim 1, characterized in that The current online status of the target power point is determined by the following steps: Determine all points associated with the target power point, wherein all points at least include the target point; When the current online state of at least one point associated with the target power point is online, the current online state of the target power point is determined to be online; otherwise, the current online state of the target power point is determined to be offline.

6. The method according to claim 1, characterized in that The determining of the second target fault cause causing the target IoT device to go offline by analyzing the current online state of the target power point through the fault diagnosis decision tree model includes: When the current online state of the target power point is offline, analyzing whether the target IoT device is within the obtained power outage range through the fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline; When the current online status of the target power point is online, if there are no other power points within the set distance X meters of the target point, the historical fault work order records of the target Internet of Things device are analyzed by the fault diagnosis decision tree model to determine the second target fault cause that caused the target Internet of Things device to go offline.

7. The method according to claim 6, characterized in that The method of analyzing the historical fault work order records of the target IoT device by using a fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline includes: Analyze the historical fault work order records of the target IoT device through the fault diagnosis decision tree model; If the number of power outages determined according to the historical fault work order records is greater than the number of network outages, the second target fault cause is determined to be a power outage. If the number of power outages determined according to the historical fault work order records is less than the number of network outages, the second target fault cause is determined to be a network outage. If the number of power outages determined according to the historical fault work order records is equal to the number of network outages, the second target fault cause is determined to be a power outage and / or a network outage.

8. The method according to claim 6, characterized in that The step of analyzing whether the target IoT device is within the obtained power outage range by using the fault diagnosis decision tree model to determine the second target fault cause causing the target IoT device to go offline includes: By analyzing the target IoT device through the fault diagnosis decision tree model, it is determined that the second target fault cause is a power outage. Otherwise, By analyzing the fault diagnosis decision tree model, the number of normal power points and the number of abnormal power points within the set distance X meters of the target point are further obtained. The number of normal power points refers to the number of power points within the range of X meters of the target point and whose online status is online, and the number of abnormal power points refers to the number of power points within the range of X meters of the target point and whose online status is offline; The fault diagnosis decision tree model is used to analyze the number of normal power supply points and the number of abnormal power supply points to determine the cause of the second target fault.

9. The method according to claim 8, characterized in that Analyzing the number of normal power points and the number of abnormal power points by using the fault diagnosis decision tree model to determine the second target fault cause includes: If it is analyzed through the fault diagnosis decision tree model that the number of normal power points is greater than the number of abnormal power points, then it is determined that the second target fault cause is a power outage; If it is analyzed through the fault diagnosis decision tree model that the number of normal power points is less than the number of abnormal power points, then it is determined that the second target fault cause is network disconnection; If it is analyzed through the fault diagnosis decision tree model that the number of normal power supply points is equal to the number of abnormal power supply points, it is determined that the second target fault cause is network disconnection and / or power outage.

10. An off-line fault diagnosis device for an Internet of Things device, characterized in that: The device includes: A data acquisition unit is used to first obtain the current online status of the target point required for offline fault diagnosis using the established fault diagnosis decision tree model when detecting that the target IoT device is offline; the target point is a point associated with the target IoT device; a fault diagnosis unit, configured to, when the current online state of the target point is online, diagnose that the preliminary fault cause causing the target IoT device to be offline is a fault of the target IoT device by using the fault diagnosis decision tree model, and then trigger the data acquisition unit to obtain a feature vector required for verifying the preliminary fault cause by using the fault diagnosis decision tree model; and Analyzing the feature vector by the fault diagnosis decision tree model to determine the first target fault cause that causes the target IoT device to go offline; and When the current online status of the target point is offline, the data acquisition unit is triggered to obtain the current online status of the target power point required for the fault diagnosis decision tree model to further perform offline fault diagnosis, and the target power point is the power point associated with the target point. The current online status of the target power point is analyzed by the fault diagnosis decision tree model to determine the second target fault cause that caused the target IoT device to go offline; Wherein, the feature vector includes: A first sub-vector, wherein the first sub-vector at least includes: the number of state changes of the target IoT device within a specified historical period, and the workload of the target IoT device within the specified historical period when the number of state changes is less than or equal to a first set number threshold; the number of state changes includes the number of changes from online to offline and from offline to online; or, A second sub-vector, wherein the second sub-vector at least includes: the number of state changes of the target IoT device within a specified historical period, and the working status of the target IoT device within the specified historical period when the number of state changes is greater than or equal to a second set number threshold; the second set number threshold is greater than the first set number threshold.

11. An electronic device, characterized in that: The electronic device includes: a processor and a machine-readable storage medium; The machine-readable storage medium stores machine-executable instructions that can be executed by the processor; The processor is used to execute machine executable instructions to implement the method steps of any one of claims 1-9.

Images