Iot connection failure root cause positioning method, device, equipment and program product

Abstract

The application discloses an Internet of Things connection fault root cause positioning method, device, equipment and program product, comprising: acquiring connection parameter data of an Internet of Things device, generating a plurality of fault evidences according to the connection parameter data, and dynamically adjusting evidence weights of the fault evidences according to a context environment of the Internet of Things device; respectively calculating contribution degrees of the fault evidences to a plurality of preset fault root cause hypotheses, and determining group behavior correction factors corresponding to the fault evidences according to a group behavior baseline of a device group where the Internet of Things device is located; determining a credibility score of each fault root cause hypothesis according to the evidence weights, the contribution degrees and the group behavior correction factors, and determining a target fault root cause according to the credibility score. The application improves the accuracy, timeliness and intelligent level of the Internet of Things connection fault root cause positioning, and can be widely applied to the technical field of the Internet of Things.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, device, and program product for locating the root cause of IoT connection failures. Background Technology

[0002] Current methods for diagnosing IoT connectivity faults primarily rely on human experience, static rules, or simple threshold alarms. For example, when a device's signal strength falls below a preset threshold or its traffic is abnormal, the system triggers an alarm, requiring manual troubleshooting by maintenance personnel. Some advanced systems may employ rule-based expert systems, pre-setting a series of "if-then" rules to determine the fault type, such as "if the device is offline and the SIM card status is abnormal, then it may be a SIM card fault." In some scenarios, simple statistical methods may also be used, such as calculating the device's offline rate and comparing it with historical averages.

[0003] Existing methods for diagnosing IoT connectivity faults have the following problems: 1) Low diagnostic efficiency: Faced with a massive number of IoT devices and complex fault phenomena, manual troubleshooting is time-consuming and labor-intensive, making it difficult to quickly locate the root cause of the fault. Even rule-based systems require a large amount of manual maintenance of the rule base and are difficult to deal with unknown faults.

[0004] 2) Insufficient diagnostic accuracy: The weights in most weighted algorithms are pre-set statically, which cannot adapt to dynamic changes in the network environment and differences in device types, resulting in insufficient accuracy and robustness of diagnostic results. For example, during peak network periods, slight signal fluctuations may not be a fault, but during off-peak periods, they may indicate a problem. Static weights cannot distinguish between these scenarios, easily leading to false alarms or missed alarms.

[0005] 3) Lack of predictive capability: Most existing diagnostic systems are reactive, meaning they only diagnose after a fault occurs. This lag leads to untimely maintenance and may cause greater losses. For example, if the device's signal strength continues to decline but does not reach a threshold, the existing system will not issue a warning until the device is completely offline.

[0006] 4) Ignoring cluster correlations: Existing diagnostics often focus only on the performance of individual devices, failing to fully utilize the characteristics of IoT device cluster deployments and ignoring the potential for cluster failures due to inter-device correlations. For example, if the signal of all devices under the same base station deteriorates simultaneously, the existing system may still treat each device as an independent failure, rather than identifying a problem with the base station or the regional network.

[0007] 5) Hidden faults are difficult to detect: Some faults (such as the device being online but failing to report data) are not obvious. Traditional methods usually only focus on the connection status and ignore abnormalities in the application layer or transport layer, making it difficult to effectively identify and diagnose such hidden faults.

[0008] The above problems urgently need to be addressed.

[0009] Terminology Explanation: The Internet of Things (IoT) refers to the use of various information sensors, radio frequency identification (RFID) technology, global positioning systems (GPS), infrared sensors, laser scanners, and other devices and technologies to collect real-time information on any object or process that needs to be monitored, connected, or interacted with. This information includes sound, light, heat, electricity, mechanics, chemistry, biology, location, and other necessary data. Through various possible network access methods, it enables ubiquitous connectivity between things and between things and people, achieving intelligent perception, identification, and management of objects and processes.

[0010] Connectivity Management Platform (CMP): An IoT connectivity management platform that provides services such as connectivity management, data transmission, lifecycle management, and security management for IoT devices.

[0011] Root cause analysis refers to the process of identifying the root cause of a system or device failure, rather than simply addressing the surface symptoms.

[0012] Dynamic weights refer to parameter weights in an algorithm or model that are dynamically adjusted based on the real-time environment, contextual information, or specific conditions, rather than being fixed values ​​set in advance.

[0013] Group Behavior Analysis (GBA) refers to a method that analyzes the overall operating status, trends, and abnormal patterns of a group of related devices (groups) to help determine the root cause of failures in individual devices or the entire group.

[0014] Predictive Diagnosis refers to a diagnostic approach that predicts potential failures and issues early warnings by analyzing historical data and operational trends before equipment failures occur.

[0015] Implicit Fault: This refers to a type of fault where the device appears to be in normal condition (e.g., online), but its function or data transmission is abnormal (e.g., data reporting failure). Summary of the Invention

[0016] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0017] Therefore, one objective of this invention is to provide a method for locating the root cause of IoT connection failures. This method calculates the credibility of the root cause hypothesis based on dynamic evidence weight and group behavior analysis, thereby achieving accurate root cause location of IoT connection failures and improving the accuracy, timeliness, and intelligence level of IoT connection failure root cause location.

[0018] Another objective of this invention is to provide an Internet of Things (IoT) connection failure root cause location device.

[0019] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include: On one hand, embodiments of the present invention provide a method for locating the root cause of IoT connection failures, comprising the following steps: Obtain connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context of the IoT device. The contribution of each piece of fault evidence to multiple preset root cause hypotheses is calculated, and the group behavior correction factor corresponding to each piece of fault evidence is determined based on the group behavior baseline of the device group to which the IoT device belongs. The credibility score of each of the root cause hypotheses is determined based on the evidence weight, the contribution degree, and the group behavior correction factor, and the target root cause is determined based on the credibility score.

[0020] Furthermore, in one embodiment of the present invention, the connection parameter data includes multiple connection parameter indicators of the IoT device, and the step of generating multiple fault evidences based on the connection parameter data specifically includes: Obtain the normal range of each of the connection parameter indicators, and determine whether each of the connection parameter indicators exceeds the corresponding normal range. When the connection parameter index exceeds the corresponding normal index range, the corresponding fault evidence is generated based on the connection parameter index. The initial weight of the corresponding fault evidence is determined based on the parameter type of the connection parameter index.

[0021] Furthermore, in one embodiment of the present invention, the step of dynamically adjusting the evidence weights of each piece of fault evidence according to the context of the IoT device specifically includes: Obtain the context environment parameters of the IoT device, including time parameters, geographical location parameters, and device service type parameters; Obtain the time weight dynamic adjustment function, geographical location weight dynamic adjustment function, and equipment service type weight dynamic adjustment function corresponding to each of the aforementioned fault evidences; The time factor is determined based on the time parameters and the time weight dynamic adjustment function. The geographic location factor is determined based on the geographic location parameters and the geographic location weight dynamic adjustment function; The equipment service type factor is determined based on the equipment service type parameter and the equipment service type weight dynamic adjustment function. The initial weights of the fault evidence are adjusted based on the time factor, the geographical location factor, and the equipment service type factor to obtain the evidence weights.

[0022] Furthermore, in one embodiment of the present invention, the step of calculating the contribution of each piece of fault evidence to a plurality of preset root cause hypotheses specifically includes: The probability of association between the fault evidence and each of the fault root cause hypotheses is determined based on an expert knowledge base, historical fault data, or machine learning models. The contribution of the fault evidence to each of the fault root cause hypotheses is determined based on the association probability.

[0023] Furthermore, in one embodiment of the present invention, determining the group behavior correction factor corresponding to each piece of fault evidence based on the group behavior baseline of the device group to which the IoT device belongs specifically includes: Based on clustering algorithms or business rules, the multiple IoT devices are divided into multiple device groups; The group behavior baseline is determined based on the average normal connection parameters of each IoT device within the device group; Based on the connection parameter index corresponding to the fault evidence, find the corresponding group behavior baseline index from the group behavior baseline; The average current connection parameter value of each IoT device in the device group is determined based on the connection parameter index corresponding to the fault evidence. The group behavior correction factor corresponding to the fault evidence is determined based on the difference between the mean of the current connection parameters and the baseline index of group behavior.

[0024] Furthermore, in one embodiment of the present invention, the step of determining the credibility score of each of the root cause hypotheses of failure based on the evidence weight, the contribution degree, and the group behavior correction factor, and determining the target root cause of failure based on the credibility score, specifically includes: The contribution correction value of the fault evidence to the fault root cause hypothesis is determined based on the evidence weight, contribution degree, and group behavior correction factor corresponding to the fault evidence. The confidence score of the root cause hypothesis is determined by summing the contribution correction values ​​of all the failure evidence to the root cause hypothesis. The root causes of the failure with the highest confidence scores are identified as the target root causes of the failure.

[0025] Furthermore, in one embodiment of the present invention, the IoT connection failure root cause localization method further includes the following steps: Predict the future connection parameter values ​​of the IoT device based on the historical trend of the connection parameter data. The confidence prediction value of each of the fault root cause hypotheses is determined based on the predicted values ​​of the connection parameters. Fault warnings are issued based on the predicted confidence level.

[0026] On the other hand, embodiments of the present invention provide an IoT connectivity failure root cause location device, comprising: The fault evidence generation module is used to acquire connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context environment of the IoT device. The contribution and correction factor determination module is used to calculate the contribution of each piece of fault evidence to multiple preset fault root cause hypotheses, and to determine the group behavior correction factor corresponding to each piece of fault evidence based on the group behavior baseline of the device group to which the IoT device belongs. The credibility calculation module is used to determine the credibility score of each of the root cause hypotheses of failure based on the evidence weight, the contribution degree and the group behavior correction factor, and to determine the target root cause of failure based on the credibility score.

[0027] On the other hand, embodiments of the present invention provide an electronic device, the electronic device including a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for implementing connection communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the IoT connection failure root cause localization method as described above.

[0028] On the other hand, embodiments of the present invention also provide a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more computer programs, which can be executed by one or more processors to implement the IoT connection failure root cause localization method as described above.

[0029] On the other hand, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the IoT connection failure root cause localization method as described above.

[0030] The advantages and beneficial effects of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention: This invention acquires connection parameter data from IoT devices, generates multiple pieces of fault evidence based on this data, dynamically adjusts the evidence weight of each piece of fault evidence according to the context of the IoT devices, calculates the contribution of each piece of fault evidence to multiple preset root cause hypotheses, and determines a group behavior correction factor corresponding to each piece of fault evidence based on the group behavior baseline of the device group to which the IoT devices belong. Based on the evidence weight, contribution, and group behavior correction factor, the credibility score of each root cause hypothesis is determined, and the target root cause is determined based on the credibility score. This invention achieves accurate root cause localization of IoT connection faults by calculating the credibility of root cause hypotheses based on dynamic evidence weights and group behavior analysis, thereby improving the accuracy, timeliness, and intelligence level of IoT connection fault root cause localization. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments of the present invention are described below. It should be understood that the drawings described below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 A flowchart illustrating one step of the IoT connection failure root cause localization method provided in this embodiment of the invention; Figure 2 This is a data interaction diagram of the IoT connection failure root cause localization method provided in an embodiment of the present invention; Figure 3 A schematic diagram of the overall process of the IoT connection failure root cause localization method provided in an embodiment of the present invention; Figure 4 A flowchart of step S101 provided in an embodiment of the present invention; Figure 5 Another flowchart of step S101 provided in an embodiment of the present invention; Figure 6 A flowchart of step S102 provided in an embodiment of the present invention; Figure 7 Another flowchart of step S102 provided in an embodiment of the present invention; Figure 8 A flowchart of step S103 provided in an embodiment of the present invention; Figure 9Another flowchart of the IoT connection failure root cause localization method provided in the embodiments of the present invention; Figure 10 This is a schematic diagram of the structure of the IoT connection failure root cause location device provided in an embodiment of the present invention; Figure 11 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of the storage medium provided in an embodiment of the present invention. Detailed Implementation

[0033] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. It should be noted that although functional modules are divided in the system schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system schematic diagram or the order in the flowchart. The step numbers in the following embodiments are only set for ease of explanation and do not limit the order between steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0035] The IoT connection failure root cause localization method provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a driver status monitoring method based on machine vision, but is not limited to the above forms.

[0036] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0037] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0038] like Figure 1 The diagram shown is a flowchart of one step in the IoT connection failure root cause localization method provided by an embodiment of the present invention. (Refer to...) Figure 1 This invention provides a method for locating the root cause of IoT connection failures, specifically including the following steps: S101. Obtain connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context of IoT devices. S102. Calculate the contribution of each fault evidence to the multiple preset fault root cause hypotheses, and determine the group behavior correction factor corresponding to each fault evidence based on the group behavior baseline of the device group to which the IoT device belongs. S103. Determine the confidence score of each failure root cause hypothesis based on the evidence weight, contribution degree, and group behavior correction factor, and determine the target failure root cause based on the confidence score.

[0039] like Figure 2The diagram illustrates the data interaction of the IoT connection failure root cause localization method provided in this embodiment of the invention. This method is primarily applied in an IoT Connection Management Platform (CMP) to provide intelligent diagnosis and early warning services for device connection failures to operators and enterprise users. The network elements involved include, but are not limited to: IoT devices (such as smart water meters, smoke detectors, vehicle terminals, industrial sensors, etc.), base stations / gateways, CMP platform servers, data storage servers, computing servers, and terminal devices for maintenance personnel. Communication connections between these network elements are primarily achieved through wireless networks (such as cellular networks, LoRa, NB-IoT, etc.) and wired networks for data transmission.

[0040] Reference Figure 2 The software architecture involved in the data interaction of this invention includes an IoT device layer, an edge computing layer, a cloud platform layer, and an application layer. The IoT device layer is equipped with an IoT device and connection parameter data acquisition module. The edge computing layer is equipped with a data and processing module, an evidence generation and weighting module, and a dynamic weight adjustment module. The cloud platform layer is equipped with a device group management module, a group behavior analysis module, a root cause localization engine, a trend analysis and prediction module, and a hidden fault discovery module. The application layer is equipped with a visualization and alarm module and an operation and maintenance system.

[0041] like Figure 3 The diagram shown is an overall flowchart of the IoT connection failure root cause localization method provided in an embodiment of the present invention. The overall flow of the embodiment of the present invention is as follows: 1) Data acquisition and preprocessing: Real-time acquisition of connection parameter data from IoT devices, followed by cleaning, normalization, and feature extraction.

[0042] 2) Evidence generation and weighting: Based on the preprocessed data, generate fault evidence and assign initial weights.

[0043] 3) Dynamic adaptive weight adjustment: The evidence weight is dynamically adjusted according to the context of the IoT device (including time factor, geographical location factor and device business type factor).

[0044] 4) Generation of root cause hypotheses: Define a series of possible root cause hypotheses.

[0045] 5) Calculation of the contribution of each piece of evidence to the root cause: Calculate the contribution of each piece of evidence to each root cause hypothesis of the failure.

[0046] 6) Group behavior analysis and collaborative diagnosis: When diagnosing a single device, the confidence score of the root cause hypothesis is corrected by comparing it with the group behavior baseline of the device group to which it belongs.

[0047] 7) Root cause credibility score calculation: The credibility score of each failure root cause hypothesis is calculated by combining the dynamically adjusted evidence weight, the contribution of evidence to the root cause, and the group behavior correction factor.

[0048] 8) Predictive diagnosis and latent fault detection: Fault prediction and early warning are generated based on historical trend analysis of device connection parameters; for latent faults where the device is online but application layer data is not communicated, special evidence extraction and analysis are performed.

[0049] 9) Root Cause Output and Visualization: Output the most likely cause based on the confidence score and display it through a visualization interface.

[0050] This invention addresses the pain points of existing IoT connectivity fault diagnosis technologies, such as rigid weights, neglect of group correlations, and inability to predict latent faults. By introducing a dynamic weight adjustment mechanism, the diagnostic model can adapt to complex real-world environments. Through an innovative group behavior analysis method, it leverages collaborative information from device groups to significantly improve the accuracy of single-device diagnosis. Furthermore, by expanding the spatiotemporal dimensions of diagnosis, it achieves predictive diagnosis based on historical trends and the ability to uncover latent faults. This solution greatly enhances diagnostic accuracy, timeliness, and intelligence, achieving a leap from "post-event diagnosis" to "pre-event warning," thereby improving the reliability and operational efficiency of IoT services.

[0051] It can be recognized that the embodiments of the present invention calculate the credibility of the root cause hypothesis of the failure based on dynamic evidence weight and group behavior analysis, thereby realizing accurate root cause location of IoT connection failures and improving the accuracy, timeliness and intelligence level of IoT connection failure root cause location.

[0052] The following uses a smart water meter, an IoT device, as an example to describe the specific implementation process of this invention. A city has deployed a large number of smart water meters, which are connected to the CMP platform via an NB-IoT network. Maintenance personnel need to promptly identify and resolve connection faults in the water meters to ensure the continuity of data reporting.

[0053] like Figure 4 The diagram shown is a flowchart of step S101 provided in an embodiment of the present invention. (Refer to...) Figure 4 As an optional implementation, the connection parameter data includes multiple connection parameter indicators of the IoT device, and multiple pieces of fault evidence are generated based on the connection parameter data, specifically including: S1011. Obtain the normal range of each connection parameter index and determine whether each connection parameter index exceeds the corresponding normal range. S1012. When the connection parameter index exceeds the corresponding normal index range, generate corresponding fault evidence based on the connection parameter index. S1013. Determine the initial weight of the corresponding fault evidence based on the parameter type of the connection parameter index.

[0054] Specifically, the CMP platform collects the connection parameters of each water meter in real time, including signal strength (RSRP), RSRQ, SNR, cell ID, online status, heartbeat packet reporting frequency, and flow data. The data is then cleaned, normalized, and outliers are removed.

[0055] The system generates fault evidence according to preset rules. Based on preprocessed connection parameter data, a series of fault evidence is generated. Each piece of evidence This corresponds to an observed anomaly (such as signal strength below a threshold, abnormal traffic, etc.). For each piece of evidence... Assign an initial weight For example, when RSRP is below -120dBm, "weak signal" evidence is generated; when heartbeat packets are not reported for three consecutive times, "abnormal heartbeat" evidence is generated. Each piece of evidence is assigned an initial weight, for example... , .

[0056] like Figure 5 The diagram shown is another flowchart of step S101 provided in an embodiment of the present invention. (Refer to...) Figure 5 As an optional implementation, the evidence weights of each fault piece of evidence are dynamically adjusted according to the context of the IoT device, specifically including: S1014. Obtain the context environment parameters of the IoT device. The context environment parameters include time parameters, geographical location parameters, and device service type parameters. S1015. Obtain the time weight dynamic adjustment function, geographical location weight dynamic adjustment function, and equipment service type weight dynamic adjustment function corresponding to each fault evidence. S1016. Determine the time factor based on the time parameters and the time weight dynamic adjustment function; S1017. Determine the geographic location factor based on the geographic location parameters and the geographic location weight dynamic adjustment function; S1018. Determine the equipment service type factor based on the equipment service type parameter and the equipment service type weight dynamic adjustment function; S1019. Adjust the initial weights of the fault evidence based on the time factor, geographical location factor, and equipment business type factor to obtain the evidence weights.

[0057] Specifically, the evidence weights are dynamically adjusted based on the context of the IoT device (including time parameters, geographic location parameters, and device service type parameters). Specifically, the adjusted weights It can be represented as:

[0058] in, , , These are dynamic adjustment functions related to time, geographic location, and device service type, respectively. These functions are dynamically calculated based on preset rules or machine learning models.

[0059] Time factor The connectivity and performance of IoT devices may exhibit different normal behavior patterns at different times of day. For example, network load is typically lower at night, and signal fluctuations may be less indicative of faults; while during peak business hours, even minor anomalies may indicate potential problems. The time factor adjusts the weight of evidence based on the current time period.

[0060] For example, regarding evidence of "weak signal" Its initial weight is At night (11:00 PM - 7:00 AM the next day), network load is low, signal fluctuations are less indicative, and the weight is adjusted downwards. During peak daytime hours (9:00-18:00), network load is high, signal fluctuations are more indicative, and the weight is increased. The initial weights are maintained for other time periods.

[0061] Geographic location factor The geographical environment in which a device is located has a significant impact on its connectivity performance. For example, devices deployed in basements or remote mountainous areas generally have lower signal strength, and using a uniform signal threshold and weight can easily lead to a large number of false alarms. The geographical location factor adjusts the evidence weights based on the characteristics of the area where the device is located.

[0062] For example, regarding evidence of "weak signal" Its initial weight is The system determines the device's geographical location based on its cell ID or GPS information and queries a preset area weight mapping table. For "basement areas" or "remote mountainous areas," even if the RSRP is below -120dBm, its weight will be adjusted. To avoid false alarms; for "high-density urban areas" with good signal coverage and low tolerance for weak signals, the weight will be adjusted accordingly. To increase sensitivity.

[0063] Equipment business type factor Different types of IoT devices have different business characteristics and data transmission modes. For example, smart water meters are low-rate, periodic reporting devices, while video surveillance equipment is a high-bandwidth, continuous transmission device. The criteria for judging abnormal traffic should vary depending on the device type. The evidence weight of the device business type factor should be adjusted according to the business characteristics of the device.

[0064] Example: Evidence of "abnormal traffic" Its initial weight is For smart water meters (low-rate, periodic reporting), if a sudden surge in water flow is detected within a short period (e.g., from 1KB per day to 1MB per hour), this is considered abnormal behavior for the meter. The system will significantly increase the contribution of "abnormal flow" evidence to the conclusion of "device malfunction," meaning there is... However, for video surveillance equipment (high bandwidth, continuous transmission), the same surge in traffic may be considered normal, and its weight may even be slightly reduced to avoid false alarms. .

[0065] By combining these contextual factors, the dynamic weight adjustment mechanism can make the fault diagnosis model more flexible and intelligent, significantly reduce false alarms and false negatives, and improve the accuracy of root cause localization.

[0066] like Figure 6 The diagram shown is a flowchart of step S102 provided in an embodiment of the present invention. (Refer to...) Figure 6 Furthermore, as an optional implementation, the contribution of each piece of fault evidence to multiple preset root cause hypotheses is calculated, specifically including: S1021. Determine the correlation probability between fault evidence and each fault root cause hypothesis based on expert knowledge base, historical fault data or machine learning model. S1022. Determine the contribution of fault evidence to each fault root cause hypothesis based on the correlation probability.

[0067] Specifically, a series of possible root cause hypotheses of failure are predefined. (e.g., base station failure, SIM card failure, device malfunction, network congestion, etc.), calculate evidence for each failure. For each root cause hypothesis Contribution The probability of association between fault evidence and each fault root cause hypothesis can be determined through expert knowledge bases, historical fault data analysis, or machine learning models. That is, the probability of the corresponding fault root cause occurring when the fault evidence exists. Based on this association probability, the contribution of fault evidence to each fault root cause hypothesis can be determined.

[0068] like Figure 7 The diagram shown is another flowchart of step S102 provided in an embodiment of the present invention. (Refer to...) Figure 7 As an optional implementation, a group behavior correction factor corresponding to each piece of fault evidence is determined based on the group behavior baseline of the device group to which the IoT device belongs. This specifically includes: S1023. Divide multiple IoT devices into multiple device groups based on clustering algorithms or business rules; S1024. Determine the group behavior baseline based on the average normal connection parameters of each IoT device in the device group; S1025. Based on the connection parameter indicators corresponding to the fault evidence, find the corresponding group behavior baseline indicators from the group behavior baseline. S1026. Determine the average current connection parameters of each IoT device in the device group based on the connection parameter indicators corresponding to the fault evidence. S1027. Determine the group behavior correction factor corresponding to the fault evidence based on the difference between the current mean of connection parameters and the baseline index of group behavior.

[0069] Specifically, based on the geographical location (e.g., cell ID, base station coverage), service type (e.g., smart water meters, smoke detectors, shared bicycles), device model, or deployment batch of IoT devices, IoT devices are divided into several device groups. The segmentation strategy can employ clustering algorithms or classification based on business rules.

[0070] Clustering algorithms, such as K-means and DBSCAN, perform unsupervised clustering based on the similarity of device connection parameters.

[0071] Rule-based classification: Classification is based on preset business rules. For example, all smart water meters connected to the same base station form a group.

[0072] For each group The system continuously monitors its key connectivity parameters (such as average signal strength). Average offline rate Average heart rate success rate Historical data (e.g., daytime, nighttime). Using statistical analysis methods (e.g., moving average, exponential smoothing, Kalman filtering), baselines of normal behavior for this group were established under different time periods (e.g., daytime, nighttime) and environments. The baseline will be updated regularly to adapt to long-term changes in the environment and the evolution of the equipment group.

[0073] When the water meter When evidence of "weak signal" is detected, the system will simultaneously check the cell group in which the signal is located. The average RSRP. If The RSRP is below the threshold, and If the average RSRP is also significantly lower than its normal baseline (e.g., dropping from -90dBm to -110dBm), the system will increase the confidence score of root cause hypotheses such as "base station failure" or "regional network congestion." Conversely, if If the average RSRP is normal, the confidence score of root cause hypotheses such as "water meter antenna failure" or "water meter failure" will be increased.

[0074] In some optional embodiments, the group behavior modification factor It can be represented as:

[0075] in, and The final root cause confidence score will be multiplied by this correction factor.

[0076] like Figure 8 The diagram shown is a flowchart of step S103 provided in an embodiment of the present invention. (Refer to...) Figure 8 As an optional implementation, the credibility score of each root cause hypothesis is determined based on evidence weight, contribution, and group behavior correction factor, and the target root cause is determined based on the credibility score. Specifically, this includes: S1031. Determine the contribution correction value of the failure evidence to the failure root cause hypothesis based on the evidence weight, contribution degree, and group behavior correction factor corresponding to the failure evidence. S1032. Determine the confidence score of the root cause hypothesis based on the sum of the contribution correction values ​​of all failure evidence to the root cause hypothesis. S1033. Determine the root cause hypothesis with the highest confidence score as the target root cause.

[0077] Specifically, by combining the dynamically adjusted evidence weights and the contribution of each piece of evidence to the root cause, each root cause hypothesis is calculated. Credibility score The calculation formula is as follows:

[0078] in, This indicates the total number of pieces of evidence of the fault.

[0079] Based on the calculated confidence scores, one or more root cause hypotheses with the highest scores are selected as the final target root cause output.

[0080] like Figure 9 The diagram shown is another step flowchart of the IoT connection failure root cause localization method provided in an embodiment of the present invention, referred to... Figure 9As an optional implementation, the IoT connectivity failure root cause localization method further includes the following steps: S201. Predict the connection parameters of IoT devices for future periods based on the historical trend of connection parameter data. S202. Determine the confidence prediction value of each fault root cause hypothesis based on the predicted values ​​of the connection parameters; S203. Provide early warning of faults based on the reliability prediction value.

[0081] Specifically, the embodiments of the present invention can not only be used for root cause localization after an IoT connection failure occurs, but also for predicting IoT connection failures. Specifically, based on the historical trend of the collected connection parameter data of the IoT device, the predicted value of the connection parameter of the IoT device in the future period is predicted. The predicted value of the connection parameter is used to replace the aforementioned connection parameter data, and the aforementioned root cause localization process is executed to obtain the confidence prediction value of each root cause hypothesis. Based on the confidence prediction value, it can be determined whether a connection failure will occur, thereby providing a fault warning.

[0082] The system continuously analyzes the historical RSRP data of each water meter. For example, water meter The RSRP value, although consistently above the fault threshold over the past 24 hours, exhibits a continuous linear downward trend (slope k < 0 and |k| exceeds the preset threshold). Even Even if there is no current fault, the system will predict that the RSRP will fall below the fault threshold within the next 12 hours based on trends, and generate a "Predictive Diagnostic Warning: Water Meter [ The signal strength continues to decline and is expected to go offline in 12 hours. It is recommended to check the antenna or location. In some optional embodiments, the present invention can also detect hidden faults, such as water meters. The report is online, but the CMP platform has not received its heartbeat packets or data reports for a long time. The system will analyze its TCP retransmission count and DNS resolution latency. If the TCP retransmission count is abnormally high, the system will use it as evidence of "poor link quality" and increase the credibility score of "network link failure".

[0083] The method flow of the embodiments of the present invention has been described above. It can be understood that the embodiments of the present invention calculate the credibility of the root cause hypothesis of the failure based on dynamic evidence weight and group behavior analysis, thereby achieving accurate root cause location of IoT connection failures and improving the accuracy, timeliness and intelligence level of IoT connection failure root cause location.

[0084] Compared with the prior art, the embodiments of the present invention have the following advantages: 1) The evidence weight of fault evidence is dynamically adjusted based on at least one of the factors of time, geographical location and equipment service type. This solves the problem of static and rigid weights in the existing technology, which cannot adapt to dynamic changes in the network environment and differences in equipment type. It significantly improves the accuracy and robustness of fault diagnosis and reduces false alarms and false negatives.

[0085] 2) When diagnosing a single device, the confidence score of the root cause hypothesis is corrected by comparing it with the group behavior baseline of the device group to which it belongs. This solves the problem of inaccurate diagnosis caused by ignoring the group correlation of IoT devices in the existing technology. It can effectively distinguish between single device failures and group failures, and greatly improve the accuracy of root cause location, especially when judging network-side or shared resource failures.

[0086] 3) Based on the historical trend analysis of device connection parameters, fault prediction and early warning are generated, which solves the limitation of existing technologies that can only diagnose after the fact. It realizes the transformation from passive response to active prediction, enabling maintenance personnel to discover potential risks and intervene in handling them before faults occur, thereby avoiding service interruption and reducing losses.

[0087] 4) The diagnostic evidence set and decision rules for hidden faults where the device is online but the application layer data is not communicated solve the problem of difficulty in finding and diagnosing hidden faults in the existing technology. By introducing evidence such as application layer heartbeat, TCP retransmission, and DNS resolution delay, it can identify deeper network or application problems and fill the gap in traditional diagnosis.

[0088] like Figure 10 The diagram shown is a structural schematic of the IoT connection failure root cause location device provided in an embodiment of the present invention. (Refer to...) Figure 10 This invention provides an IoT connectivity failure root cause location device, comprising: The fault evidence generation module is used to acquire connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context of the IoT device. The contribution and correction factor determination module is used to calculate the contribution of each fault evidence to multiple preset fault root cause hypotheses, and to determine the group behavior correction factor corresponding to each fault evidence based on the group behavior baseline of the device group to which the IoT device belongs. The credibility calculation module is used to determine the credibility score of each failure root cause hypothesis based on evidence weight, contribution, and group behavior correction factor, and to determine the target failure root cause based on the credibility score.

[0089] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0090] This invention also provides an electronic device, comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for communication between the processor and the memory. When the program is executed by the processor, it implements the aforementioned method for locating the root cause of IoT connection failures. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0091] like Figure 11 The diagram shown is a hardware structure schematic of an electronic device provided in an embodiment of the present invention. (Refer to...) Figure 11 This invention provides an electronic device, comprising: The processor 1101 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention. The memory 1102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1102 and is called and executed by the processor 1101 to execute the IoT connection failure root cause localization method of the embodiments of this invention. Input / output interface 1103 is used to implement information input and output; The communication interface 1104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1105 transmits information between various components of the device (e.g., processor 1101, memory 1102, input / output interface 1103, and communication interface 1104); The processor 1101, memory 1102, input / output interface 1103 and communication interface 1104 are connected to each other within the device via bus 1105.

[0092] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0093] like Figure 12 The diagram shown is a structural schematic of the storage medium provided in an embodiment of the present invention. (Refer to...) Figure 12 The present invention also provides a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more programs 1201, which can be executed by one or more processors to implement the above-mentioned IoT connection failure root cause location method.

[0094] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0095] This invention also discloses a computer program product, including a computer program that, when executed by a processor, implements the above-described method for locating the root cause of IoT connection failures.

[0096] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0097] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0098] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0099] The terms "first," "second," "third," "fourth," etc. (if present) in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0100] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the aforementioned blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0101] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the aforementioned functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0102] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0104] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the aforementioned program can be printed, because the aforementioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0105] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0108] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for locating the root cause of IoT connection failures, characterized in that, Includes the following steps: Obtain connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context of the IoT device. The contribution of each piece of fault evidence to multiple preset root cause hypotheses is calculated, and the group behavior correction factor corresponding to each piece of fault evidence is determined based on the group behavior baseline of the device group to which the IoT device belongs. The confidence score of each of the root cause hypotheses is determined based on the evidence weight, the contribution degree, and the group behavior correction factor, and the target root cause is determined based on the confidence score. The connection parameter data includes multiple connection parameter indicators of the IoT device, and the generation of multiple fault evidences based on the connection parameter data specifically includes: Obtain the normal range of each of the connection parameter indicators, and determine whether each of the connection parameter indicators exceeds the corresponding normal range. When the connection parameter index exceeds the corresponding normal index range, the corresponding fault evidence is generated based on the connection parameter index. The initial weight of the corresponding fault evidence is determined based on the parameter type of the connection parameter index. The calculation of the contribution of each piece of fault evidence to the preset multiple root cause hypotheses specifically includes: The probability of association between the fault evidence and each of the fault root cause hypotheses is determined based on an expert knowledge base, historical fault data, or machine learning models. The contribution of the fault evidence to each of the fault root cause hypotheses is determined based on the association probability. The step of determining the group behavior correction factor corresponding to each piece of fault evidence based on the group behavior baseline of the device group to which the IoT device belongs specifically includes: Based on clustering algorithms or business rules, the multiple IoT devices are divided into multiple device groups; The group behavior baseline is determined based on the average normal connection parameters of each IoT device within the device group; Based on the connection parameter index corresponding to the fault evidence, find the corresponding group behavior baseline index from the group behavior baseline; The average current connection parameter value of each IoT device in the device group is determined based on the connection parameter index corresponding to the fault evidence. The group behavior correction factor corresponding to the fault evidence is determined based on the difference between the mean of the current connection parameters and the baseline index of group behavior.

2. The method for locating the root cause of IoT connection failures according to claim 1, characterized in that, The step of dynamically adjusting the evidence weights of each fault piece of evidence based on the context of the IoT device specifically includes: Obtain the context environment parameters of the IoT device, including time parameters, geographical location parameters, and device service type parameters; Obtain the time weight dynamic adjustment function, geographical location weight dynamic adjustment function, and equipment service type weight dynamic adjustment function corresponding to each of the aforementioned fault evidences; The time factor is determined based on the time parameters and the time weight dynamic adjustment function. The geographic location factor is determined based on the geographic location parameters and the geographic location weight dynamic adjustment function. The equipment service type factor is determined based on the equipment service type parameter and the equipment service type weight dynamic adjustment function. The initial weights of the fault evidence are adjusted based on the time factor, the geographical location factor, and the equipment service type factor to obtain the evidence weights.

3. The method for locating the root cause of IoT connection failures according to claim 1, characterized in that, The step of determining the credibility score of each of the root cause hypotheses of failure based on the evidence weight, the contribution degree, and the group behavior correction factor, and determining the target root cause of failure based on the credibility score, specifically includes: The contribution correction value of the fault evidence to the fault root cause hypothesis is determined based on the evidence weight, contribution degree, and group behavior correction factor corresponding to the fault evidence. The confidence score of the root cause hypothesis is determined by summing the contribution correction values ​​of all the failure evidence to the root cause hypothesis. The root causes of the failure with the highest confidence scores are identified as the target root causes of the failure.

4. A method for locating the root cause of IoT connection failures according to any one of claims 1 to 3, characterized in that, The method for locating the root cause of IoT connection failures also includes the following steps: Predict the future connection parameter values ​​of the IoT device based on the historical trend of the connection parameter data. The confidence prediction value of each of the fault root cause hypotheses is determined based on the predicted values ​​of the connection parameters. Fault warnings are issued based on the predicted confidence level.

5. A device for locating the root cause of Internet of Things (IoT) connection failures, characterized in that, The method for implementing the root cause localization of IoT connectivity failures as described in any one of claims 1 to 4 includes: The fault evidence generation module is used to acquire connection parameter data of IoT devices, generate multiple fault evidences based on the connection parameter data, and dynamically adjust the evidence weight of each fault evidence according to the context environment of the IoT device. The contribution and correction factor determination module is used to calculate the contribution of each piece of fault evidence to multiple preset fault root cause hypotheses, and to determine the group behavior correction factor corresponding to each piece of fault evidence based on the group behavior baseline of the device group to which the IoT device belongs. The credibility calculation module is used to determine the credibility score of each of the root cause hypotheses of failure based on the evidence weight, the contribution degree and the group behavior correction factor, and to determine the target root cause of failure based on the credibility score.

6. An electronic device, characterized in that, The electronic device includes a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the computer program is executed by the processor, it implements the IoT connection failure root cause localization method as described in any one of claims 1 to 4.

7. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the IoT connection failure root cause localization method as described in any one of claims 1 to 4.

Images