An internet-based intelligent household appliance fault monitoring, collecting and processing system

Abstract

This invention discloses an Internet-based intelligent home appliance fault monitoring, acquisition, and processing system, relating to the fields of IoT and remote operation and maintenance technology for intelligent home appliances. This invention maps the initial operating data of new devices to a shared feature space through a pre-trained meta-model, and combines this with the operating mode prototype to form an operating baseline. This enables the new device to establish a stable reference system for subsequent judgment even in the absence of fault labels. Addressing the problem of increased misjudgment and false alarm rates in transfer models due to cross-model differences, this invention pre-solidifies the normal operating distribution of new devices through shared feature space alignment and basic operating mode category determination. It also triggers cumulative judgment or reporting mechanisms based on uncertain intervals in mode determination, reducing frequent switching and misclassification at boundary states, and ensuring consistency between the operating baseline and subsequent anomaly judgment criteria.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things and remote operation and maintenance technology for smart home appliances, and in particular to an Internet-based smart home appliance fault monitoring, acquisition and processing system. Background Technology

[0002] Currently, remote operation and maintenance and fault monitoring of smart home appliances typically rely on IoT access capabilities. This involves data collection at the device end, network transmission, and cloud computing to achieve operational status assessment and anomaly alarms. The device side can acquire time-series data related to operation, such as current / power, temperature, speed, and vibration / sound, from the controller or sensing components, and upload it to the cloud platform via the home router or gateway. The cloud platform aggregates data from multiple devices and uses statistical analysis, machine learning, or deep learning methods to establish health assessment and anomaly detection models to identify abnormal patterns and provide fault warnings.

[0003] For mature models that have been in mass production and deployed on a large scale for a long time, the cloud can accumulate a lot of historical operating data and some maintenance / fault records, thereby supporting the training or iteration of more effective diagnostic models. However, when a brand-new home appliance model or key component solution is launched into the market, due to differences in operating condition distribution, structural parameters and control strategies, and the scarcity of fault samples (especially early fault samples with labels), the model often faces the problems of data cold start and insufficient cross-domain generalization.

[0004] To alleviate the lack of samples for new models, existing solutions propose strategies such as transfer learning / domain adaptation, which transfer models trained on similar devices or similar tasks to new devices and fine-tune them using a small amount of data from the new devices. Other solutions adopt relatively lenient thresholds or rules in the early stages of deployment to improve the anomaly detection rate and combine manual or user feedback to correct alarm results.

[0005] However, the above solutions may still bring new problems in the actual deployment of home appliances: On the one hand, due to the differences in equipment structure and control logic, the migration model may experience negative migration or domain shift, which may lead to the misjudgment of the normal characteristics of new equipment as abnormal, resulting in an increase in the false alarm rate; on the other hand, the overly wide threshold strategy is prone to frequent alarms and alarm fatigue, while generating a large amount of low-value data, increasing the cost of subsequent screening and labeling, and affecting the efficiency of model iteration and the effect of early fault feature extraction. Summary of the Invention

[0006] In view of the aforementioned existing problems, the present invention is proposed.

[0007] This invention provides an Internet-based intelligent home appliance fault monitoring, acquisition, and processing system to solve the problems of lack of fault data for new models of home appliances, easy false alarms in migration and threshold alarms, and inefficient iteration.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] This invention provides an internet-based intelligent home appliance fault monitoring, acquisition, and processing system, comprising:

[0010] This includes cloud platforms, target smart home appliances that communicate with the cloud platform, user terminals, and edge computing nodes;

[0011] The cloud platform has a fault diagnosis model library and a meta-model. The model library stores general fault diagnosis models trained based on historical data of various known home appliance models, a set of operating mode prototypes, and a set of fault prototypes generated from known fault data. The meta-model is pre-trained based on multi-dimensional time-series data of the various known models.

[0012] The cloud platform is used to: receive initial operating data of the target smart home appliance, extract features using a meta-model and map them to a shared feature space, and form an operating baseline based on a set of operating mode prototypes; when receiving an anomaly report for the target smart home appliance, obtain the anomaly data fragment corresponding to the anomaly report, and generate a fault prototype description of the target smart home appliance by combining it with a set of fault prototypes; adjust the lightweight parameters of the selected general fault diagnosis model according to the fault prototype description to generate a dedicated fault diagnosis model, and distribute the dedicated fault diagnosis model to the user terminal or edge computing node for online diagnosis and early warning of real-time data of the target smart home appliance.

[0013] As a preferred embodiment of the Internet-based intelligent home appliance fault monitoring, acquisition, and processing system described in this invention, the initial operating data and real-time operating data include time-series sequences of at least two types of operating signals. The cloud platform segments and normalizes the time-series sequences according to a preset time window before inputting them into the meta-model.

[0014] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system of the present invention, the step of forming an operating baseline includes: projecting the key feature vectors output by the meta-model onto the shared feature space via a feature mapping network; calculating the similarity between the projected key feature vectors and the operating mode prototype vectors in the operating mode prototype set; determining the basic operating mode category of the target smart home appliance based on the similarity comparison results, and generating the operating baseline accordingly;

[0015] Within a shared feature space, the cloud platform calculates the similarity between the key feature vectors of the target smart home appliance and the prototype vectors of its operating modes, and normalizes the similarity results to form comparable scores for each operating mode category. The cloud platform determines the basic operating mode category based on the maximum value of the comparable scores, while using the difference between the maximum and the second-largest scores to represent the uncertainty of the category determination. When this difference falls into the uncertainty interval of the mode determination, a cumulative determination or reporting strategy is triggered, so that the category determination process and the uncertainty interval triggering mechanism are connected under the same evaluation scale. The cloud platform also performs cumulative voting based on the comparable scores of multiple consecutive time windows.

[0016] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the operating baseline includes a reference range or statistical description of key feature vectors in the shared feature space, and is adaptively updated according to a preset update rule when the target smart home appliance is in a stable operating state.

[0017] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system of the present invention, the generation of fault prototype description includes: retrieving multiple known fault prototype vectors in the shared feature space that satisfy a preset condition in terms of feature distance to the abnormal data fragment; extracting common abstract features of the multiple known fault prototype vectors; and weightedly fusing the abnormal data fragment features with the common abstract features to obtain a fault prototype vector as the fault prototype description.

[0018] The cloud platform measures the feature distance between abnormal data fragment features and multiple known fault prototypes, and converts the distance measurement results into normalized weights. The cloud platform generates a fusion strength based on the concentration of the normalized weights, and applies upper and lower bounds to the fusion strength, so that the abnormal data fragment features and common abstract features are weighted and fused through a convex combination method to obtain a fault prototype vector as a description of the fault prototype. The cloud platform normalizes the fused fault prototype vector so that the fault prototype descriptions generated by different devices and at different times have a consistent scale in the shared feature space. When the normalized weights are dispersed, the cloud platform adjusts the fusion strength to the lower bound.

[0019] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the common abstract features are obtained through cross-model comparative learning training, and the comparative learning enables similar fault samples to be aggregated in the shared feature space and dissimilar fault samples to be separated in the shared feature space.

[0020] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the lightweight parameter adjustment includes: the meta-model output hierarchical parameter update guidance matrix, used to indicate the update priority of each network layer parameter in the general fault diagnosis model; according to the update priority, only the high-priority network layer parameters are iteratively updated, while the low-priority network layer parameters remain unchanged.

[0021] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the abnormal report is triggered by any of the following methods: the user terminal makes a local judgment based on the deviation of the operating baseline and a preset lenient threshold and then reports it, or the user submits it manually through the human-computer interaction interface of the user terminal.

[0022] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the user terminal or edge computing node loads the dedicated fault diagnosis model, performs online inference on the real-time operating data of the target smart home appliance, and outputs alarm confidence; when the alarm confidence falls into the alarm confidence uncertainty range, the corresponding operating data segment is reported to the cloud platform to trigger the generation of the fault prototype description or model readjustment.

[0023] As a preferred embodiment of the Internet-based smart home appliance fault monitoring, acquisition, and processing system described in this invention, the cloud platform associates and stores the dedicated fault diagnosis model with the device identifier, the operating baseline, and the abnormal report feedback information, and updates the fault diagnosis model library or the fault prototype set according to the associated storage results of multiple target smart home appliances.

[0024] Through the above technical solution, the present invention can achieve at least the following beneficial effects:

[0025] To address the problem of lack of fault samples during cold starts of new home appliances, this invention maps the initial operating data of new devices to a shared feature space through a pre-trained meta-model and combines it with the operating mode prototype to form an operating baseline, enabling the new devices to establish a stable reference system that can be used for subsequent discrimination even in the absence of fault labels.

[0026] To address the issue of increased misjudgment and false alarm rates in migration models due to cross-model differences, this invention pre-solidifies the normal operating distribution of new equipment by aligning shared feature spaces and determining basic operating mode categories. It also uses a cumulative judgment or reporting mechanism triggered by uncertain intervals in mode determination to reduce frequent switching and misclassification at boundary states, ensuring that the operating baseline remains consistent with the subsequent anomaly judgment criteria.

[0027] To address the problem of a large amount of low-value data and difficulty in screening out early fault features due to lenient threshold collection, this invention focuses incremental data collection on abnormal data fragments corresponding to anomaly reports. It also retrieves and weights the abnormal fragments and fault prototype sets within a shared feature space to form a fault prototype vector. This makes the sample source for model updates more targeted and traceable, reducing noise accumulation caused by indiscriminate collection.

[0028] To address the problem of unstable model iteration direction caused by abnormal sample noise and feedback uncertainty, this invention forms a fault prototype vector with drift suppression by fusing normalized weights, fusion strength, and convex combination. Abnormal segments that do not meet preset conditions are entered into a confirmation queue. The confirmation status field is used to manage the sample credibility in a closed loop, so that the fault prototype set and the model update process are updated incrementally based on the confirmation results, avoiding noise samples directly dominating model drift.

[0029] Addressing the contradiction between real-time early warning on the edge and centralized training in the cloud, this invention distributes a dedicated fault diagnosis model to user terminals or edge computing nodes for online inference and triggers segment reporting based on the uncertainty interval of alarm confidence. This achieves a collaborative closed loop between real-time response on the edge and the return of high-value samples from the cloud, enabling model specialization and online monitoring to be continuously connected in the same system link.

[0030] To address the challenge of unifying model version management with multi-device evolution, this invention links and stores dedicated fault diagnosis models, operating baselines, anomaly reports, and feedback confirmation records by device identifier, and manages the library update process using update batch identifiers. This enables multi-device incremental samples and model updates to have a traceable version chain, supporting the continuous evolution and reuse of model libraries and prototype sets. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0032] Figure 1 This is a framework diagram of the Internet-based smart home appliance fault monitoring, acquisition, and processing system in the embodiment. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0034] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way. Example 1:

[0035] like Figure 1 As shown, this application proposes an Internet-based smart home appliance fault monitoring, acquisition, and processing system, including a cloud platform, a target smart home appliance communicating with the cloud platform, a user terminal, and an edge computing node;

[0036] In this embodiment, the data reported by the target smart home appliance, user terminal, and edge computing node to the cloud platform all carry device identifiers and collection timestamps. The collection timestamps are calibrated using a unified clock reference issued by the cloud platform, and the most recent calibration result is cached locally. When the communication link is interrupted, the user terminal or edge computing node caches the unreported data segments in chronological order. The minimum cache duration is set to 300s, with an adjustable range of 60s to 3600s. After the link is restored, the data is retransmitted in chronological order and a retransmission mark is retained. When the cache duration exceeds the available storage limit, the abnormal data segments corresponding to the abnormal reports are retained first, and the earliest non-abnormal segments are discarded. At the same time, the start and end timestamps of the discard interval are recorded to maintain data continuity and traceability.

[0037] The cloud platform has a fault diagnosis model library and a meta-model. The model library stores general fault diagnosis models trained based on historical data of various known home appliance models, a set of operating mode prototypes, and a set of fault prototypes generated from known fault data. The meta-model is pre-trained based on multi-dimensional time-series data of the various known models.

[0038] Furthermore, the pre-training uses appliance model identifiers, operating stage identifiers, and fault category identifiers as data organization indexes. Both normal operation samples and known fault samples use data segments after time window segmentation as basic sample units. The pre-training process adopts a training set and a validation set. The training set accounts for 80% by default, with an adjustable range of 60% to 90%. The validation set accounts for the remaining part. The division is based on stratified sampling according to the time order of the sample identifiers to avoid the same continuous time period entering the training set and the validation set at the same time. When the fault category samples are unbalanced, the training samples are resampled according to the fault category identifiers so that the sample proportion of any fault category in the training set is not less than 1%, and the original distribution is maintained in the validation set to reflect the real deployment scenario.

[0039] In one implementation, the meta-model includes a feature extraction network, a feature mapping network, and a parameter-guided output network. The feature extraction network performs temporal encoding on the input multidimensional time-series data and outputs key feature vectors. The feature mapping network maps the key feature vectors to a shared feature space. The parameter-guided output network outputs hierarchical update priority information corresponding to the network layers of the general fault diagnosis model based on the key feature vectors. The pre-training data of the meta-model is organized according to appliance model, operating mode, and fault category, and includes normal operation samples and known fault samples. The pre-training process includes operating mode representation learning and fault representation learning, forming a feature distribution that can be used for cross-model alignment within the shared feature space.

[0040] Specifically, the hierarchical update priority information is given by update priority flags and update intensity flags that correspond one-to-one with the network layers of the general fault diagnosis model. The update priority flag is used to determine the size of the set of network layers that can be updated. By default, the 30% of network layers with the highest update priority are selected as the high-priority layer set, and the adjustable range is 20%~50%. The setting is based on the trade-off between output stability and false alarm suppression effect on the validation set. The update intensity flag is used to limit the iteration update step size of each network layer. By default, a medium update intensity is used and linear scaling is allowed in the range of 0.5x~2.0x. The scaling is based on the consistency between the number of abnormal data segments and the feedback confirmation records. When the consistency is low, a smaller scaling is used to suppress overfitting and drift.

[0041] The cloud platform is used to: receive initial operating data of the target smart home appliance, extract features using a meta-model and map them to a shared feature space, and form an operating baseline based on an operating mode prototype set; in one embodiment, the shared feature space is represented by feature vectors of a uniform dimension, the operating mode prototype set contains multiple operating mode prototype vectors, each operating mode prototype vector is associated with a basic operating mode category and associated with the baseline statistical description corresponding to that operating mode; the baseline statistical description includes a description of the center position and fluctuation range of the key feature vectors under that operating mode in the shared feature space. After receiving the initial operating data of the target smart home appliance, the cloud platform divides the initial operating data into multiple operating stage datasets according to the working stage identifier of the target smart home appliance, and forms an operating baseline in each operating stage dataset and records the operating stage identifier.

[0042] When receiving an anomaly report for a target smart home appliance, the system obtains the anomaly data fragment corresponding to the anomaly report, and generates a fault prototype description of the target smart home appliance by combining it with a fault prototype set. Based on the fault prototype description, the system performs lightweight parameter adjustments on the selected general fault diagnosis model to generate a dedicated fault diagnosis model, and sends the dedicated fault diagnosis model to the user terminal or edge computing node for online diagnosis and early warning of real-time data of the target smart home appliance.

[0043] In one implementation, the anomaly report includes at least a device identifier, an anomaly trigger timestamp, an anomaly trigger operation stage identifier, an anomaly type identifier, and anomaly confidence information. The anomaly data segment is formed by the cloud platform by extending forward and backward based on the anomaly trigger timestamp, and the start and end offsets of the anomaly data segment are determined by the segment truncation rules corresponding to the anomaly type identifier in the configuration table. When acquiring the anomaly data segment, the cloud platform simultaneously acquires the operation status variables and environment status variables before and after the anomaly trigger, and stores the operation status variables and environment status variables as additional features of the anomaly data segment.

[0044] Furthermore, the default forward extension duration of abnormal data segments is set to 30s, with an adjustable range of 5s to 300s; the default backward extension duration is set to 60s, with an adjustable range of 5s to 300s. The settings are based on the lead time of the target smart home appliance fault symptoms and the speed of fault development. When the abnormal trigger operation phase identifier is missing, the cloud platform uses the most recent valid operation phase identifier before the abnormal trigger timestamp as a substitute and adds a substitution mark. When there are missing measurements of environmental state quantities before and after the abnormal trigger, the environmental state quantities remain missing and a missing measurement mark is added. Abnormal data segments are still truncated according to the predetermined start and end offsets to ensure consistent segment length.

[0045] In this embodiment, the initial running data and real-time running data include time series of at least two running signals. The cloud platform segments and normalizes the time series according to a preset time window before inputting it into the meta-model.

[0046] In one implementation, the multidimensional time-series data consists of multiple operating signals aligned to timestamps. These operating signals include at least two of the following: current or power signals, temperature signals, and equipment operating status quantities. The equipment operating status quantities include at least one of the following: rotational speed, duty cycle, valve opening, operating gear, operating stage identifier, or fault self-check code. The segmentation uses a sliding segmentation method to generate continuous data segments. The normalization process is completed based on the dimensional information of the corresponding model and the statistical description of the operating baseline. When missing sampling points exist, timestamp proximity interpolation is used to fill in the missing points. When there are abrupt changes exceeding a preset pruning rule, the abrupt changes are replaced with representative values ​​of adjacent stable segments according to the pruning rule, while retaining the abrupt change marker.

[0047] For example, the default window length of the preset time window is 10s, with an adjustable range of 1s to 120s. The default window step size is 50% of the window length, with an adjustable range of 10% to 90%. The settings are based on the speed of change in the operating phase of the target smart home appliance and the alarm response time. When the sampling frequency of the operating signals is inconsistent, each operating signal is first resampled to a unified sampling frequency before being segmented. The default unified sampling frequency is 10Hz, with an adjustable range of 1Hz to 200Hz. Resampling uses linear interpolation with timestamp alignment and retains the original sampling point markings. When the proportion of missing sampling points in a single time window exceeds 20%, the time window is marked as a missing window and removed from the similarity calculation, deviation calculation, and model fine-tuning dataset. The missing percentage threshold is 20% by default, with an adjustable range of 5% to 50%.

[0048] Similarly, the trimming rules are executed based on the statistical description of the same operating signal within adjacent stable segments. The determination of abrupt change points adopts a joint determination of amplitude change and duration. The amplitude change threshold is set to 5% of the full scale of the operating signal by default, with an adjustable range of 1% to 20%. The duration threshold is set to 0.5s by default, with an adjustable range of 0.1s to 5s. When abrupt change points occur consecutively and the duration exceeds the upper limit of the duration threshold, the original value of the abrupt change segment is retained and a change marker is added only at the window level to avoid mistried trimming of real fault symptoms as normal fluctuations.

[0049] In this embodiment, forming the operating baseline includes: projecting the key feature vectors output by the meta-model onto the shared feature space via a feature mapping network; calculating the similarity between the projected key feature vectors and the operating mode prototype vectors in the operating mode prototype set; determining the basic operating mode category of the target smart home appliance based on the similarity comparison results, and generating the operating baseline accordingly.

[0050] In one implementation, the similarity calculation employs either cosine similarity or Euclidean distance. When using Euclidean distance, the cloud platform performs scale-consistency processing on the key feature vector and the prototype vector of the operating mode before calculating the distance. The rules for determining the basic operating mode category include a maximum similarity selection rule and a confidence difference judgment rule. When the difference between the maximum similarity and the second-largest similarity is lower than a preset difference threshold, the basic operating mode category is marked as an uncertain category, and the target smart home appliance is triggered to continue reporting subsequent operating data segments to update the operating baseline.

[0051] Furthermore, the preset difference threshold is determined by the cloud platform based on the distribution of the difference between the maximum and second-largest scores in the shared feature space of the initial running data. The default value is the 0.30 quantile of this difference distribution, and the adjustable range is 0.10~0.50 quantile. When the difference is lower than the preset difference threshold and an uncertain category is triggered, the number of time windows used for cumulative judgment is 5 by default, and the adjustable range is 3~30. The cumulative judgment is based on the accumulation of comparable scores of the mode and the basic running mode category is output at once after the accumulation is completed. The number of time windows is not 1 to avoid frequent drift of the running baseline caused by fluctuations in a single time window.

[0052] In this embodiment, when cosine similarity is used, the temperature coefficient is used to adjust the smoothness of the normalized similarity distribution. The temperature coefficient is set to 0.2 by default, and the adjustable range is 0.05~1.0. The setting is based on the number of prototypes of the running mode and the separability of the feature distribution within the running stage. The temperature coefficient is not set to 0 to avoid the normalized distribution degenerating into extreme peaks, which would make the maximum score sensitive to noise. When Euclidean distance is used and scale uniformity is performed, scale uniformity is completed with reference to the description of the center position of the running baseline and the description of the fluctuation range. When the fluctuation range is too small and the scale is magnified, the lower limit of the fluctuation range is truncated to the corresponding value of its historical sample quantile. The quantile is set to 0.05 by default, and the adjustable range is 0.01~0.10 to ensure the numerical stability of the distance calculation.

[0053] Within a shared feature space, the cloud platform calculates the similarity between the key feature vectors of the target smart home appliance and the prototype vectors of the operating modes one by one, and normalizes the similarity results to form comparable scores for each operating mode category. The cloud platform determines the basic operating mode category based on the maximum value of the comparable scores, and uses the difference between the maximum and the second largest scores to represent the uncertainty of the category determination. When this difference falls into the uncertainty interval of the mode determination, a cumulative determination or reporting strategy is triggered, so that the category determination process and the uncertainty interval triggering mechanism are connected under the same evaluation scale. The cloud platform also performs cumulative voting based on the comparable scores of multiple consecutive time windows to reduce the impact of single time window fluctuations on the operating baseline. When the operating baseline includes statistical descriptions, the cloud platform uses the mean and covariance formed under stable operating conditions to measure the distance deviation of features, and converts the distance measurement results into comparable scores to reuse the same category determination logic. The update of the operating mode prototype is limited to execution under stable operating conditions, and a sliding update method is used to integrate new samples, so that the operating baseline is consistent with the basis for subsequent anomaly triggering judgment.

[0054] Specifically, the sliding update method controls the impact of new samples on the prototype vector of the operating mode by the prototype update step size coefficient. The prototype update step size coefficient is set to 0.01 by default, and the adjustable range is 0.001~0.10. The setting is based on the long-term drift speed of the operating mode and the false alarm suppression target. The prototype update step size coefficient is not set to 1 to avoid directly rewriting the prototype due to abnormal fluctuations in a single window. When the duration of the stable operating state is insufficient to form a reliable new sample mean, the prototype update is paused and only the key feature vector trajectory is accumulated. The update is resumed after the accumulated duration of the stable operating state reaches the preset duration threshold.

[0055] In one implementation, the category is determined based on the similarity comparison results. This is achieved within a shared feature space through a chain of segmented features, prototype comparison, confidence normalization, and category determination. The calculation and determination are connected using the same set of similarity results; specifically as follows:

[0056] When the target smart home appliance is The key feature vectors corresponding to each time window are obtained by projection through a feature mapping network. When, compare it with the first in the set of running mode prototypes. Each operating mode prototype vector Perform cosine similarity calculation:

[0057] ,

[0058] in, Indicates the first The characteristics of the first time window and the first A similarity scalar between the prototypes of the operating modes Indicates the first The key feature vectors of each time window in the shared feature space Indicates the first A prototype vector of operating modes, Indicates transpose. Represents the L2 norm;

[0059] To ensure comparability of similarity between different prototypes and facilitate alignment with uncertain intervals, the following steps are taken: The normalized similarity distribution is obtained by using softmax with a temperature coefficient:

[0060] ,

[0061] in, Indicates the first The time window belongs to the first Normalized similarity scores for each operating mode category This represents the temperature coefficient, used to adjust the smoothness of the distribution. This indicates the number of prototype vectors for the running mode. Indicates the prototype index;

[0062] The category determination uses Top-1 and the largest and second-largest difference to represent uncertainty; when ,in, Indicates the first The basic operation mode category determination results for each time window This represents the category index that maximizes the objective function.

[0063] To quantify the separability of this determination, an uncertainty index for the difference is introduced:

[0064] ,

[0065] in, Indicates the first The uncertainty index of the difference between time windows. Indicates to make Take the category index of the maximum value. Indicates to make Take the category index with the second largest value;

[0066] Will Uncertainty interval of mode determination When aligning, when The strategy can trigger the category not to be fixed, to switch to cumulative judgment or reporting, so that the category judgment and the reporting of uncertain intervals are consistent at the indicator level.

[0067] ,

[0068] in, Indicates the lower bound of the uncertain interval. It represents the upper bound of the uncertain interval.

[0069] To reduce the impact of fluctuations within a single time window on the operating baseline, continuous An equivalent implementation of Top-k confidence voting within a time window is to take the largest sum of scores from each category as the base operating mode category:

[0070] ,

[0071] in, Indicates in Within the first time window The cumulative score of the class Indicates the number of time windows used to form the operational baseline. This indicates the base operating mode category used to generate the operating baseline.

[0072] When the operating baseline contains statistical descriptions and you want to leverage the consistency of baseline statistics—distance metrics, classify the operating mode. Statistics under steady-state operation are represented as a mean vector. With covariance matrix Furthermore, Mahalanobis distance is used to measure abnormal deviations, and then the distance is converted into similarity for use in the same decision framework.

[0073] ,

[0074] in, Indicates the first The features of the first time window are relative to the first Mahalanobis distance of baseline-like statistics Indicates the first The mean vector of stable operating characteristics of a class. Indicates the first The covariance matrix of stable operating characteristics, The inverse matrix of the covariance matrix;

[0075] The corresponding distance similarity is:

[0076] ,

[0077] in, This represents the normalized similarity score obtained based on Mahalanobis distance. Indicates the distance scaling factor.

[0078] The update of the prototype vector in the running mode is consistent with the adaptive update in the stable running state, when the state is determined to be stable and the category is... At that time, the corresponding prototype is updated exponentially while maintaining a consistent vector scale:

[0079] ,

[0080] in, This represents the updated runtime prototype vector. This represents the prototype update step size coefficient. This indicates that within the preset update cycle, it has been determined to be a category. And the mean of the key feature vectors that satisfy the stability condition.

[0081] Specifically, similarity calculation within the shared feature space can use vector comparison to connect the logical links of baseline generation: after time window features are mapped to the same space, similarity is calculated one by one with the operational mode prototype, and then normalization is used to obtain comparable scores for each mode; category determination does not need to rely on a single result, the maximum score is used as the candidate category, and the difference between the maximum and the second largest score is used to characterize separability, making it form the same evaluation scale as the uncertainty interval in online diagnosis. When the difference falls into the interval, it is transferred to cumulative determination or reporting, thereby avoiding frequent switching in boundary states; to reduce the impact of short-term fluctuations, the baseline category can adopt a score accumulation method of multiple time windows to form a stable decision; the adaptive update of the operational mode prototype can be limited to stable operating conditions, and new samples are incorporated by sliding update to alleviate misjudgment and false alarm caused by long-term drift, so that the operational baseline is consistent with the judgment criteria for subsequent abnormal triggers.

[0082] In this embodiment, the operating baseline includes the reference range or statistical description of the key feature vector in the shared feature space, and is adaptively updated according to a preset update rule when the target smart home appliance is in a stable operating state.

[0083] In one implementation, the stable operating state is determined by the operating phase identifier being in a stable phase and the operating state quantities satisfying a stability criterion; the stability criterion includes the change amplitude of the operating state quantities being lower than a preset amplitude threshold and continuously satisfying a preset duration threshold. The adaptive update of the operating baseline adopts a phased update strategy: when the target smart home appliance is in a stable phase, the baseline statistical description corresponding to the stable phase is updated; when the target smart home appliance is in an unstable phase, the baseline statistical description remains unchanged and only the key feature vector trajectory is recorded.

[0084] For example, the change range is formed by the difference between the maximum and minimum values ​​of the operating status quantity within a continuous time window. The preset amplitude threshold is set to 3% of the full scale of the operating status quantity by default, with an adjustable range of 1% to 10%. The duration threshold is set to 60s by default, with an adjustable range of 10s to 600s. When the operating phase indicator indicates that it is in the start-up or shutdown phase, even if the change range meets the preset amplitude threshold, it is not determined to be a stable operating state. This ensures that the operating baseline update only occurs in the stable phase and maintains a consistent caliber with subsequent deviation calculations.

[0085] In this embodiment, generating the fault prototype description includes: retrieving multiple known fault prototype vectors in the shared feature space that satisfy a preset condition in terms of distance from the abnormal data fragment features; extracting common abstract features from the multiple known fault prototype vectors; and weightedly fusing the abnormal data fragment features with the common abstract features to obtain a fault prototype vector as the fault prototype description.

[0086] In one implementation, the retrieval is performed using a two-level retrieval process: the first-level retrieval filters the fault prototype set into a candidate set based on the basic operating mode category; the second-level retrieval sorts the candidate set according to a distance metric and selects several fault prototype vectors that meet preset distance conditions. The preset distance conditions are calculated from the baseline statistical description of the basic operating mode category corresponding to the target smart home appliance and are bound to that basic operating mode category; when no fault prototype vector in the candidate set meets the preset distance conditions, the cloud platform marks the abnormal data fragment as an unknown fault candidate and enters the pending confirmation queue.

[0087] Specifically, unknown fault candidates in the pending confirmation queue are stored with an abnormal data fragment identifier as an index and are accompanied by a basic operating mode category and anomaly type identifier. The queue retention period is set to 7 days by default and can be adjusted from 1 day to 30 days. If the confirmation status field of the user terminal is updated within the retention period, the corresponding abnormal data fragment is included in the incremental sample set and the confirmation result identifier is retained. If the confirmation status field is not updated within the retention period, the abnormal data fragment is marked as unconfirmed and removed from the model fine-tuning dataset, but its metadata is still retained for subsequent statistical analysis.

[0088] In this embodiment, the distance metric of the second-level retrieval maintains the same dimension as the similarity metric within the shared feature space. The distance metric defaults to a vector distance equivalent to Euclidean distance, and optionally, when the operating baseline includes a covariance statistical description, a distance equivalent to Mahalanobis distance is used. The number of known fault prototype vectors that meet the preset distance conditions is selected by default as 10, with an adjustable range of 3 to 50. The number is set based on the size of the fault prototype set and the concentration of the retrieval results. When the retrieval results are concentrated, a smaller number is used to enhance the focus of common abstraction, and when the retrieval results are scattered, a larger number is used to avoid missing similar fault modes.

[0089] In one implementation, the common abstract features are represented by common prototype vectors, which are calculated from the plurality of known fault prototype vectors using an aggregation operator. The aggregation operator includes one of mean aggregation, weighted aggregation, or attention aggregation, and performs normalization constraints on the common prototype vectors after aggregation. The common prototype vectors and the set of fault prototype vector identifiers participating in the aggregation together constitute a fault prototype generation record and are stored on a cloud platform.

[0090] In one implementation, the weights for the weighted fusion are jointly determined by the cloud platform based on the anomaly confidence information of the anomaly report, the distance metric between the anomaly data fragment features and the common prototype vector. When the anomaly confidence information is lower than a preset confidence threshold, the weight allocation rule ensures that the proportion of the common prototype vector in the fusion result is higher than the proportion of the anomaly data fragment features; when the anomaly confidence information is higher than the preset confidence threshold, the weight allocation rule ensures that the proportion of the anomaly data fragment features in the fusion result is higher than the proportion of the common prototype vector. The fused fault prototype vector is stored in association with the anomaly data fragment identifier, the basic operating mode category, and the set of fault prototype vector identifiers participating in the retrieval.

[0091] Furthermore, the preset confidence threshold is determined by the cloud platform based on the distribution of anomaly confidence information in historical anomaly reports, with a default value of 0.50 and an adjustable range of 0.20 to 0.80. The setting is based on the consistency between the confirmation result identifier in the user feedback confirmation record and the anomaly confidence information. When anomaly confidence information is missing, the cloud platform sets the anomaly confidence information to 0.50 and adds a missing marker. The weight allocation rule enters a conservative mode according to the missing marker, ensuring that the proportion of common prototype vectors in the fusion result is not less than the proportion of features of abnormal data fragments, thereby reducing the risk of prototype drift caused by missing confidence information.

[0092] The cloud platform measures the feature distance between the features of abnormal data fragments and multiple known fault prototypes, and converts the distance measurement results into normalized weights to weightedly aggregate multiple known fault prototypes to form common abstract features. The cloud platform generates a fusion strength based on the concentration of the normalized weights and applies upper and lower bounds to the fusion strength, so that the features of abnormal data fragments and common abstract features are weighted and fused through a convex combination to obtain a fault prototype vector as a description of the fault prototype.

[0093] For example, the lower bound of the fusion coefficient is set to 0.20 by default, with an adjustable range of 0.05 to 0.40. The upper bound of the fusion coefficient is set to 0.80 by default, with an adjustable range of 0.60 to 0.95. The upper and lower bounds are set based on a trade-off between the stability of the output of the dedicated fault diagnosis model on the validation set and the degree of preservation of individualized expression of abnormal fragments. The fusion coefficient is not set to 0 or 1 to avoid the fusion result being completely dominated by unilateral features, which could lead to the loss of common structures or the erasure of individualized anomalies. The distance scaling factor is used to map the distance metric to the normalized weight space. The distance scaling factor is set to the median of the distance distribution in the shared feature space by default, with an adjustable range of 0.5 times to 2.0 times the median. The setting is based on the degree of concentration of the retrieval weight distribution.

[0094] The cloud platform normalizes the fused fault prototype vectors to ensure that fault prototype descriptions generated by different devices and at different times have a consistent scale within the shared feature space. When the normalization weights are dispersed, the cloud platform adjusts the fusion strength to a lower bound to suppress prototype drift caused by noisy and abnormal fragments dominating the fusion result. When it is necessary to express differences by dimension, the cloud platform can use a gating mechanism to output the fusion strength by dimension, and perform dimensional weighted fusion of abnormal data fragment features and common abstract features to maintain a balance between common priors and individual anomalies.

[0095] In one implementation, the features of abnormal data fragments are weighted and fused with common abstract features. This fusion is achieved within a shared feature space through a chain of common abstractions, fusion coefficients, fusion vectors, and drift suppression. This ensures that the fusion result inherits the common structure of known faults while preserving the individualized abnormal behavior of the target device. Specifically:

[0096] When anomaly data fragments are mapped from the metamodel to the shared feature space to obtain anomaly data fragment feature vectors... And retrieve the results that meet the preset conditions in the shared feature space. Known fault prototype vectors At that time, vector distance is used to characterize the degree of fit between the abnormal segment and each known fault prototype:

[0097] ,

[0098] in, express With the The distance between known fault prototype vectors Represents the feature vector of an abnormal data segment. Indicates the first A known fault prototype vector, Represents the L2 norm, Indicates the index of known fault prototypes;

[0099] When extracting common abstract features, distance is transformed into normalized weights, so that fault prototypes that are closer to the abnormal segments contribute more to the common abstraction:

[0100] ,

[0101] in, Indicates the first Weights of common abstractions for a known fault prototype. This represents the distance scaling factor, used to adjust the rate at which the weights decay with distance. Indicates the summation index. This represents the number of known fault prototypes that participate in the common abstraction.

[0102] Based on the above weights, a common abstract feature vector is obtained by weighted summation. :

[0103] ,

[0104] in, This represents a common abstract feature vector extracted from multiple known fault prototypes;

[0105] When entering the weighted fusion stage, the fusion coefficient should be correlated with whether the commonalities of the retrieval are concentrated, in order to reduce the fault prototype drift caused by noisy and abnormal fragments; the entropy of the weight distribution should be used to measure whether the retrieval is scattered.

[0106] ,

[0107] in, Represents the weight distribution entropy. Represent the natural logarithm function;

[0108] Entropy normalization yields common credibility. When the search is more focused Larger:

[0109] ,

[0110] in, Indicates the credibility of commonalities;

[0111] When forming the fusion coefficient, The mapping is done to convex combination coefficients, and their upper and lower bounds are restricted to prevent the fusion result from being completely dominated by unilateral features:

[0112] ,

[0113] in, This represents the weighted fusion coefficient. This represents a cutoff function used to restrict the input to a given range. Indicates the lower bound of the fusion coefficient. This indicates the upper bound of the fusion coefficient. The aforementioned definition will be used;

[0114] Based on this, a linear convex combination can be used to perform a weighted fusion of abnormal segment features and common abstract features, resulting in an unnormalized representation of the fault prototype vector. :

[0115] ,

[0116] in, This represents the intermediate representation of the fused fault prototype vector. This represents the weighted fusion coefficient. Represents the feature vector of an abnormal data segment. Represents a common abstract feature vector.

[0117] To ensure that fault prototype descriptions generated by different devices and at different times have a consistent scale in a shared feature space, the following measures are taken: Normalization is performed to obtain the fault prototype vector, which serves as the description of the fault prototype. :

[0118] ,

[0119] in, This represents the fault prototype vector, serving as a description of the fault prototype. This represents the intermediate representation after fusion. This represents the L2 norm.

[0120] When abnormal data segments contain sporadic noise or the retrieval weights are scattered, drift suppression is incorporated into the fusion coefficient generation logic to ensure... The impact on the integration is limited to a controllable range:

[0121] ,

[0122] in, Indicates the common credibility threshold. , , The aforementioned definition will be used.

[0123] Similarly, the commonality credibility threshold is used to determine whether the retrieval is sufficiently concentrated to support reliable commonality abstraction. The commonality credibility threshold is set to 0.60 by default, and the adjustable range is 0.30~0.90. The setting is based on the correspondence between the historical retrieval weight distribution entropy and the consistency of user feedback confirmation records. When the commonality credibility is lower than the commonality credibility threshold, the fusion coefficient is fixed at the lower bound and is only allowed to recover to the dynamic fusion coefficient after at least 3 consecutive abnormal segments meet the commonality credibility threshold, so as to suppress the frequent jitter of fusion intensity caused by short-term noise.

[0124] In scenarios requiring dimensional weighting, a gating network is used to output vectorized fusion coefficients, allowing the fusion strength of key dimensions to adapt adaptively; and After splicing, the data is input into the gating network to obtain... :

[0125] ,

[0126] in, This represents the fusion coefficient vector generated by dimension. Represents the sigmoid mapping function. This represents the weight matrix of the gated network. This represents vector concatenation. Represents the bias vector of the gated network;

[0127] Furthermore, after the output of the gated network generates a fusion coefficient vector by dimension, the fusion coefficient vector is smoothed to reduce drastic jumps between dimensions. The smoothing process uses the moving average of adjacent dimensions by default and can be adjusted within a 3-11 dimension window. When the output of the gated network becomes saturated, causing the fusion coefficients of most dimensions to approach 0 or 1, the fusion coefficient vector is truncated by the lower and upper bounds so that the dimensional weighted fusion still satisfies the convex combination constraint and maintains the consistency of the result scale.

[0128] In obtaining Then, weighted fusion is performed according to dimensions to obtain :

[0129] ,

[0130] in, This represents the intermediate representation after weighted fusion across dimensions. Represents a vector consisting entirely of 1s. This represents the Hadamard product. , , Following the aforementioned definition, Similarly, you can press Normalization is performed to obtain the fault prototype description.

[0131] Specifically, weighted fusion is used to combine the individualized manifestations of abnormal segments with the common structures of known fault prototypes into a fault prototype description that can be used for subsequent lightweight adjustments. Before fusion, distance weighting is applied to multiple retrieved fault prototypes to obtain information representations that reflect commonalities. The fusion coefficients do not use fixed values ​​but are related to the concentration of the retrieval results, which suppresses the contribution of commonalities when the retrieval is dispersed and reduces the risk of occasional noise skewing the fault prototype. The fusion form adopts convex combination, which makes it easy to control the proportion of abnormal segments and common abstractions in the results, and normalization ensures that the descriptions obtained from different devices and at different times are on a consistent scale. For low-confidence fusion results, threshold logic can be introduced to limit the dominant role of abnormal segments in the results, thereby mitigating the drift trend of fault prototypes. When more granular expression is required, fusion intensity can be generated at the dimensional level, so that the degree of fusion between key dimensions and non-key dimensions differs, which is closer to the feature structure of multi-source operating signals.

[0132] In this embodiment, the common abstract features are obtained through cross-model comparative learning training. The comparative learning enables similar fault samples to be aggregated in the shared feature space and dissimilar fault samples to be separated in the shared feature space.

[0133] In one implementation, the sample pair construction rules for the contrastive learning include: when two samples correspond to the same fault category and come from different appliance models, the sample pair is marked as a positive sample pair; when two samples correspond to different fault categories, the sample pair is marked as a negative sample pair; when two samples are both normal samples, come from different appliance models, and are in the same operating phase identifier, the sample pair is marked as a positive operating mode sample pair. The contrastive learning training process records the model identifier, operating phase identifier, and fault category identifier for each sample, and retains the mapping relationship between the sample identifier and the original multidimensional time-series data segment in the training dataset.

[0134] In this embodiment, the ratio of positive sample pairs to negative sample pairs in the training batch is set to 1:3 by default, and the adjustable range is 1:1 to 1:5. The ratio is set based on the convergence speed of the number of fault categories and the inter-class separation degree in the shared feature space. When the number of positive sample pairs of the same type of fault across models is insufficient, the number of positive sample pairs of operating modes is maintained first to stabilize the representation of the prototype set of operating modes. The insufficient part is supplemented by sample pairs of the same type and the same fault. At the same time, the supplementation mark is retained to separately count its impact on the aggregation effect in the validation set.

[0135] In this embodiment, the lightweight parameter adjustment includes: the meta-model outputs a hierarchical parameter update guidance matrix to indicate the update priority of each network layer parameter in the general fault diagnosis model; according to the update priority, only the high-priority network layer parameters are iteratively updated, while the low-priority network layer parameters remain unchanged;

[0136] In one implementation, the hierarchical parameter update guidance matrix includes hierarchical guidance information corresponding one-to-one with the network layers of the general fault diagnosis model. The hierarchical guidance information corresponding to each network layer includes at least an update priority marker and an update intensity marker. The update priority marker is used to divide the network layers into a high-priority layer set and a low-priority layer set, and the update intensity marker is used to determine the iterative update step size configuration of each network layer within the high-priority layer set. When the meta-model generates the hierarchical parameter update guidance matrix, it uses fault prototype descriptions, basic operating mode categories, and operating baseline statistical descriptions as part of the joint input features.

[0137] In one implementation, the iterative update process uses a set of training samples corresponding to abnormal data fragments and retrieved known fault prototype vectors to form a fine-tuning dataset. The fine-tuning dataset is then divided into a training subset and a validation subset according to a preset ratio. After each round of updates, the validation subset undergoes a consistency evaluation. The iterative update terminates and outputs a dedicated fault diagnosis model version number when the consistency evaluation result meets a preset convergence criterion. The convergence criterion includes the output stability on the validation subset meeting a preset stability threshold and continuously meeting a preset stability round threshold.

[0138] Specifically, the default ratio of the training subset to the validation subset in the fine-tuning dataset is 80% and 20%, respectively, with an adjustable range of 70%~90% and 10%~30%. The division is based on stratified sampling according to the time order of the outlier data segment identifiers. The maximum number of iterations is set to 200 by default, with an adjustable range of 20~1000. The learning rate is set to 0.0001 by default, with an adjustable range of 0.00001~0.001. The learning rate is set based on the size of the high-priority network layer set and the stability of the validation subset output. The learning rate should not be too large to avoid parameter divergence caused by a small number of outlier segments. When the stability of the validation subset output does not improve within 3 consecutive iterations, the iteration update is terminated and a dedicated fault diagnosis model version number is output. The default number of consecutive iterations is 3, with an adjustable range of 2~10.

[0139] In this embodiment, the anomaly report is triggered by any of the following methods: the user terminal makes a local judgment based on the deviation of the operating baseline and a preset lenient threshold and then reports it, or the user submits it manually through the human-computer interaction interface of the user terminal.

[0140] In one implementation, the deviation is calculated by the user terminal or edge computing node based on key feature vectors generated from real-time operating data and statistical descriptions of the operating baseline. The preset leniency threshold is issued by the cloud platform to the user terminal or edge computing node after the target smart home appliance completes device registration and is stored in association with the basic operating mode category. Different basic operating mode categories correspond to different preset leniency thresholds. When the user terminal triggers a report, it also reports the triggering criteria, which at least include the deviation value, the basic operating mode category, the uncertain category marker, and the corresponding operating stage identifier.

[0141] Furthermore, when the operating baseline is a reference range, the deviation is formed by the extent to which the key feature vector exceeds the reference range boundary. When the operating baseline is a statistical description, the deviation is formed by the distance between the key feature vector and the description of the center position and the description of the fluctuation range, and then converted into a comparable score. The preset lenient threshold is determined by the cloud platform based on the deviation distribution of the initial operating data. The default value is the 0.95th quantile of the deviation distribution, and the adjustable range is 0.90~0.99 quantile. To suppress duplicate reporting, the user terminal sets a minimum reporting interval for the same anomaly type identifier. The minimum reporting interval is set to 300s by default, and the adjustable range is 60s~3600s. When the error is triggered continuously and the minimum reporting interval is met, only the anomaly report with the largest deviation is retained and the anomaly confidence information is updated.

[0142] In this embodiment, the user terminal or edge computing node loads the dedicated fault diagnosis model, performs online inference on the real-time operating data of the target smart home appliance, and outputs the alarm confidence level; when the alarm confidence level falls into the alarm confidence level uncertainty range, the corresponding operating data segment is reported to the cloud platform to trigger the generation of the fault prototype description or model readjustment;

[0143] In one implementation, the alarm confidence uncertainty interval is generated by the cloud platform based on the statistical description of the target smart home appliance's operating baseline and the historical inference output distribution of the dedicated fault diagnosis model, and stored in association with the basic operating mode category. After determining that the alarm confidence falls within the alarm confidence uncertainty interval, the user terminal or edge computing node reports a data segment containing the original sequence of real-time operating data, the corresponding key feature vector, the basic operating mode category, the alarm confidence, and the trigger timestamp. After receiving the reported data segment, the cloud platform puts it into a pending confirmation queue and records the confirmation status field in the queue; the confirmation status field is updated by the user terminal's manual interaction submission result.

[0144] In this embodiment, the alarm confidence level ranges from 0 to 1. The default value of the alarm confidence level uncertainty interval is set to 0.40 to 0.60, and the adjustable range is 0.20 to 0.80. The interval boundary is determined by the historical inference output distribution of the dedicated fault diagnosis model under the constraint of user feedback confirmation records. The boundary is not set to 0 or 1 to avoid failure of the uncertainty triggering mechanism. When the target smart home appliance generates a dedicated fault diagnosis model for the first time and the historical inference output is insufficient, the alarm confidence level uncertainty interval adopts the default value and is updated once according to the historical distribution after accumulating no less than 50 inference outputs. After the update, the default interval is still retained as a fallback interval to cope with distribution changes. Example 2:

[0145] Based on Example 1, the cloud platform associates and stores the dedicated fault diagnosis model with the device identifier, the operating baseline, and the abnormal report feedback information, and updates the fault diagnosis model library or the fault prototype set according to the association storage results of multiple target smart home appliances.

[0146] In one implementation, the associated storage uses a device identifier as the primary key. Each device identifier contains at least a dedicated fault diagnosis model version record, a runtime baseline version record, anomaly report records, and feedback confirmation records. Each anomaly report record is associated with a corresponding anomaly data fragment identifier, and each feedback confirmation record includes a confirmation result identifier and a confirmation timestamp. When updating the fault diagnosis model library or fault prototype set, the cloud platform filters anomaly data fragments according to the confirmation result identifier and forms an incremental sample set. This incremental sample set is archived together with its source device identifier set and an update batch identifier is written into it.

[0147] Furthermore, the selection of incremental sample sets is based on the confirmation result identifier. When the confirmation result identifier is "confirmed", the sample is included in the fine-tuning dataset and used to generate fault prototype vectors. When the confirmation result identifier is "denied", only the sample identifier and the anomaly type identifier are retained for threshold calibration and are not included in the fine-tuning dataset. The update batch identifier is incremented in chronological order and associated with the dedicated fault diagnosis model version record. After any update batch is completed, a snapshot of the model and prototype set of the previous batch is retained. The default number of snapshots retained is 3, and the adjustable range is 1 to 10. When the new batch model does not meet the convergence criterion in the consistency evaluation of the validation subset, it reverts to the snapshot version that most recently met the convergence criterion and records the revert marker.

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

[0149] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. An Internet-based intelligent household appliance failure monitoring collection and processing system, characterized by, include: This includes cloud platforms, target smart home appliances that communicate with the cloud platform, user terminals, and edge computing nodes; The cloud platform has a fault diagnosis model library and a meta-model. The model library stores general fault diagnosis models trained based on historical data of various known home appliance models, a set of operating mode prototypes, and a set of fault prototypes generated from known fault data. The meta-model is pre-trained based on multi-dimensional time-series data of the various known models. The cloud platform is used to: receive initial operating data of the target smart home appliance, extract features using a meta-model and map them to a shared feature space, and form an operating baseline based on a set of operating mode prototypes; when receiving an anomaly report for the target smart home appliance, obtain the anomaly data fragment corresponding to the anomaly report, and generate a fault prototype description of the target smart home appliance by combining it with a set of fault prototypes; adjust the lightweight parameters of the selected general fault diagnosis model according to the fault prototype description to generate a dedicated fault diagnosis model, and distribute the dedicated fault diagnosis model to the user terminal or edge computing node for online diagnosis and early warning of real-time data of the target smart home appliance; The process of generating a fault prototype description includes: retrieving multiple known fault prototype vectors in the shared feature space that satisfy a preset condition in terms of feature distance to the abnormal data fragment; extracting common abstract features from the multiple known fault prototype vectors; and weightedly fusing the abnormal data fragment features with the common abstract features to obtain a fault prototype vector as the fault prototype description. The cloud platform measures the feature distance between abnormal data fragment features and multiple known fault prototypes, and converts the distance measurement results into normalized weights. Based on the concentration of these normalized weights, the cloud platform generates a fusion strength and applies upper and lower bounds to the fusion strength, enabling the abnormal data fragment features and common abstract features to be weighted and fused through a convex combination method, resulting in a fault prototype vector that describes the fault prototype. The cloud platform normalizes the fused fault prototype vector to ensure that fault prototype descriptions generated by different devices and at different times have a consistent scale within the shared feature space. When the normalized weights are dispersed, the cloud platform adjusts the fusion strength to the lower bound. The lightweight parameter adjustment includes: the meta-model outputs a hierarchical parameter update guidance matrix, which is used to indicate the update priority of each network layer parameter in the general fault diagnosis model; according to the update priority, only the high-priority network layer parameters are iteratively updated, while the low-priority network layer parameters remain unchanged; The user terminal or edge computing node loads the dedicated fault diagnosis model, performs online inference on the real-time operating data of the target smart home appliance, and outputs the alarm confidence level. When the alarm confidence level falls into the alarm confidence level uncertainty range, the corresponding operating data segment is reported to the cloud platform to trigger the generation of the fault prototype description or model readjustment.

2. The Internet-based intelligent home appliance fault monitoring, acquisition, and processing system according to claim 1, characterized in that, The initial running data and real-time running data include time series of at least two types of running signals. The cloud platform segments and normalizes the time series according to a preset time window before inputting it into the meta-model. 3.The Internet-based intelligent household appliance fault monitoring, collecting and processing system according to claim 1, characterized in that, The process of forming the operating baseline includes: projecting the key feature vectors output by the meta-model onto the shared feature space via a feature mapping network; calculating the similarity between the projected key feature vectors and the operating mode prototype vectors in the operating mode prototype set; determining the basic operating mode category of the target smart home appliance based on the similarity comparison results; and generating the operating baseline accordingly. Within a shared feature space, the cloud platform calculates the similarity between the key feature vectors of the target smart home appliance and the prototype vectors of its operating modes, and normalizes the similarity results to form comparable scores for each operating mode category. The cloud platform determines the basic operating mode category based on the maximum value of the comparable scores, while using the difference between the maximum and the second-largest scores to represent the uncertainty of the category determination. When this difference falls into the uncertainty interval of the mode determination, a cumulative determination or reporting strategy is triggered, so that the category determination process and the uncertainty interval triggering mechanism are connected under the same evaluation scale. The cloud platform also performs cumulative voting based on the comparable scores of multiple consecutive time windows.

4. The Internet-based intelligent home appliance failure monitoring, collecting and processing system according to claim 1, characterized in that, The operating baseline includes a reference range or statistical description of key feature vectors in the shared feature space, and is adaptively updated according to a preset update rule when the target smart home appliance is in a stable operating state. 5.The Internet-based intelligent household appliance fault monitoring, collecting and processing system according to claim 1, characterized in that, The common abstract features are obtained through cross-model comparative learning training. The comparative learning enables similar fault samples to be aggregated in the shared feature space and dissimilar fault samples to be separated in the shared feature space. 6.The Internet-based intelligent household appliance fault monitoring, collecting and processing system according to claim 1, characterized in that, The anomaly report is triggered by any of the following methods: the user terminal makes a local judgment based on the deviation of the operating baseline and a preset lenient threshold and then reports it, or the user submits it manually through the human-computer interaction interface of the user terminal. 7.The Internet-based intelligent household appliance fault monitoring, collecting and processing system according to claim 1, characterized in that, The cloud platform associates and stores the dedicated fault diagnosis model with the device identifier, the operating baseline, and the anomaly report feedback information, and updates the fault diagnosis model library or the fault prototype set based on the associated storage results of multiple target smart home appliances.

Images