Fault detection method and system of Internet of Things module

Abstract

The invention relates to a fault detection method and system for an Internet of Things module, and the method comprises the following steps: carrying out the real-time collection of the operation data of the Internet of Things module, and carrying out the preprocessing of the operation data, and obtaining the operation parameters of the module; performing fluctuation analysis on the module operation parameters to obtain fluctuation operation parameters, and when the fluctuation operation parameters exceed a fault threshold value, performing fault classification on the Internet of Things module based on the fluctuation operation parameters to obtain a fault type judgment result; and carrying out fault source tracking on the Internet of Things module based on the fault type determination result to obtain fault source data, and carrying out comprehensive analysis on the fault source data to obtain a fault detection report, thereby solving the problem that performance degradation or even sudden fault of the module frequently occurs due to temperature change, voltage fluctuation, communication interference or hardware aging factors, and improving the reliability of the module. If the information cannot be found and processed in time, chain reaction is easily caused, and data loss, service interruption and even safety accidents are caused.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) module technology, and in particular to a fault detection method and system for IoT modules. Background Technology

[0002] With the widespread application of IoT technology in industrial control, intelligent transportation, smart homes, and other fields, IoT modules, as core components connecting physical devices and network systems, directly affect the operational efficiency of the entire system. However, in complex and ever-changing real-world operating environments, modules often experience performance degradation or even sudden failures due to factors such as temperature variations, voltage fluctuations, communication interference, or hardware aging. If these issues are not detected and addressed promptly, they can easily trigger a chain reaction, leading to data loss, service interruptions, and even security incidents. Therefore, building an efficient and accurate fault detection mechanism has become an urgent need to ensure the continuous and reliable operation of IoT systems. Summary of the Invention

[0003] The main technical problem addressed in this application is to provide a fault detection method and system for Internet of Things (IoT) modules. This solves the technical problem that modules often experience performance degradation or even sudden failures due to factors such as temperature changes, voltage fluctuations, communication interference, or hardware aging. If these failures are not detected and addressed in a timely manner, they can easily trigger a chain reaction, resulting in data loss, service interruption, or even security incidents.

[0004] To address the aforementioned technical problems, this application employs a fault detection method for an Internet of Things (IoT) module, comprising the following steps: The operating data of the IoT module is collected in real time and preprocessed to obtain the module's operating parameters. Fluctuation analysis is performed on the module's operating parameters to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, the IoT module is classified into faults based on the fluctuating operating parameters to obtain a fault type determination result. Based on the fault type determination result, the fault source of the IoT module is traced to obtain fault source data, and the fault source data is comprehensively analyzed to obtain a fault detection report.

[0005] Furthermore, the real-time collection of operational data from the IoT module and the preprocessing of the operational data to obtain module operational parameters include: The operation data of the IoT module is collected in real time by multiple types of sensors, and the operation data is processed to unify the data format, converting operation data of different formats into a unified standard format to obtain unified format data. Based on preset data cleaning rules, abnormal data is removed from the uniform format data to obtain a clean data set. The clean data set is then normalized and mapped to a specific numerical range to obtain the module operating parameters.

[0006] Furthermore, the step of performing fluctuation analysis on the module's operating parameters to obtain fluctuating operating parameters includes: The module's operating parameters are divided into time series to obtain parameter data for multiple time periods. The mean of the parameter data for each time period is calculated to obtain the mean of the parameters for each time period. The difference between the mean values ​​of parameters in adjacent time periods is calculated to obtain the mean difference between adjacent time periods. The absolute value of the mean difference between adjacent time periods is then processed to obtain a set of absolute differences. The maximum value in the set of absolute differences is used as the fluctuation operation parameter.

[0007] Furthermore, the step of classifying the IoT module for faults based on the fluctuating operating parameters to obtain a fault type determination result includes: Parameter correlation analysis is performed on the fluctuating operating parameters to obtain a set of correlated parameters, and parameter interaction influence analysis is performed on the set of correlated parameters to obtain interaction influence characteristics; Based on the interactive influence features, a fault feature matching and determination is performed on the preset fault feature library to obtain the fault type determination result.

[0008] Furthermore, the step of performing parameter interaction influence analysis on the set of related parameters to obtain interaction influence characteristics includes: The set of associated parameters is statistically paired to obtain parameter pairing groups, and the parameter pairing groups are analyzed for change trends to obtain trend matrix data including voltage-temperature change values, voltage-power consumption change values, and temperature-power consumption change values. The correlation of the trend matrix data is calculated to obtain parameter correlation values, and the parameter correlation values ​​are then filtered by a threshold to obtain the interaction influence characteristics including strongly correlated parameter pairs and weakly correlated parameter pairs.

[0009] Furthermore, the step of tracing the fault source of the IoT module based on the fault type determination result to obtain fault source data includes: Based on the fault type determination results, component association analysis is performed on the IoT module to obtain a set of suspicious components, and the set of suspicious components is prioritized to obtain a sequence of components to be tested. Based on the sequence of components under test, voltage detection and temperature acquisition are performed on the IoT module to obtain component operation data. Threshold comparison is then performed on the component operation data to identify abnormal component groups. Based on the abnormal component group, the circuit connection analysis of the IoT module is performed to obtain fault location data, and the parameters of the fault location data are verified to obtain fault source data.

[0010] Furthermore, based on the fault type determination result, the component association analysis of the IoT module is performed to obtain a set of suspicious components, including: The fault type determination result is analyzed for fault features to obtain key fault features, and the key fault features are analyzed at the circuit level to obtain the component level sequence. Based on the component hierarchy sequence, circuit topology analysis is performed on the IoT module to obtain component connection relationships. Based on the component connection relationships, signal flow analysis is performed on the IoT module to obtain a set of suspicious components.

[0011] Furthermore, the comprehensive analysis of the fault source data to obtain a fault detection report includes: The fault source data is subjected to a quantitative analysis of fault severity to obtain a fault severity value, and the fault severity value is classified into levels to obtain a fault level identifier. Based on the fault level identifier and fault source data, fault repair suggestions are generated for the IoT module. The fault severity value, fault level identifier and fault repair suggestions are then integrated to form a fault detection report.

[0012] The present invention also provides a fault detection device for an Internet of Things (IoT) module, comprising: The data acquisition module is used to acquire the operating data of the IoT module in real time and preprocess the operating data to obtain the module operating parameters. The analysis module is used to perform fluctuation analysis on the operating parameters of the module to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, the IoT module is classified into faults based on the fluctuating operating parameters to obtain the fault type determination result. The tracking module is used to track the fault source of the IoT module based on the fault type determination result, obtain fault source data, and perform comprehensive analysis on the fault source data to obtain a fault detection report.

[0013] The above solution collects operational data of the IoT module in real time and preprocesses the data to obtain module operating parameters. Fluctuation analysis is performed on these parameters to obtain fluctuating operating parameters. When the fluctuating parameters exceed a fault threshold, the IoT module is classified based on these parameters to obtain a fault type determination result. Based on the fault type determination result, the fault source is traced to obtain fault source data, which is then comprehensively analyzed to generate a fault detection report. This solution addresses the technical problem that modules often experience performance degradation or even sudden failures due to temperature changes, voltage fluctuations, communication interference, or hardware aging. Failure to detect and address these issues promptly can easily trigger a chain reaction, leading to data loss, service interruption, and even security incidents. The solution enables further fault source tracing based on a clear fault type, refining the problem localization from "module anomaly" to specific modules, interfaces, or environmental factors. This provides a clear basis for subsequent maintenance or optimization, avoiding "blind repairs" or repetitive troubleshooting and improving operational efficiency. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of the steps of a fault detection method for an IoT module in one embodiment of the present invention; Figure 2 This is a structural block diagram of a fault detection device for an IoT module in one embodiment of the present invention; Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0016] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] Specifically, the fault detection method for the IoT module in this embodiment includes the following steps: like Figure 1 As shown, Figure 1 This invention provides a fault detection method for an Internet of Things (IoT) module, comprising the following steps: Step S1: Real-time collection of the operating data of the IoT module and preprocessing of the operating data to obtain the module operating parameters.

[0019] Specifically, in the above steps, "real-time acquisition of the operating data of the IoT module" is achieved by continuously acquiring raw data streams such as current, voltage, temperature, signal strength, and protocol layer status codes at a sampling frequency of no less than 10 Hz through sensors and communication interfaces deployed inside or outside the module. Subsequently, "preprocessing the operating data" includes sequentially performing outlier removal (e.g., using the 3σ criterion to filter out sudden noise), timestamp alignment, sliding window smoothing (with a window length of 5 sampling points), and normalization operations, ultimately outputting structured "module operating parameters," such as converting the raw RSSI value into a standardized link quality index. This process fully implements the specific technical paths of the two elements "real-time acquisition" and "preprocessing" in the upper-level solution, ensuring that the data relied upon for subsequent fluctuation analysis is both continuous and reliable. For example, in the long-term operation of the smart meter remote communication module, this preprocessing can effectively eliminate false current spikes caused by instantaneous disturbances in the power grid, avoiding false fault judgments.

[0020] Step S2: Perform fluctuation analysis on the module's operating parameters to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, classify the IoT module for faults based on the fluctuating operating parameters to obtain a fault type determination result.

[0021] Specifically, "fluctuation analysis of the module's operating parameters" quantifies the severity of changes by calculating the first-order difference or sliding standard deviation of each parameter within a continuous time window. For example, the standard deviation of the preprocessed voltage parameter is calculated using a 5-second sliding window, and the result is the "fluctuating operating parameter." When this value exceeds a pre-defined "fault threshold" (e.g., voltage fluctuation standard deviation greater than 0.15 V), the system immediately calls a classification model trained based on a decision tree or SVM, using the current fluctuating operating parameter as input features, and outputs the corresponding "fault type determination result," such as distinguishing between "unstable power supply," "radio frequency interference," or "firmware anomaly." This process strictly corresponds to the complete logical chain from fluctuation analysis to fault classification in the upper-level solution. In the actual operation of the smart meter module, if the voltage fluctuates slightly at high frequency due to grid harmonics, this method can avoid misjudging it as a hardware failure, thereby improving classification accuracy.

[0022] Step S3: Based on the fault type determination result, trace the fault source of the IoT module to obtain fault source data, and perform comprehensive analysis on the fault source data to obtain a fault detection report.

[0023] Specifically, after obtaining the "fault type determination result," the system traces back relevant logs, register states, and historical operating parameters based on a preset fault-source mapping rule table (e.g., "RF interference" corresponds to the antenna interface or nearby electromagnetic devices) to locate the specific abnormal module or external cause. This is "fault source tracing," and the extracted data constitutes "fault source data." Subsequently, this data is cross-compared with module design specifications, environmental records, and similar historical cases. A weighted scoring method (e.g., power supply faults have a weight of 0.4, communication faults 0.35) is used to generate structured text, ultimately forming a "fault detection report." Taking a smart meter IoT module as an example, if the fault is determined to be "firmware abnormal," the system tracks the Bootloader verification log and OTA upgrade records to confirm whether communication interruption is caused by version incompatibility, ensuring that the report content can directly guide on-site maintenance.

[0024] In a specific embodiment, the real-time collection of operational data from the IoT module and the preprocessing of the operational data to obtain module operational parameters include: The operation data of the IoT module is collected in real time by multiple types of sensors, and the operation data is processed to unify the data format, converting operation data of different formats into a unified standard format to obtain unified format data. Based on preset data cleaning rules, abnormal data is removed from the uniform format data to obtain a clean data set. The clean data set is then normalized and mapped to a specific numerical range to obtain the module operating parameters.

[0025] Specifically, through various types of sensors deployed inside or around the module—such as temperature sensors (e.g., DS18B20), current sensing chips (e.g., INA219), RF signal strength monitoring units, and protocol stack status interfaces—raw operational data, including ambient temperature, operating current, supply voltage, RSSI value, and TCP connection status, are collected synchronously. The sampling frequency is set between 5 Hz and 50 Hz according to the parameter characteristics. These data have different initial formats due to different sources; some are hexadecimal register readings, while others are ASCII strings or floating-point sequences. Therefore, data format unification processing needs to be performed, that is, all fields are converted into a key-value pair structure with timestamps according to a predefined data model (e.g., JSON Schema) to form data in a unified format. Next, based on preset data cleaning rules—such as removing values ​​exceeding physically reasonable ranges (e.g., current less than 0 A or greater than 2 A) and discarding records with abnormal timestamp intervals (e.g., intervals between adjacent sampling points exceeding 300 ms)—the data in a uniform format is filtered, retaining valid samples to form a clean dataset. Subsequently, this dataset undergoes data normalization, linearly mapping each dimension of data to the [0,1] interval, thereby eliminating dimensional differences. The final output is the module operating parameters that can be used for subsequent analysis. Taking the NB-IoT communication module in a smart meter as an example, in high-temperature and high-humidity environments, if the original current reading experiences instantaneous jumps due to ADC drift, the above cleaning and normalization effectively suppresses false anomalies, ensuring that the parameters stably reflect the true operating conditions and providing reliable input for fluctuation analysis.

[0026] In a specific embodiment, the step of performing fluctuation analysis on the module's operating parameters to obtain fluctuating operating parameters includes: The module's operating parameters are divided into time series to obtain parameter data for multiple time periods. The mean of the parameter data for each time period is calculated to obtain the mean of the parameters for each time period. The difference between the mean values ​​of parameters in adjacent time periods is calculated to obtain the mean difference between adjacent time periods. The absolute value of the mean difference between adjacent time periods is then processed to obtain a set of absolute differences. The maximum value in the set of absolute differences is used as the fluctuation operation parameter.

[0027] Specifically, the continuously collected and preprocessed module operating parameters are divided into fixed time windows, for example, 10 seconds per time period. One hour's data is divided into 360 consecutive time periods, each containing several sampling points, forming parameter data for multiple time periods. Then, the arithmetic mean of the parameter data within each time period is calculated, i.e., the average of all normalized voltage values ​​within a given time period, yielding the parameter mean for that time period. Next, the difference between the parameter mean values ​​of any two adjacent time periods (e.g., time period k and time period (k+1)) is calculated. The result may be positive or negative, so its absolute value is taken to eliminate directional influence, forming a series of non-negative values, constituting a set of absolute differences. Finally, the maximum value is extracted from this set as the fluctuation operating parameter for this analysis period. This process strictly corresponds to the higher-level terminology of "fluctuation analysis" and "fluctuation operating parameters," without introducing any additional concepts. Taking voltage monitoring of the NB-IoT module in a smart meter as an example, if the power supply of the module gradually becomes unstable due to aging of the power module, and the average voltage drops sharply from 0.72 to 0.58 (after normalization) within a certain 10-second window, the absolute value of the difference between the average values ​​of adjacent time periods is 0.14. If this value is the largest in the entire analysis interval, it is identified as a fluctuating operating parameter. This method avoids directly using raw high-frequency noise data and instead focuses on time-level trend changes, which reduces computational complexity and highlights abnormal fluctuations with engineering significance, facilitating subsequent comparison and judgment with fault thresholds (such as 0.12).

[0028] In a specific embodiment, the step of classifying the IoT module for faults based on the fluctuating operating parameters to obtain a fault type determination result includes: Parameter correlation analysis is performed on the fluctuating operating parameters to obtain a set of correlated parameters, and parameter interaction influence analysis is performed on the set of correlated parameters to obtain interaction influence characteristics; Based on the interactive influence features, a fault feature matching and determination is performed on the preset fault feature library to obtain the fault type determination result.

[0029] Specifically, the process begins by using the currently obtained fluctuating operating parameters (e.g., the maximum difference in average voltage over a given period of 0.14) as a trigger point. This is followed by tracing back to other module operating parameters that are time-synchronized or physically coupled with these parameters—such as average current, temperature readings, and communication retransmission counts within the same time period—to construct a set of related parameters. This step is not a simple listing but rather involves filtering out truly relevant variables based on module hardware topology or historical covariance statistics (e.g., a Pearson correlation coefficient greater than 0.6). Next, a parameter interaction analysis is performed on this set of related parameters. Specifically, a second-order interaction matrix is ​​constructed, and the covariance or mutual information between each pair of parameters is calculated. For example, if a sharp increase in retransmission counts is accompanied by a stable temperature when voltage fluctuations are severe, it indicates that the problem is more likely in the RF front-end than in power supply thermal failure. This type of combination pattern forms the interaction characteristic. Subsequently, the interactive impact feature is compared item by item with entries in a preset fault feature library. This library is generated offline from historical fault samples, and each type of fault (such as "unstable power supply," "poor antenna contact," and "firmware deadlock") corresponds to a set of typical interactive feature vectors and tolerance ranges. The matching process uses Euclidean distance metric. If the distance between the current feature and the center of the "unstable power supply" category is less than the threshold of 0.08, it is determined to be of that type. Taking the NB-IoT module of a smart meter as an example, when the fluctuating operating parameters exceed the limits, if the system detects that the voltage and current drop in the same step, but there is no abnormal retransmission in the communication log, the interactive feature points to aging of the power supply line rather than radio frequency interference, and thus outputs "unstable power supply" as the fault type determination result.

[0030] In a specific embodiment, the step of performing parameter interaction influence analysis on the associated parameter set to obtain interaction influence characteristics includes: The set of associated parameters is statistically paired to obtain parameter pairing groups, and the parameter pairing groups are analyzed for change trends to obtain trend matrix data including voltage-temperature change values, voltage-power consumption change values, and temperature-power consumption change values. The correlation of the trend matrix data is calculated to obtain parameter correlation values, and the parameter correlation values ​​are then filtered by a threshold to obtain the interaction influence characteristics including strongly correlated parameter pairs and weakly correlated parameter pairs.

[0031] Specifically, in actual execution, the parameters in the associated parameter set are first paired to form all possible parameter pairing groups. For example, in the NB-IoT module scenario of smart meters, if the associated parameters include normalized voltage, temperature, and power consumption, then three pairs are generated: (voltage, temperature), (voltage, power consumption), and (temperature, power consumption). Next, for each pair, its changing trend is calculated within the same time window. Specifically, the first-order difference of the two parameter sequences is performed separately, and then the ratio of the difference values ​​or the covariant increment at the corresponding time is calculated to obtain quantitative indicators such as "voltage-temperature change value". The results of all pairings are then organized into a trend matrix data. Subsequently, the Pearson correlation coefficient or Spearman rank correlation coefficient is calculated for each column (i.e., each parameter pair) in the trend matrix data to obtain the parameter correlation value; for example, in a certain operation, the correlation value between voltage and power consumption is 0.82, while that between temperature and power consumption is only 0.31. Finally, these parameter correlation values ​​are filtered based on a preset correlation threshold (e.g., 0.7): those above the threshold are considered strongly correlated parameter pairs, while those below are considered weakly correlated parameter pairs. Together, they constitute the final interaction characteristics. Taking a real-world fault as an example, if the module experiences a temperature rise due to poor heat dissipation, leading to a voltage drop and abnormal power consumption, then voltage-temperature and temperature-power consumption typically show a strong correlation. However, if only the voltage drops suddenly but the temperature remains stable, then voltage-temperature exhibits a weak correlation. Based on this, the system can distinguish between thermal failure and power interruption.

[0032] In a specific embodiment, the step of tracing the fault source of the IoT module based on the fault type determination result to obtain fault source data includes: Based on the fault type determination results, component association analysis is performed on the IoT module to obtain a set of suspicious components, and the set of suspicious components is prioritized to obtain a sequence of components to be tested. Based on the sequence of components under test, voltage detection and temperature acquisition are performed on the IoT module to obtain component operation data. Threshold comparison is then performed on the component operation data to identify abnormal component groups. Based on the abnormal component group, the circuit connection analysis of the IoT module is performed to obtain fault location data, and the parameters of the fault location data are verified to obtain fault source data.

[0033] Specifically, when the system outputs a fault type judgment result such as "unstable power supply," it first maps this type to potentially involved physical components—such as DC-DC regulators, filter capacitors, power input interfaces, etc.—based on the module's hardware design documents and historical fault knowledge base, forming a set of suspected components. Next, based on the criticality of each component in the circuit and its past failure rate (e.g., 0.5 for regulator ICs, 0.3 for capacitors), a weighted scoring method is used to prioritize the suspected component set, generating a sequence of components to be tested. Subsequently, voltage detection (using the module's built-in ADC or external probes, sampling accuracy ±10 mV) and temperature acquisition (using mounted NTC thermistors or infrared sensors) are performed sequentially at the corresponding locations in the IoT module according to this sequence to obtain component operating data under the current conditions. This data is then compared item by item with preset safety thresholds (e.g., regulator output voltage should be 3.3 V ± 0.15 V, temperature should not exceed 75℃), and those exceeding the range are marked, ultimately summarizing them into an abnormal component group. Based on this, the PCB layout diagram and signal flow information of the module are further invoked to analyze the connection relationship of the circuit path where the abnormal component group is located, identify whether there are cold solder joints, open circuits or short circuits, and thus locate the specific fault location data. Finally, an excitation signal (such as injecting test current) is applied to the location and the response parameters (such as voltage drop and temperature rise rate) are monitored. If the measured value deviates from the normal model by more than 10%, the point is confirmed as the real fault point, and the output verification result constitutes the fault source data. Taking the NB-IoT module of a smart meter as an example, if it is determined to be "unstable power supply", the above process may eventually pinpoint an input filter capacitor with degraded capacity, whose voltage ripple reaches 280 mV (200mV over the limit) and has abnormal temperature rise. Circuit analysis confirms that it is located at the main power input, and the parameter verification is consistent. Therefore, this capacitor is the fault source data.

[0034] In a specific embodiment, the step of performing component association analysis on the IoT module based on the fault type determination result to obtain a set of suspicious components includes: The fault type determination result is analyzed for fault features to obtain key fault features, and the key fault features are analyzed at the circuit level to obtain the component level sequence. Based on the component hierarchy sequence, circuit topology analysis is performed on the IoT module to obtain component connection relationships. Based on the component connection relationships, signal flow analysis is performed on the IoT module to obtain a set of suspicious components.

[0035] Specifically, fault characteristic analysis is performed—that is, extracting key indicators supporting the conclusion from the judgment criteria, such as severe RSSI fluctuations, retransmission rate exceeding 40%, but stable power supply parameters; these constitute key fault characteristics. Next, circuit-level analysis is conducted around these characteristics, drilling down the problem level by level to the functional modules according to the module's reference design manual. For example, from "communication anomaly" to the RF front-end subsystem, and then further refined to the power amplifier (PA), filter, or antenna matching network, thus forming a component-level sequence arranged in the order of signal processing. Based on this, the circuit topology diagram of the IoT module (usually stored in Netlist or schematic form) is called to extract the connection relationships of each component in the component-level sequence, identifying which devices are in the same signal path or power supply branch. Subsequently, combined with the data flow direction under typical operating conditions (e.g., from baseband chip → PA → antenna interface), signal flow analysis is performed to eliminate bypass components that are only electrically connected but have no signal interaction, ultimately screening out the devices actually involved in the abnormal signal chain, forming a set of suspected components. Taking the NB-IoT module used in smart meters as an example, if the key fault characteristics show a sudden drop in transmission power while reception is normal, the circuit hierarchy analysis will focus on the transmission path. Topology analysis confirms the π-type matching network between the PA and the antenna switch. Signal flow analysis further points out that if a microcrack occurs in a certain 0402 packaged capacitor in this network, it will directly lead to impedance mismatch. Therefore, this capacitor and its adjacent solder joints are included in the set of suspected components.

[0036] In a specific embodiment, the step of comprehensively analyzing the fault source data to obtain a fault detection report includes: The fault source data is subjected to a quantitative analysis of fault severity to obtain a fault severity value, and the fault severity value is classified into levels to obtain a fault level identifier. Based on the fault level identifier and fault source data, fault repair suggestions are generated for the IoT module. The fault severity value, fault level identifier and fault repair suggestions are then integrated to form a fault detection report.

[0037] Specifically, after obtaining fault source data—for example, locating capacitance decay in the input filter capacitor C12 within the NB-IoT module of a smart meter, with a measured ripple voltage of 280 millivolts across its terminals, significantly exceeding the allowable upper limit of 200 millivolts—the system first performs a quantitative analysis of the fault severity based on preset evaluation rules. This process comprehensively considers actual deviations across multiple dimensions, including the voltage ripple exceeding limits, the accompanying temperature rise, and the duration of the anomaly, deriving a specific fault severity value through weighted scoring. Subsequently, according to established grading standards, this value is mapped to a corresponding grade range, such as "mild," "moderate," or "severe," thereby generating a clear fault level identifier. Based on this, the system combines the fault level identifier with the specific content of the fault source data, matching targeted operational guidance from its built-in repair strategy knowledge base. For example, for a severe-level power filter capacitor failure, it automatically generates a fault repair suggestion: "Immediate shutdown and replacement of capacitor C12 (model: 0603 package, 10 microfarads / 25 volts, X7R material)." Finally, the above-mentioned fault severity values, fault level indicators, and fault repair suggestions are integrated in a unified format to form a fault detection report with a clear structure and complete information.

[0038] Please see Figure 2 , Figure 2 This is a schematic diagram of the framework of an embodiment of the fault detection device for the Internet of Things module of this application. Figure 2 As shown, the fault detection device for the IoT module includes a data acquisition module 1, which is used to acquire the operating data of the IoT module in real time and preprocess the operating data to obtain the module operating parameters; an analysis module 2, which is used to perform fluctuation analysis on the module operating parameters to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, the IoT module is classified into faults based on the fluctuating operating parameters to obtain a fault type determination result; and a tracking module 3, which is used to track the fault source of the IoT module based on the fault type determination result to obtain fault source data and perform comprehensive analysis on the fault source data to obtain a fault detection report.

[0039] Reference Figure 3 This invention also provides a computer device whose internal structure can be as follows: Figure 3As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0040] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0041] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0042] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0043] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0044] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0045] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0046] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0047] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0048] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part 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.) or processor to execute all or part of the steps of the methods of various embodiments of this application. 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.

[0049] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the user through pop-up information or by asking the user to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A fault detection method for an Internet of Things (IoT) module, characterized in that, Includes the following steps: The operating data of the IoT module is collected in real time and preprocessed to obtain the module's operating parameters. Fluctuation analysis is performed on the module's operating parameters to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, the IoT module is classified into faults based on the fluctuating operating parameters to obtain a fault type determination result. Based on the fault type determination result, the fault source of the IoT module is traced to obtain fault source data, and the fault source data is comprehensively analyzed to obtain a fault detection report.

2. The fault detection method for an IoT module according to claim 1, characterized in that, The real-time collection of operational data from the IoT module, followed by preprocessing of the operational data to obtain module operational parameters, includes: The operation data of the IoT module is collected in real time by multiple types of sensors, and the operation data is processed to unify the data format, converting operation data of different formats into a unified standard format to obtain unified format data. Based on preset data cleaning rules, abnormal data is removed from the uniform format data to obtain a clean data set. The clean data set is then normalized and mapped to a specific numerical range to obtain the module operating parameters.

3. The fault detection method for an IoT module according to claim 1, characterized in that, The fluctuation analysis of the module's operating parameters to obtain fluctuating operating parameters includes: The module's operating parameters are divided into time series to obtain parameter data for multiple time periods. The mean of the parameter data for each time period is calculated to obtain the mean of the parameters for each time period. The difference between the mean values ​​of parameters in adjacent time periods is calculated to obtain the mean difference between adjacent time periods. The absolute value of the mean difference between adjacent time periods is then processed to obtain a set of absolute differences. The maximum value in the set of absolute differences is used as the fluctuation operation parameter.

4. The fault detection method for an IoT module according to claim 1, characterized in that, The step of classifying the IoT module for faults based on the fluctuating operating parameters to obtain fault type determination results includes: Parameter correlation analysis is performed on the fluctuating operating parameters to obtain a set of correlated parameters, and parameter interaction influence analysis is performed on the set of correlated parameters to obtain interaction influence characteristics; Based on the interactive influence features, a fault feature matching and determination is performed on the preset fault feature library to obtain the fault type determination result.

5. The fault detection method for an IoT module according to claim 4, characterized in that, The step of performing parameter interaction influence analysis on the set of related parameters to obtain interaction influence characteristics includes: The set of associated parameters is statistically paired to obtain parameter pairing groups, and the parameter pairing groups are analyzed for change trends to obtain trend matrix data including voltage-temperature change values, voltage-power consumption change values, and temperature-power consumption change values. The correlation of the trend matrix data is calculated to obtain parameter correlation values, and the parameter correlation values ​​are then filtered by a threshold to obtain the interaction influence characteristics including strongly correlated parameter pairs and weakly correlated parameter pairs.

6. The fault detection method for an IoT module according to claim 1, characterized in that, The step of tracing the fault source of the IoT module based on the fault type determination result to obtain fault source data includes: Based on the fault type determination results, component association analysis is performed on the IoT module to obtain a set of suspicious components, and the set of suspicious components is prioritized to obtain a sequence of components to be tested. Based on the sequence of components under test, voltage detection and temperature acquisition are performed on the IoT module to obtain component operation data. Threshold comparison is then performed on the component operation data to identify abnormal component groups. Based on the abnormal component group, the circuit connection analysis of the IoT module is performed to obtain fault location data, and the parameters of the fault location data are verified to obtain fault source data.

7. The fault detection method for an IoT module according to claim 1, characterized in that, The comprehensive analysis of the fault source data to obtain a fault detection report includes: The fault source data is subjected to a quantitative analysis of fault severity to obtain a fault severity value, and the fault severity value is classified into levels to obtain a fault level identifier. Based on the fault level identifier and fault source data, fault repair suggestions are generated for the IoT module. The fault severity value, fault level identifier and fault repair suggestions are then integrated to form a fault detection report.

8. A fault detection device for an Internet of Things (IoT) module, characterized in that, include: The data acquisition module is used to acquire the operating data of the IoT module in real time and preprocess the operating data to obtain the module operating parameters. The analysis module is used to perform fluctuation analysis on the operating parameters of the module to obtain fluctuating operating parameters. When the fluctuating operating parameters exceed the fault threshold, the IoT module is classified into faults based on the fluctuating operating parameters to obtain the fault type determination result. The tracking module is used to track the fault source of the IoT module based on the fault type determination result, obtain fault source data, and perform comprehensive analysis on the fault source data to obtain a fault detection report.

9. A computer device, characterized in that, The device includes a memory and a processor that are coupled to each other. The memory stores program instructions, and the processor executes the program instructions to implement the fault detection method for the Internet of Things module according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The device stores program instructions that can be executed by a processor, the program instructions being used to implement the fault detection method for the Internet of Things module according to any one of claims 1 to 7.

Images