A Fault Diagnosis and Analysis Method and System for Rotating Equipment Based on Cloud-Edge Collaboration

Abstract

This invention provides a fault diagnosis and analysis method and system for rotating equipment based on cloud-edge collaboration, belonging to the field of cloud-edge collaboration technology. Specifically, it includes: determining a method for identifying collaborative monitoring devices in rotating equipment based on optimization demand group data and considering the degree of overlap of fault types in the fault diagnosis and analysis results between optimization demand groups where deviations exist; identifying collaborative monitoring devices using this method; and determining a collaborative monitoring optimization scheme for optimization demand groups based on the updated results of collaborative monitoring devices in different optimization demand groups and considering the degree of overlap of fault types in the fault diagnosis and analysis results between optimization demand groups and other optimization groups, thereby improving the reliability of the model's fault identification results for rotating equipment.

Description

Technical Field

[0001] This invention belongs to the field of cloud-edge collaboration technology, and in particular relates to a fault diagnosis and analysis method and system for rotating equipment based on cloud-edge collaboration. Background Technology

[0002] Rotating machinery, as critical equipment, plays a dominant role in large-scale industries such as aerospace, petrochemicals, metallurgy, and power. Research on its fault diagnosis technology is crucial for ensuring safe operation. Since the mid-20th century, NASA, Westinhouse, and Bentley have led the development of related theories and technologies. my country has followed suit since the early 1970s, with several universities, including Xi'an Jiaotong University and Shanghai Jiaotong University, achieving significant results in the field of rotating machinery fault diagnosis technology. Currently, vibration signals are the primary basis for fault diagnosis in academia. However, due to the complex and variable working environment, these signals often contain a large amount of noise and irrelevant information, increasing the difficulty of extracting effective fault features.

[0003] To address the aforementioned technical problems, invention patent application CN202511400964.X, "A Rotating Equipment Fault Diagnosis Method Based on Time-Frequency Feature Decoupling," employs a collaborative mechanism of dual-dimensional feature extraction and multi-index screening to achieve accurate matching between features and fault types. Simultaneously, through multi-scale feature extraction, feature distribution transformation, and sampling, it enhances the model's ability to identify minority-class faults, thereby improving the accuracy and reliability of rotating equipment fault diagnosis. However, the following shortcomings still exist: To identify and process fault types in rotating equipment, vibration signal recognition is used to identify faults. However, since edge nodes are often lightweight diagnostic models, their fault diagnosis results based on vibration signals may not match those of the cloud platform, making it difficult to meet the required accuracy of the fault diagnosis results. Therefore, it is urgent to determine a cloud-edge collaborative monitoring and processing method for different types of rotating equipment based on the identification deviation between the cloud platform's diagnostic model and the edge nodes in different types of rotating equipment, thereby improving the reliability of fault diagnosis and processing and increasing the update and iteration efficiency of the edge node's fault diagnosis model.

[0004] To address the aforementioned technical issues, this application provides a fault diagnosis and analysis method and system for rotating equipment based on cloud-edge collaboration. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides a fault diagnosis and analysis method for rotating equipment based on cloud-edge collaboration, which includes: S1 divides the rotating equipment into different groups based on the type of rotating equipment, and determines the cloud-edge collaborative control method for the group based on the rotating equipment data and fault diagnosis data of the rotating equipment in the group; S2, based on the cloud-edge collaborative control method, determines the deviation of the fault diagnosis analysis results of the rotating equipment in the group, and based on the deviation and the degree of matching between the deviation and the fault diagnosis data of the rotating equipment in the group, determines the optimization requirement group in the group. S3, based on the data of the optimization demand groups and considering the degree of overlap of fault types in the fault diagnosis analysis results between the optimization demand groups where there is a deviation, determines the identification and processing method for the collaborative monitoring devices in the rotating equipment. The collaborative monitoring devices are then identified using this method. Based on the updated results of the collaborative monitoring devices in different optimization demand groups and considering the updated results of the degree of overlap of fault types in the fault diagnosis analysis results between the optimization demand groups and other optimization groups, the collaborative monitoring optimization scheme for the optimization demand groups is determined.

[0006] The beneficial effects of this invention are as follows: Based on the deviation and the degree of matching between the deviation and the fault diagnosis data of the rotating equipment in the group, the optimization needs of the group are determined. By quantitatively analyzing the deviation between the cloud platform and the edge node in the fault diagnosis results, those deviations that are "persistent", "frequent" and highly correlated with the "historical high risk" of the group are identified from among many deviations. In this way, the groups that most urgently need to optimize the algorithm or adjust the strategy are accurately located, that is, those groups that "have serious cloud and edge identification deviations and the problem of large identification deviations occurs frequently", which lays the foundation for further optimization of the cloud-edge collaborative monitoring scheme.

[0007] This study determines the identification and processing method for collaborative monitoring devices in rotating equipment by optimizing demand group data and the degree of overlap in fault types where there are discrepancies in fault diagnosis analysis results between demand groups. Using the optimization demand groups and their internal fault types identified in the previous scheme as input, and by evaluating the proportion of optimization demand degrouping and the correlation between fault types, the model can dynamically distinguish between "overall systemic risk" and "local common risk" in different types of rotating equipment. When the overall risk is high, collaborative monitoring is performed on all high-frequency fault equipment; when the risk focuses on specific fault types, collaborative monitoring is performed only on high-frequency equipment that has experienced these specific faults. This avoids wasting limited cloud computing resources on low-risk equipment while also achieving reliable monitoring of collaborative monitoring equipment, maximizing benefits.

[0008] Furthermore, the rotating equipment is divided into different groups, specifically including: Rotary equipment of the same type should be grouped together.

[0009] Furthermore, the rotating device data in the group includes the number of rotating devices in the group.

[0010] Furthermore, the fault diagnosis data of the rotating equipment includes the number of times the rotating equipment was diagnosed under different fault types.

[0011] Furthermore, the method for determining the cloud-edge collaborative control method of the group is as follows: S11 determines the number of rotating devices in the group based on the rotating device data in the group; S12 uses the fault diagnosis data of the rotating equipment to determine the number of times the rotating equipment in the group was identified under different fault types in the history; S13 determines the cloud-edge collaborative control method for the group based on the number of recognitions and the number of rotating devices in the group.

[0012] Furthermore, the method for determining the collaborative monitoring optimization scheme for the optimization demand group is as follows: S41 determines the number of collaborative monitoring devices in the optimization demand groups based on the update results of the collaborative monitoring devices in different optimization demand groups; S42 determines the updated data of the associated groups for the screened fault types of the optimization requirement group based on the updated results of the degree of overlap of fault types in the fault diagnosis analysis results between the optimization requirement group and other optimization groups where there is a deviation; S43 determines the collaborative monitoring optimization scheme for the optimization demand group based on the number of collaborative monitoring devices in the optimization demand group and the updated data of the associated groups of the filtered fault types of the optimization demand group.

[0013] In a second aspect, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the aforementioned fault diagnosis and analysis method for a rotating device based on cloud-edge collaboration when running the computer program.

[0014] Other features and advantages will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0017] Figure 1 This is a flowchart of a fault diagnosis and analysis method for rotating equipment based on cloud-edge collaboration; Figure 2 This is a flowchart illustrating the method for determining the cloud-edge collaborative control approach for a group; Figure 3 This is a flowchart illustrating the method for determining the optimization requirement group within the group. Detailed Implementation

[0018] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that the invention will be thorough and complete, and the concept of the exemplary embodiments will be fully conveyed to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and therefore their detailed description will be omitted.

[0019] The terms “a,” “one,” “the,” and “the” are used to indicate the existence of one or more elements / components / etc.; the terms “including” and “having” are used to indicate an open-ended meaning of inclusion and that other elements / components / etc. may exist in addition to the listed elements / components / etc.

[0020] Example 1 To solve the above problems, according to one aspect of the present invention, such as Figure 1 As shown, a fault diagnosis and analysis method for rotating equipment based on cloud-edge collaboration is provided, specifically including: S1 divides the rotating equipment into different groups based on the type of rotating equipment, and determines the cloud-edge collaborative control method for the group based on the rotating equipment data and fault diagnosis data of the rotating equipment in the group; S2, based on the cloud-edge collaborative control method, determines the deviation of the fault diagnosis analysis results of the rotating equipment in the group, and based on the deviation and the degree of matching between the deviation and the fault diagnosis data of the rotating equipment in the group, determines the optimization requirement group in the group. S3, based on the data of the optimization demand groups and considering the degree of overlap of fault types in the fault diagnosis analysis results among the optimization demand groups, determines the identification and processing method for collaborative monitoring devices in the rotating equipment, uses the identification and processing method to identify and process collaborative monitoring devices, and determines the collaborative monitoring optimization scheme for the optimization demand groups based on the update results of collaborative monitoring devices in different optimization demand groups and in combination with the update results of fault diagnosis data.

[0021] Furthermore, the rotating equipment is divided into different groups, specifically including: Rotary equipment of the same type should be grouped together.

[0022] Furthermore, the rotating device data in the group includes the number of rotating devices in the group.

[0023] Furthermore, the fault diagnosis data of the rotating equipment includes the number of times the rotating equipment was diagnosed under different fault types.

[0024] Specifically, such as Figure 2 As shown, the method for determining the cloud-edge collaborative control method of the group is as follows: The core decision-making objective of this technical solution is to intelligently and dynamically determine the cloud-edge collaborative control method for a pre-defined group of rotating equipment. This method aims to balance the real-time performance and accuracy of cloud computing resources, edge device load, and fault diagnosis.

[0025] Its core logic is based on the assessment of two key dimensions within a group: group size (number of devices) and the group's failure risk characteristics (historical failure types and frequency). By setting different judgment thresholds, groups are divided into different risk levels, and the most suitable cloud-edge collaboration strategy is matched to each level. Simply put, the larger the group size and the higher the risk, the greater the scope of cloud intervention, and vice versa, thereby achieving optimal resource allocation.

[0026] S11 determines the number of rotating devices in the group based on the rotating device data in the group; Rotating equipment data: refers to basic information describing the overall situation of a specific group. In this step, it specifically refers to the total number of rotating devices contained in the group.

[0027] Number of rotating devices in the group: This is a specific value that represents the size of the group.

[0028] The size of the group is the primary factor determining the coordination strategy. The probability density of failure is completely different between a large group with hundreds of devices and a small group with only a few devices. Determining the group size first provides a basic dividing line for subsequent decisions.

[0029] Specific examples: In the chemical plant setting, technicians have grouped all centrifugal pumps into a "P-100 series centrifugal pump group." By querying the group's ledger information (i.e., rotating equipment data), the system knows that there are currently 15 centrifugal pumps in operation or on standby in this group. Therefore, the number of rotating equipment in the "P-100 series centrifugal pump group" is 15.

[0030] S12 uses the fault diagnosis data of the rotating equipment to determine the number of times the rotating equipment in the group was identified under different fault types in the history; Fault diagnosis data for rotating equipment: This refers to all fault records identified by the diagnostic system during the historical operation of each rotating piece of equipment. Each record must include at least the time of the fault occurrence and the type of fault.

[0031] Number of identifications: This refers to the cumulative number of times a certain type of fault has been diagnosed within a specific historical period. This data is aggregated from the "device level" to the "group level".

[0032] The types of failures that a group has frequently experienced in the past indicate that it carries a higher risk. By statistically analyzing the number of times each device in the group has been identified under different failure types, we can quantitatively depict the "historical failure spectrum" of the group, providing data support for judging the overall risk tendency of the group.

[0033] Specific examples: The system retrieved fault diagnosis data for the rotating equipment of all 15 centrifugal pumps in the "P-100 series centrifugal pump group" over the past year. After statistical analysis, it was found that the equipment in this group was identified with a total of 20 faults due to "bearing wear", 15 faults due to "impeller corrosion", 5 faults due to "mechanical seal leakage", and 3 other occasional faults.

[0034] S13 determines the cloud-edge collaborative control method for the group based on the number of recognitions and the number of rotating devices in the group.

[0035] It is understood that if the number of rotating devices in the group is greater than the preset threshold for the number of rotating devices, the cloud-edge collaborative control method for the group is determined to be that, for all rotating devices in the group, as long as no fault is identified within the most recent preset time period, fault diagnosis and processing are performed simultaneously by the cloud platform and the edge device.

[0036] Preset threshold for the number of rotating devices: A pre-defined value used to determine whether a group belongs to a "large-scale group". For example, it can be set to 10 or 20 devices.

[0037] Cloud-edge collaborative control method: refers to the specific rules for how cloud platforms and edge devices divide tasks and cooperate to perform fault diagnosis.

[0038] When the group size is large, the number of devices is significant, and the absolute probability of failure is also higher. If cloud collaboration is only performed on devices that have recently experienced failures, some new devices in the early stages of failure that have not yet been identified by edge devices may be missed. To ensure the security of large-scale groups, the broadest possible cloud collaboration strategy should be adopted, enabling cloud collaboration on all recently "silent" (failure-notified) devices within the group. This achieves maximum monitoring coverage and avoids missed detections.

[0039] Specific examples: Assume the preset threshold for the number of rotating devices is 10. The "P-100 series centrifugal pump group" has 15 units, which is more than 10. Therefore, the cloud-edge collaborative control method determined by the system for this group is: as long as no fault is identified in any centrifugal pump in the group in the most recent 24 hours, then in the next diagnostic cycle, i.e., the next 24 hours, the data of all devices in the group will be simultaneously submitted to the edge device and the cloud platform for analysis.

[0040] Additionally, it should be noted that if the number of rotating devices in the group is not greater than a preset threshold for the number of rotating devices, the following also applies: S131 determines the total number of identifications for different fault types in the group based on the number of times the rotating devices in the group have been identified in history. Fault types with a total number of identifications greater than a preset threshold are identified as risk fault types. It is then determined whether there are risk fault types in the group. If yes, proceed to step S132. If no, the cloud-edge collaborative control method for the group is determined to be that for all rotating devices in the group that have experienced faults in the most recent preset time period, if no fault is identified in the most recent preset time period, fault diagnosis and processing are performed simultaneously using the cloud platform and edge devices. Total number of identifications: The total number of identifications of all devices in the group under a certain fault type is summed to obtain the total number of historical occurrences of that fault type at the group level.

[0041] Preset frequency threshold: A pre-set frequency value used to determine whether a fault type belongs to the "high-incidence" faults of this group.

[0042] Risk Fault Types: These refer to fault types that have been identified more than a preset threshold in the group's history. These types are the key risk points that the group needs to focus on preventing.

[0043] For small to medium-sized groups, resources are relatively abundant, allowing for more refined risk management, focusing on the types of potential failures. If a group has not historically experienced a particularly high incidence of failures, it indicates that the equipment is operating relatively healthily and stably. If frequent failures do occur, their severity needs further assessment.

[0044] Specific examples: Suppose there is an "N-200 series wind turbine group" with 5 rotating units, which is no more than the preset threshold of 10 units. The system retrieves its historical fault diagnosis data and counts the total number of times each fault type is identified: "blade crack" 8 times, "gear wear" 2 times, and "bearing overheating" 1 time. If the preset threshold is set to 5 times, then "blade crack" (8 times > 5 times) is defined as a risk fault type for this group. The system determines that this group has a risk fault type, and therefore proceeds to step S132.

[0045] If a group has a good historical failure record and no frequent failures, it indicates that the group has a low risk. In this case, there is no need to over-consume cloud resources. Just focus on monitoring devices that have recently "had problems" (failed within the most recent preset period), as these devices may still be in an unstable state.

[0046] Specific examples: Suppose another "A-100 series compressor group" has 8 units, and the total number of fault identifications for all fault types does not exceed 5 (i.e., there are no risky fault types). The cloud-edge collaborative control method determined by the system for this group is as follows: only for the compressors in the group that have experienced any faults in the past year, if no new faults are identified in all rotating equipment in the group within the most recent 24 hours, then in the next diagnostic cycle (the next 24 hours), cloud-edge collaborative diagnostics will be enabled for all of the aforementioned compressors that have experienced any faults in the past year.

[0047] S132 obtains the number of risk fault types in the group, and determines whether the number of risk fault types is greater than a preset risk fault type number threshold. If so, the cloud-edge collaborative control method for the group is determined to be that, for all rotating devices in the group, as long as no fault is identified within the most recent preset time period, fault diagnosis processing is performed simultaneously using the cloud platform and the edge device. If not, the cloud-edge collaborative control method for the group is determined to be that, for all rotating devices in the group that have experienced faults within the most recent preset time period and rotating devices that have experienced risk fault types in the past, as long as no fault is identified within the most recent preset time period, fault diagnosis processing is performed simultaneously using the cloud platform and the edge device.

[0048] Number of risk failure types: refers to the total number of types that are marked as risk failure types in a group.

[0049] Preset threshold for the number of risk fault types: A pre-defined value used to determine whether a group of risks is a "single risk" or a "multiple complex risks". For example, it can be set to 2 or 3 types.

[0050] This step involves quantifying the complexity of risks once they have been identified. If a group exhibits multiple common faults simultaneously, it indicates complex operating conditions, severely aged equipment, or inadequate maintenance, classifying it as a "high-risk group." Conversely, if there are only one or two common faults, the risk is relatively focused and singular.

[0051] If the number of risky fault types exceeds a preset threshold, the uncertainty is high when dealing with a small but complex and diverse group of fault modes. Any single device could suddenly experience one of several faults. Therefore, it is necessary to adopt the most cautious strategy and enable cloud-based collaboration for comprehensive monitoring of all devices within the group to prevent missed detections under complex risks.

[0052] Specific examples: Following the example in S131, the "N-200 series wind turbine group" has one type of risk failure: "blade crack," and the number of such risk failure types is 1. Assuming the preset threshold for the number of risk failure types is set to 2, this condition is not met.

[0053] Case B2b: If the number of risky fault types is not greater than the preset threshold for the number of risky fault types: When the risk type of a group is relatively simple, in addition to monitoring devices that have recently "had problems," it is also necessary to focus on devices that have historically experienced these specific high-risk failures, as they are more likely to fail again. This strategy not only focuses on key areas but also saves more cloud resources than a "full coverage" strategy.

[0054] Specific examples: Continuing with the previous example, the number of risk fault types in the "N-200 series wind turbine group" is 1, which is no greater than the threshold of 2. Therefore, the cloud-edge collaborative control method determined by the system is as follows: for all wind turbines in the group that have experienced any faults in the past year, and for all wind turbines that have historically experienced "blade crack" (i.e., risk fault type) faults, as long as no faults are detected in any of the rotating equipment in the group within the most recent 24 hours, then in the next diagnostic cycle, i.e., the next 24 hours, cloud-edge collaborative diagnosis will be enabled for all wind turbines in the group that have experienced any faults in the past year, and for all wind turbines that have historically experienced "blade crack" (i.e., risk fault type) faults.

[0055] Furthermore, the deviation of the fault diagnosis analysis results of the rotating equipment in the group is determined based on the degree of consistency between the fault diagnosis analysis results of the rotating equipment in the group and the edge nodes of the rotating equipment on the cloud platform.

[0056] Specifically, such as Figure 3 As shown, the method for determining the optimization requirement group within the group is as follows: The core decision-making objective of this technical solution is to identify groups of rotating equipment with existing cloud-edge collaborative control systems that have optimization needs due to problems in their current control strategies or diagnostic models. Essentially, it involves post-evaluation and feedback on the effectiveness of cloud-edge collaborative diagnostics.

[0057] The core logic is to quantitatively analyze the discrepancies between the fault diagnosis results of the cloud platform and edge nodes. These discrepancies signal problems with the accuracy and adaptability of the diagnostic model. The solution uses a progressively layered screening mechanism to identify those discrepancies that are "persistent," "frequent," and highly correlated with groups exhibiting "historical high risk," thereby accurately pinpointing the groups most in need of algorithm optimization or strategy adjustment. Simply put, it identifies groups where "cloud and edge identification discrepancies are relatively severe, and these large discrepancies occur frequently."

[0058] S21 Based on the aforementioned deviation, determine the type of fault where there is a deviation in the fault diagnosis analysis results between the cloud platform and the edge node of the rotating equipment, and use it as the type of fault to identify the deviation. In the above steps, it is determined whether the number of identified deviation fault types in the group is greater than the preset threshold for the number of deviation fault types. If yes, the group is determined to belong to the optimization requirement group; otherwise, proceed to step S22. Discrepancy refers to the objective fact that the cloud platform and edge nodes obtain inconsistent analysis results after performing fault diagnosis on the same rotating equipment for the same period of time. Inconsistency can be reflected in different fault types, different fault degrees, or situations where one party diagnoses a fault while the other diagnoses it as normal.

[0059] Cloud platform: refers to a centralized server or cloud service with powerful computing capabilities and big data storage and analysis capabilities, which usually runs more complex diagnostic models with a lower update frequency.

[0060] Edge nodes: refer to embedded devices, gateways, etc. deployed at or near the equipment site, responsible for collecting data in real time and running lightweight, fast-response diagnostic models.

[0061] Identification bias fault type: This refers to those fault types in a group's historical diagnostic records where "cloud and edge diagnostic results are inconsistent". For example, if a device in the group was once diagnosed as "bearing wear" by the cloud but "normal" by the edge diagnostic, then "bearing wear" would be recorded as an identification bias fault type for that group.

[0062] This step is fundamental to identifying optimization needs. It starts with macroscopic deviations, transforming the vague concept of "inconsistency" into a concrete, statistically verifiable list of fault types. This provides the raw data for subsequent quantitative analysis. Its significance lies in linking inconsistencies in the diagnostic model with specific fault phenomena (such as wear and corrosion).

[0063] Specific examples: Looking back at the previous "P-100 series centrifugal pump group" (15 pumps, employing a full-coverage cloud-edge collaborative strategy), the system summarized all collaborative diagnostic records over the past month and identified 10 instances of inconsistent diagnostic results. These 10 discrepancies involved the following fault types: "bearing wear" (occurring 6 times) and "impeller corrosion" (occurring 4 times). Therefore, the identified discrepancy fault type set for this group is {"bearing wear", "impeller corrosion"}.

[0064] Preset threshold for the number of fault types with diagnostic deviations: A pre-defined value used to determine whether there are too many types of faults with diagnostic deviations in a group. If the deviations involve too many types of faults, it indicates that the problem may be more widespread than an isolated case.

[0065] This is a preliminary screening. If a group exhibits diagnostic biases across multiple fault types, it indicates poor overall performance of its cloud-edge collaboration, potentially involving issues with the universality of multiple diagnostic models. Such groups should be prioritized for inclusion in the optimization requirement group.

[0066] Specific examples: Assume the preset threshold for the number of deviation fault types is 3. The number of identified deviation fault types for the "P-100 series centrifugal pump group" is 2 ("bearing wear" and "impeller corrosion"). Since 2 is not greater than 3, it does not meet the condition of being directly identified as an optimization demand group, and needs to proceed to step S22 for more detailed analysis.

[0067] S22 will select the identification deviation fault type as the fault type in which the number of times the fault diagnosis analysis results between the cloud platform and the edge node of the rotating equipment deviates from the identified deviation fault type is greater than the preset deviation number threshold. Preset deviation frequency threshold: A pre-set frequency value used to determine whether a diagnostic deviation of a fault type belongs to "frequent" deviation.

[0068] Fault type filtering: Fault types selected from the identified deviation fault types that have exceeded a preset deviation frequency threshold. These are the most prominent diagnostic deviation issues in the group.

[0069] This step is "focusing." Not all occasional diagnostic biases are worth immediate resource allocation for optimization. By setting a preset threshold for the number of biases, we can filter out noise or low-probability events, focusing attention on recurring, systematic biases. These filtered fault types are where the diagnostic model is most likely to have flaws.

[0070] Specific examples: Continuing with the previous example, assume the preset deviation threshold is 5 times. In the "P-100 series centrifugal pump group," the deviation fault type "bearing wear" has 6 deviations (>5 times), while "impeller corrosion" has 4 deviations (≤5 times). Therefore, "bearing wear" is identified as the screening fault type for this group, while "impeller corrosion" is filtered out.

[0071] The above steps include the following: S221 Determine whether there is a filtering fault type in the group. If yes, proceed to step S222. If no, determine that the group does not belong to the optimization requirement group. If a group exhibits diagnostic biases, but each type of bias is infrequent (not exceeding a preset bias frequency threshold), it indicates that the biases are likely random and sporadic, and the problem is not serious, requiring no immediate optimization. Therefore, this group is determined not to belong to the group requiring optimization.

[0072] Assuming the "bearing wear" deviation count is 3 times and the "impeller corrosion" deviation count is 2 times, both below the threshold of 5 times, then this group does not have any filterable fault types, and the system will determine that it does not belong to the optimization requirement group.

[0073] Case B: If there is a fault type to be filtered, in this example, the deviation of "bearing wear" exceeds the threshold by 6 times. Therefore, there is a fault type to be filtered in this group, and we need to proceed to step S222 for the next step of judgment.

[0074] S222 Obtain the number of filter fault types in the group, and determine whether the number of filter fault types in the group is greater than the preset filter type number threshold. If yes, determine that the group belongs to the optimization requirement group. If not, proceed to step S23.

[0075] Preset filter type quantity threshold: A pre-set value used to determine whether there are too many types of "frequent deviations" in a group.

[0076] This step is to further assess the severity of the problem. If a group has multiple screening failure types, it indicates that its diagnostic model has systematic biases across multiple key dimensions, and the problem is very complex and serious. Such a group undoubtedly needs immediate optimization.

[0077] Case B1: If the number of fault types to be filtered exceeds the preset threshold for the number of filtered types, the diagnostic system for the group with multiple frequent deviations is already unreliable and must be optimized as a whole as an optimization requirement group.

[0078] Specific examples: Assume the preset threshold for the number of screening types is 1. If the "P-100 series" group has two screening fault types, "bearing wear" and "impeller corrosion," which is greater than the threshold of 1, then it is directly determined to belong to the optimization requirement group. However, in this example, there is only one fault type, "bearing wear," which is not greater than the threshold of 1. Therefore, it is necessary to proceed to step S23 to make a more in-depth judgment based on historical risks.

[0079] S23 Based on the identified deviation fault type, filter the degree of overlap between the fault type and the risk fault type in the group, and determine whether the group belongs to the optimization requirement group.

[0080] Furthermore, the above steps include the following: S231 Based on the degree of overlap between the screened fault type and the risk fault type in the group, the fault type that belongs to both the risk fault type and the screened fault type is taken as the overlapping fault type. The overlap coefficient is determined based on the proportion of the overlapping fault type in the risk fault type. It is determined whether the overlap coefficient is greater than the preset overlap coefficient threshold. If so, it is determined that the group belongs to the optimization requirement group. If not, proceed to step S232. Risk Fault Type: Following the previous technical solution, this refers to a high-incidence fault in which the total number of identifications in the group history exceeds a preset threshold.

[0081] Overlapping fault types: These are fault types that fall under both the screening fault type (currently frequent deviations) and the risk fault type (historically high-risk). This is the "focal area" where current and historical problems intersect.

[0082] Overlap coefficient: A quantitative indicator calculated as the proportion of overlapping fault types to the total number of risky fault types. It reflects the frequency of current deviations.

[0083] Preset overlap coefficient threshold: A pre-set ratio value used to determine whether the degree of "deviation hitting the pain point" has reached a dangerous level.

[0084] This is a crucial assessment dimension. If the recurring diagnostic biases in a group happen to be the most frequent types of failures (risk failures) in its history, then the problem is very serious. This means that the diagnostic results from cloud-edge collaboration are frequently conflicting at the most critical risk points that should be accurately diagnosed. This directly leads to high-risk failures being missed or falsely reported, requiring immediate optimization.

[0085] Specific examples: Following the previous example, we need to introduce the "N-200 series wind turbine group" for comparison. Recall that the risk fault type for the "N-200 series wind turbine group" is {"blade crack"} (only one type). Assume that through the analysis in S21 and S22, we obtain that the selected fault type for this group is also {"blade crack"} (because the deviation number of "blade crack" exceeds the threshold). Then, the overlapping fault type is "blade crack", with a quantity of 1. Overlap coefficient = Number of overlapping fault types / Number of risk fault types = 1 / 1 = 100%. Assume the preset overlap coefficient threshold is 50%. Since 100% > 50%, we directly determine that the "N-200 series wind turbine group" belongs to the optimization requirement group.

[0086] S232 determines the identification deviation risk value of the group based on the overlap coefficient and the number of times the identification deviation fault type overlaps with the risk fault type in the group, and determines whether the identification deviation risk value of the group is greater than a preset risk threshold. If so, the group is determined to belong to the optimization demand group; otherwise, the group is determined not to belong to the optimization demand group.

[0087] Identify deviation fault types: The most basic list of deviation fault types.

[0088] Identification Bias Risk Value: A comprehensive risk score that considers both the "proportion of historical pain points hit by the bias" (overlap coefficient) and the "breadth of historical pain points covered by the bias" (the number of overlaps between the identified bias failure type and the risk failure type). A higher value indicates a greater threat to the group's core historical risks from the current diagnostic bias. The calculation formula can be a weighted sum or product of the two, for example: Identification Bias Risk Value = (Number of Overlapping Failure Types) * a + (Overlap Coefficient) * b, where a and b are weighting coefficients.

[0089] Preset risk threshold: A pre-set value used to determine whether the overall deviation risk of the group has become high enough to require optimization.

[0090] This is a more comprehensive and refined assessment method. When the "percentage of pain points hit by the deviation" is not particularly high (e.g., only 30%), but the "range of pain points covered by the deviation" is broad (e.g., the group has 10 historically high-risk faults, and the deviation covers 8 of them), then the overall risk is still very high. This step is to capture this kind of "broad-based" risk and avoid missing any due to a low percentage of a single risk. It ensures the comprehensiveness of the assessment.

[0091] Specific examples: Assume the risk fault types for the "P-100 series centrifugal pump group" are {"bearing wear", "impeller corrosion"} (2 types). The screening fault type is {"bearing wear"} (1 type). The identification deviation fault types are {"bearing wear", "impeller corrosion"} (2 types).

[0092] calculate: Overlapping fault type = {“bearing wear”}, quantity is 1, overlap coefficient = 1 / 2 = 50%.

[0093] The number of overlaps between identified deviation fault types and risk fault types = 2 (because both "bearing wear" and "impeller corrosion" are identified deviation fault types).

[0094] Assuming the formula for calculating the identification bias risk value is: (Number of overlapping fault types * 0.1) + (Overlap coefficient * 0.9), then the identification bias risk value for this group = (2 * 0.1) + (50% * 0.9) = 0.2 + 0.45 = 0.65.

[0095] Assume the preset risk threshold is 0.6. Since 0.65 is greater than 0.6, the "P-100 series centrifugal pump group" is determined to also belong to the optimization requirement group.

[0096] The significance and value of this technical solution lies in constructing a closed-loop feedback mechanism for cloud-edge collaborative diagnostics: the previous solution focused on "strategy formulation," while this solution focuses on "effect evaluation and optimization point identification." The combination of these two approaches forms a complete closed loop from strategy implementation to effect feedback, enabling the entire intelligent operation and maintenance system to possess the ability for self-learning and continuous evolution.

[0097] By employing multi-level screening (from identifying deviation fault types to screening fault types, and then to overlapping fault types) and combining historical risk data, the optimization objective can be refined from "a group" to "diagnostic algorithms for several core fault types within the group," thus avoiding resource waste and achieving "targeted optimization."

[0098] The previously abstract problem of "model inaccuracy" is transformed into a series of quantifiable and comparable indicators, such as the number of biases, overlap coefficients, and risk values ​​for identification biases. This makes the monitoring and evaluation of diagnostic model performance data-driven, providing clear direction and data support for model iteration.

[0099] By continuously monitoring and identifying optimization demand groups, the system can promptly detect and correct diagnostic deviations, especially those related to high-risk faults. This effectively reduces production risks and safety hazards caused by false alarms or omissions, ensuring the long-term, stable, and reliable operation of rotating equipment groups.

[0100] Furthermore, the method for determining the identification and processing method of the collaborative monitoring device in the rotating equipment is as follows: The core decision-making objective of this technical solution is, based on the identified optimization demand groups, to further determine, from a global perspective, which specific rotating equipment within the entire set of rotating equipment needs to be designated as collaborative monitoring equipment. Collaborative monitoring equipment refers to devices that simultaneously utilize cloud platforms and edge nodes for monitoring data analysis and processing at all times. Its purpose is to implement the highest level of monitoring for these critical or high-risk devices, ensuring the accuracy and timeliness of diagnostics.

[0101] The core logic involves evaluating two levels of metrics: first, the overall prevalence of optimization demand groups (i.e., the proportion of optimization demands); and second, the correlation between different optimization demand groups in terms of fault diagnosis bias (i.e., the overlap in the types of faults being screened). These two metrics together reflect the breadth and depth of the diagnostic model problems in the current system. The more prevalent the problems and the more concentrated they are on certain core faults, the more extensive the collaborative monitoring strategy needs to be; conversely, a more precise and targeted collaborative monitoring strategy can be adopted. The final decision is to determine a rule for selecting the set of devices that need to be included in collaborative monitoring.

[0102] It is understandable that the same model is used for fault diagnosis for different types of rotating equipment.

[0103] S31 uses the optimization demand group data to determine the proportion of optimization demand groups in the group, and uses the proportion of optimization demand groups in the group as the optimization demand proportion; In the above steps, it is determined whether the optimization demand ratio is greater than the preset demand ratio threshold. If so, rotating equipment with a historical failure count greater than the preset failure count threshold will be regarded as collaborative monitoring equipment. If not, proceed to step S32.

[0104] It should be noted that the collaborative monitoring device is a rotating device that simultaneously utilizes cloud and edge nodes to analyze and process the monitoring data of the rotating device.

[0105] Optimize demand group data: This refers to the relevant information of rotating equipment groups that were identified in the previous technical solution as needing optimization of their diagnostic models or collaborative strategies, including group identifiers, quantities, etc.

[0106] Optimization Requirement Ratio: A percentage value calculated as: (Number of groups identified as having optimization requirements) / (Total number of all rotating equipment groups) * 100%. It reflects the proportion of groups in the current system where diagnostic models or collaborative strategies have widespread problems.

[0107] This step assesses the severity of the problem from a macro perspective. If the optimization demand ratio is high, it indicates that the problem with the diagnostic model is not isolated or localized, but rather a widespread systemic issue. In this case, it is necessary to adopt the broadest collaborative monitoring strategy, providing double protection for all potentially high-risk devices (measured by the number of historical failures) to prevent a large number of missed reports due to widespread model defects.

[0108] Specific examples: In a steel plant, a total of 20 rotating equipment groups were established, such as "blast furnace blower group," "rolling mill motor group," and "dust collector fan group." Based on the optimization requirement identification in the previous stage, 5 groups were identified as having optimization requirements. Therefore, the calculated optimization requirement ratio is 5 / 20 = 25%.

[0109] Preset demand ratio threshold: A pre-set percentage threshold used to determine whether the common problems of the current diagnostic model have reached the point where full collaborative monitoring needs to be initiated.

[0110] This is the first watershed moment in decision-making. When the proportion of optimization needs exceeds this threshold, it means that more than a certain proportion of the group has diagnostic bias issues, and the system as a whole is in an unreliable state. At this point, the conservative strategy is to prioritize ensuring the monitoring reliability of all potentially high-risk devices (i.e., devices with a high number of historical failures), so they are all directly set as collaborative monitoring devices without considering more refined correlation analysis.

[0111] Specific examples: Assume the preset demand ratio threshold is set to 30%. In the example above, 25% is not greater than 30%, therefore the conditions for directly initiating comprehensive collaborative monitoring are not met, and it is necessary to proceed to step S32 for more detailed analysis.

[0112] S32 determines the overlap of screening fault types between different optimization demand groups based on the degree of overlap of fault types where there is a deviation in fault diagnosis analysis results among the optimization demand groups. Based on the overlap, the fault type is determined, and the optimization demand group to which the fault type belongs is designated as the associated group. Filtering fault types: Following the previous technical solution, this refers to the fault types in a certain optimization requirement group whose number of deviations exceeds a preset deviation threshold. These are the most prominent and systematic diagnostic deviation problems in the group.

[0113] Overlapping situations: This refers to the situation where the same screening fault type appears in different optimization requirement groups. For example, if "bearing wear" is a screening fault type common to both group A and group B, then the overlap for the fault type "bearing wear" is manifested as involving both group A and group B.

[0114] Association Groups: For a specific fault type, all groups of optimization requirements that use that fault type as a filter type are called association groups for that fault type. This concept links the same fault problems scattered in different groups, revealing the commonalities of the problems.

[0115] This step involves "cluster analysis based on the fault dimension." It doesn't focus on the clusters themselves, but rather on which fault types are common to multiple clusters. If a fault type appears in the selected fault types across multiple optimization requirement groups, it indicates that the diagnostic model for that fault may have systemic defects with a wide impact, requiring close attention.

[0116] Specific examples: Suppose there are three optimization requirement groups: Group A (pump group), Group B (fan group), and Group C (compressor group). Their respective fault screening types are: Group A: {"Bearing wear", "Impeller corrosion"}, Group B: {"Blade cracks"}, Group C: {"Bearing wear", "Gear wear"} Therefore, for the fault type "bearing wear," it is a filter fault type for both group A and group C. Thus, group A and group C are the associated groups for the fault type "bearing wear." For the fault type "impeller corrosion," its associated group is only group A; for "blade cracks," only group B; and for "gear wear," only group C.

[0117] The above steps also include the following: Case 1: Using the associated group data in different fault types, determine the number of associated groups in the fault type. If there is a fault type with a number of associated groups greater than a preset threshold, then all rotating devices with a historical fault count greater than a preset fault count threshold will be considered as collaborative monitoring devices.

[0118] Number of associated groups: refers to the total number of optimization requirement groups for a specific fault type, used to filter fault types.

[0119] Preset threshold for the number of associated groups: A pre-set value used to determine whether a fault type belongs to "widespread systemic deviation problems".

[0120] If the number of associated groups for a certain fault type exceeds this threshold, it indicates that the diagnostic bias for that fault is very prevalent and exists in many groups. This means that the entire diagnostic system has a common and fundamental flaw in handling this type of fault. In this case, even if the optimization demand is not high, the concentration of the problem is very high, and the most extensive collaborative monitoring strategy needs to be adopted to conduct comprehensive dual monitoring of all devices that may be affected and have a high number of historical faults.

[0121] Specific examples: Assume the preset threshold for the number of associated groups is set to 2. For "bearing wear," the number of associated groups is 2 (group A and group C), therefore the condition is not met. For other fault types, the number is 1 for each, which also does not meet the condition. Therefore, in this example, there is no fault type with a number of associated groups greater than the threshold, and we need to proceed to case 2.

[0122] Case 2: When there is no fault type with a number of associated groups greater than the preset threshold for the number of associated groups, determine whether the number of fault types with associated groups is less than the preset value for the fault type. If so, then all rotating devices with a number of faults in history greater than the preset threshold for the number of faults and which have experienced the screening of fault types in history will be considered as collaborative monitoring devices. If not, proceed to step S33.

[0123] Fault types with associated groups: refers to fault types with at least one associated group, namely the union of faults that occur in multiple groups (but the number does not reach the threshold of case 1) and faults that occur only in a single group.

[0124] Fault type preset value: A preset value used to determine whether there are too few fault types with common diagnostic deviation problems.

[0125] When there are no widespread (beyond a threshold) systematic deviation failures, it is necessary to assess the diversity of the deviation problems. If the number of common deviation failure types is small, it indicates that the problem is relatively concentrated but not particularly widespread. In this case, a compromise collaborative monitoring strategy can be adopted: in addition to focusing on historically high-frequency failure equipment, special attention should be paid to equipment that has previously experienced these common deviation failures (i.e., screening for failure types), because the risk of similar failures recurring and being misdiagnosed is higher on these devices.

[0126] Specific examples: Continuing the previous example, the fault types for all related groups are "bearing wear," "impeller corrosion," "blade cracks," and "gear wear," totaling four types. Assume the preset value for fault types is three. Decision 4 shows that the number is not less than three; therefore, the condition for directly implementing the compromise strategy is not met, and we need to proceed to step S33 for more refined calculations.

[0127] S33 uses the optimized demand ratio and the associated group data in different fault types to determine the identification and processing method of the collaborative monitoring device in the rotating equipment.

[0128] In the above steps, based on the number of associated groups in different fault types, fault types with multiple associated groups are determined. The average number is determined by the average of the number of fault types with multiple associated groups and the number of fault types with associated groups. It is then determined whether the average number meets the requirements. If yes, rotating equipment with a historical fault count greater than a preset fault count threshold is considered as a collaborative monitoring device. If no, rotating equipment with a historical fault count greater than a preset fault count threshold and which has experienced a screened fault type in the past is considered as a collaborative monitoring device.

[0129] Fault types with multiple associated groups: These are fault types that have more than one associated group. The impact of these fault types covers at least two optimization requirement groups.

[0130] Average Quantity: An average calculated from the number of fault types with multiple associated groups and the number of fault types with associated groups. The calculation formula can be flexibly defined, for example, taking the arithmetic mean of the two or a weighted average. Its purpose is to comprehensively reflect the "concentration" and "breadth" of the deviation problem. The higher the value, the more concentrated and widespread the problem is.

[0131] Meeting the requirement means that the calculated average quantity is greater than a preset average quantity threshold. If this requirement is met, it indicates that the current problem has a high degree of concentration and breadth, and the most extensive collaborative monitoring strategy should be adopted; otherwise, a relatively precise collaborative monitoring strategy should be adopted.

[0132] This step is the final integration of all the information gathered so far. When the proportion of optimization needs is not high, and no single fault type is extremely prevalent, but the overall situation of deviation faults is quite complex, a comprehensive indicator is needed to quantify the severity of the problem. The average number indicator considers both "how many faults are cross-groups" (the number of fault types with multiple related groups) and "how many faults are involved in total" (the number of fault types with related groups), thus providing a good overall picture of the problem. The breadth of collaborative monitoring is determined based on the level of this indicator, achieving a precise match between resource investment and risk level.

[0133] Specific examples: The number of fault types with multiple associated groups: that is, fault types with more than 1 associated group. In this example, only "bearing wear" meets this condition (with 2 associated groups), so the number is 1.

[0134] Number of fault types with associated groups: All fault types with associated groups, namely “bearing wear”, “impeller corrosion”, “blade crack”, and “gear wear”, totaling 4 types.

[0135] Assume the formula for calculating the average number is the arithmetic mean: (Number of fault types with multiple associated groups + Number of fault types with associated groups) / 2 = (1 + 4) / 2 = 2.5.

[0136] Assume the preset average number threshold is 2. If 2.5 > 2, then yes, the average number meets the requirement. Therefore, the final method for identifying and processing collaborative monitoring devices is as follows: all rotating devices with a historical failure count greater than the preset failure count threshold will be considered as collaborative monitoring devices.

[0137] If the calculation results do not meet the requirements, such as an average number of 1.5, which is not greater than the threshold of 2, the determined processing method is as follows: rotating equipment with a number of failures in history that is greater than the preset failure number threshold (e.g., greater than 5 times) and has experienced any of the selected failure types belonging to its group in its historical failure records will be used as collaborative monitoring equipment.

[0138] This technical solution constructs a progressive decision-making chain from "group optimization" to "equipment enhancement": taking the optimization requirement groups identified in the preceding solutions and the selected fault types within them as input, and through layer-by-layer logical judgments, it ultimately outputs a specific and executable list of collaboratively monitored equipment. This makes the entire intelligent operation and maintenance strategy an organic whole, with each step closely linked from macro-strategy to micro-execution.

[0139] By assessing the correlation between the proportion of optimization needs and fault types, it is possible to dynamically distinguish between "comprehensive systemic risks" and "local common risks." When the overall risk is high, all high-frequency faulty devices are monitored collaboratively; when the risk focuses on specific fault types, only high-frequency devices that have experienced these specific faults are monitored collaboratively. This avoids wasting limited cloud computing resources on low-risk devices and maximizes efficiency.

[0140] By introducing a series of quantitative indicators such as the number of associated groups, the number of fault types with associated groups, and the average number, the originally abstract "influence range of model problems" is transformed into calculable and comparable values, providing an objective and scientific basis for the final resource allocation decision.

[0141] Furthermore, the method for determining the collaborative monitoring optimization scheme for the optimization demand group is as follows: The core decision-making objective of this technical solution is to conduct further, dynamic, and personalized evaluations of these optimization need groups after they have been identified and a global collaborative monitoring equipment list has been determined based on the previous solution. This evaluation aims to determine whether a more stringent collaborative monitoring optimization scheme needs to be implemented for these groups. Essentially, it is a feedback-based, iterative optimization strategy adjustment mechanism.

[0142] The core logic is as follows: After the previous round of optimization (i.e., setting certain devices as collaborative monitoring devices according to the previous scheme), the system status has been updated. Based on these updates, this scheme re-examines each optimization requirement group. If, after obtaining initial collaborative monitoring resources, a group still has an insufficient number of collaborative monitoring devices, or if its diagnostic bias problem (characterized by the correlation of fault types) is not alleviated but exacerbated (e.g., new common biases across groups appear), then further optimization measures are needed for this group. For example, lowering the threshold for including its devices in collaborative monitoring (using a smaller fault count threshold) can expand the scope of collaborative monitoring until its reliability reaches expectations.

[0143] S41 determines the number of collaborative monitoring devices in the optimization demand groups based on the update results of the collaborative monitoring devices in different optimization demand groups; In the above steps, it is determined whether the number of collaborative monitoring devices in the optimization demand group is greater than the preset threshold for the number of collaborative monitoring devices. If so, it indicates that the identification reliability of the optimization demand group is high, and therefore the collaborative monitoring optimization scheme of the optimization demand group is determined to be without optimization processing. If not, proceed to step S42. Updated results for collaborative monitoring devices: This refers to the update of the list of devices marked as collaborative monitoring devices in the entire system after the implementation of the previous technical solution (S31-S33). This update will affect each specific optimization requirement group.

[0144] Number of collaborative monitoring devices in an optimization demand group: For a specific optimization demand group, count how many rotating devices within that group are currently included in the global collaborative monitoring device list. This number represents the highest level of monitoring and protection currently enjoyed by that group.

[0145] This step assesses the actual impact of the previous global strategy on individual groups. If a group with optimization needs has already had enough devices included in collaborative monitoring, it indicates that the core risk points of that group have been largely controlled, and its overall identification reliability is high. It may not be necessary to add more stringent optimization schemes for it separately.

[0146] Specific examples: Referring back to the previous example, 120 devices across the plant with more than 5 historical failures were designated as collaborative monitoring devices. Now, let's focus on a specific optimization requirement group, such as the "P-100 series centrifugal pump group" (Group A). ​​Statistics show that 3 of these 120 devices belong to Group A. Therefore, the number of collaborative monitoring devices in this optimization requirement group is 3.

[0147] Preset threshold for the number of collaborative monitoring devices: A pre-set value used to determine whether the number of devices enjoying collaborative monitoring protection within a group with optimization needs is sufficient to support the high identification reliability of the group.

[0148] This is an initial screening for a single group. If the number exceeds the threshold, it indicates that the group has received sufficient monitoring resources and can be considered "basically reliable," requiring no further optimization. If the number is insufficient, it suggests that the group may have monitoring blind spots, necessitating further in-depth analysis.

[0149] Specific examples: Assume the preset threshold for the number of collaborative monitoring devices is set to 3. Group A has 2 collaborative monitoring devices, which is less than 3. Therefore, Group A does not meet the condition of "no optimization required" and needs to proceed to step S42 for further diagnosis.

[0150] S42 determines the updated data of the associated groups for the screened fault types of the optimization requirement group based on the updated results of the degree of overlap of fault types in the fault diagnosis analysis results between the optimization requirement group and other optimization groups where there is a deviation; Specifically, the updated data of the associated groups for the filtering fault types of the optimization demand group includes the updated number of associated groups for the filtering fault types of the optimization demand group.

[0151] The updated overlap result refers to the reassessment of the overlap in fault type selection among different optimization requirement groups after the implementation of the previous round of global collaborative monitoring scheme. This overlap is dynamic, as the implementation of collaborative monitoring may uncover more or less bias.

[0152] Updated data for associated groups of filtered fault types within an optimization requirement group: For a specific optimization requirement group, after an update, how many other optimization requirement groups are associated with each filtered fault type? The most crucial element is the number of updated associated groups.

[0153] This step is to observe whether the "lesions" (screened fault types) in the group show signs of spreading or worsening after the initial collaborative monitoring is implemented. If a fault type that originally only appeared in this group is now appearing in more groups (i.e., the number of updates in related groups increases), it indicates that the problem may be contagious or widespread and requires escalation.

[0154] Specific examples: In the previous assessment, the fault types selected for group A were {"bearing wear", "impeller corrosion"}. At that time, the associated groups for "bearing wear" were groups A, C, and D, a total of 3; the associated group for "impeller corrosion" was only group A, a total of 1. After a period of collaborative monitoring, the system data was updated, and it was found that the "impeller corrosion" problem also began to frequently deviate in group F (which was not previously identified as an optimization requirement group). Therefore, the updated data is as follows: the number of updated associated groups for "bearing wear" remains 3, while the number of updated associated groups for "impeller corrosion" becomes 2 (groups A and F).

[0155] It is understood that the above steps include the following: S421 Based on the update count of the associated groups of the filter fault types of the optimization demand group, determine the filter fault types with multiple associated groups, take the newly added filter fault types with multiple associated groups as secondary filter fault types, determine whether there are secondary filter fault types, if yes, then determine that the collaborative monitoring optimization scheme of the optimization demand group is to take all rotating equipment with a fault count greater than the second preset fault count threshold as collaborative monitoring equipment, if no, then proceed to step S422. Filtering failure type with multiple associated groups: This refers to a filtering failure type where the number of updates to associated groups is greater than 1.

[0156] Secondary screening failure type: This specifically refers to those failure types that have newly become "screening failure types with multiple associated groups" after this update. That is, in the previous evaluation, its number of associated groups was no more than 1, but now it is more than 1.

[0157] If a fault type changes from an "isolated problem" to a "common problem" (fault type secondary screening), this is a very dangerous signal, indicating that the root cause of the problem may be deep-seated, or that the initial collaborative monitoring plan has failed to effectively curb its spread. This necessitates immediate and stronger measures, namely, collaborative monitoring of more high-risk equipment (based on a second preset fault count threshold).

[0158] For group A, the number of associated groups for "bearing wear" was originally 3 (>1), so it is not "newly added". However, the number of associated groups for "impeller corrosion" changed from 1 to 2, which belongs to "newly added screening fault types with multiple associated groups". Therefore, "impeller corrosion" is defined as a secondary screening fault type for group A.

[0159] Scenario A (Secondary screening fault type exists): According to the rules, if a secondary screening of fault types exists, the collaborative monitoring optimization scheme for this optimization requirement group is determined as follows: all rotating equipment with a fault count greater than a second preset fault count threshold is included as collaborative monitoring equipment. This second preset fault count threshold should be smaller than the globally used preset fault count threshold to expand the monitoring scope.

[0160] A specific example (case A): Assuming the global preset fault count threshold is 5 times, and the second preset fault count threshold is set to 3 times, then for group A, the optimization solution is to add all rotating equipment in the entire plant (or at least within group A) with a historical fault count greater than 3 times to the collaborative monitoring equipment list. Since group A has the secondary screening fault type "impeller corrosion" in this example, this solution is triggered. The decision-making process terminates here.

[0161] S422 determines whether there are any newly added filtering fault types in the optimization requirement group. If yes, proceed to step S43. If no, determine that the collaborative monitoring optimization scheme of the optimization requirement group does not require optimization.

[0162] Newly added filterable fault types: These refer to fault types that have newly appeared in the filterable fault type list for this group during this round of updates. In other words, they were not present in the previous assessment but are now included.

[0163] If no secondary screening failure types appear (the problem has not spread to more groups) or new screening failure types appear (the problem has not increased within this group), it indicates that the situation in that group is stable, or even improving. Although the number of internal collaborative monitoring devices is insufficient (a prerequisite for entering S42), the problem has not worsened, so no additional action can be taken for the time being, and observation can continue. This reflects the prudence of the strategy and avoids excessive intervention.

[0164] Specific examples: Assuming that no new fault types are added to Group A, and the remaining fault types are {"bearing wear", "impeller corrosion"}, then according to the rules, the collaborative monitoring optimization scheme for Group A will be determined as "no optimization required". If a new fault type is added to Group A, such as "mechanical seal leakage" becoming a screened fault type, then a more complex comprehensive evaluation needs to be performed in step S43.

[0165] S43 determines the collaborative monitoring optimization scheme for the optimization demand group based on the number of collaborative monitoring devices in the optimization demand group and the updated data of the associated groups of the filtered fault types of the optimization demand group.

[0166] In the above steps, an optimization requirement group that does not require optimization processing is obtained, and it is determined whether the proportion of the optimization requirement group that does not require optimization processing in the optimization group is greater than a preset optimization group proportion threshold. If so, the collaborative monitoring optimization scheme of the optimization requirement group is determined to be that all rotating equipment with a failure number greater than a second preset failure number threshold is regarded as collaborative monitoring equipment. If not, proceed to the next step. Groups of optimization requirements that do not require optimization processing: These are the groups of optimization requirements that were marked as "not requiring optimization processing" in this evaluation process after being judged by S41 and S422.

[0167] Preset optimized group ratio threshold: A pre-set percentage threshold used to determine whether the proportion of the "stable group" is high enough.

[0168] This is a consideration from a global perspective. If most optimization requirement groups are in a stable state of "no optimization needed," it indicates that the overall trend of the system is positive. At this point, even if a few groups (such as the one currently being evaluated) show new filtering fault types, a relatively aggressive optimization scheme can be considered (i.e., using a second preset fault count threshold) in order to bring them back to a stable state as soon as possible and keep them in line with the mainstream.

[0169] Specific examples: Suppose there are 5 optimization requirement groups (A, B, C, D, E). After judgment in S41 and S422, groups B, D, and E are marked as "no optimization required," while groups A and C require further analysis (group A enters S43, and group C may enter other branches of S42). Therefore, the proportion of "optimization requirement groups that do not require optimization" is 3 / 5 = 60%. Assume the preset optimization group proportion threshold is 50%. 60% > 50%, satisfying the condition. Therefore, for group A currently being evaluated, its optimization scheme is determined as follows: all rotating equipment with a failure count greater than the second preset failure count threshold (e.g., 3 times) is considered as collaborative monitoring equipment.

[0170] The number of filtered fault types in the optimization demand group is obtained, and combined with the proportion of rotating equipment that has had filtered fault types in the history of the optimization demand group, the optimization demand value of the optimization demand group is determined. It is then determined whether the optimization demand value of the optimization demand group is greater than a preset demand threshold. If so, the collaborative monitoring optimization scheme of the optimization demand group is determined to be to treat rotating equipment with a fault count greater than a second preset fault count threshold as collaborative monitoring equipment. If not, the collaborative monitoring optimization scheme of the optimization demand group is determined to be to treat rotating equipment with a fault count greater than a third preset fault count threshold as collaborative monitoring equipment.

[0171] Percentage of rotating equipment that has experienced screening failure type: For the current group, the percentage of all equipment within it that has experienced any screening failure type of the group at least once in the past.

[0172] Optimization Requirement Value: A comprehensive score used to measure the urgency of the group's optimization needs under the current circumstances. Its calculation formula can be (number of filtered fault types) * weight A + (proportion of rotating equipment that has experienced filtered fault types) * weight B.

[0173] Preset demand threshold: A pre-set value used to determine whether the urgency of the optimization demand is high or low.

[0174] Second preset fault count threshold: A smaller threshold (e.g., 3 times) is used to initiate a wider range of collaborative monitoring.

[0175] The third preset fault count threshold: a threshold (e.g., 4 times) between the second preset fault count threshold and the global preset fault count threshold, used to initiate collaborative monitoring within a suitable range. Furthermore, the second preset fault count threshold < the third preset fault count threshold < the preset fault count threshold.

[0176] When the proportion of globally stable groups is low, a more refined quantitative assessment is needed for each group. The optimization requirement value considers both the diversity of the problem (the number of fault types filtered) and the prevalence of the problem (the proportion of devices that have experienced these faults). A higher value indicates a more diverse and prevalent problem, and a more urgent need for optimization; therefore, a stricter second threshold is used to expand monitoring. A lower value indicates that although the problem is newly emerging, its types and scope are limited, and a slightly more lenient third threshold can be used to moderately strengthen monitoring, reflecting the concept of refined management.

[0177] Specific examples: Assume that the number of screened fault types in group A is 3 (after adding "mechanical seal leakage"). Group A has a total of 15 devices, of which 9 devices have historically experienced "bearing wear," "impeller corrosion," or "mechanical seal leakage." Therefore, the proportion of rotating devices that have experienced screened fault types is 9 / 15 = 60%. Assume the optimization demand value is calculated as (number of screened fault types * 10) + (proportion * 100) = (3 * 10) + (60% * 100) = 30 + 60 = 90. Assume the preset demand threshold is 80. If 90 > 80, the optimization demand is urgent, and the second preset fault occurrence threshold (e.g., 3 times) is used. If the calculated value is 70, which is not greater than 80, the third preset fault occurrence threshold (e.g., 4 times) is used.

[0178] It should be noted that the second preset fault count threshold is less than the third preset fault count threshold, and the third preset fault count threshold is less than the preset fault count threshold.

[0179] Significance and value of this technical solution A complete closed-loop iterative optimization system has been constructed: This solution is the "strategy readjustment" stage following "strategy formulation," "effect evaluation," and "resource enhancement." It enables the entire intelligent operation and maintenance system to form a complete closed loop that can self-feedback and self-optimize based on execution results, achieving continuous iterative evolution.

[0180] By introducing multi-level thresholds (second and third thresholds) and comprehensive scoring (optimization requirement value), this solution can distinguish the risk status of different groups at different stages in an extremely fine manner, and match response strategies at multiple levels, from "no optimization required" to "strict optimization", thus achieving the ultimate refinement of risk management granularity.

[0181] The system can decide whether to expand or maintain the current collaborative monitoring resource investment. For groups that are improving (such as group C), additional investment can be paused; for groups that are deteriorating (such as group A), investment can be increased. This ensures that limited computing resources are always directed to the areas with the highest risk and the greatest need.

[0182] Example 2 In a second aspect, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the aforementioned fault diagnosis and analysis method for a rotating device based on cloud-edge collaboration when running the computer program.

[0183] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0184] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0185] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A fault diagnosis and analysis method for rotating equipment based on cloud-edge collaboration, characterized in that, Specifically, it includes: Based on the type of rotating equipment, the rotating equipment is divided into different groups. Based on the rotating equipment data and fault diagnosis data of the rotating equipment in the group, the cloud-edge collaborative control method of the group is determined. Based on the cloud-edge collaborative control method, the deviation of the fault diagnosis analysis results of the rotating equipment in the group is determined. Based on the deviation and the degree of matching between the deviation and the fault diagnosis data of the rotating equipment in the group, the optimization requirement group in the group is determined. Based on the data of the optimization demand groups, and considering the degree of overlap of fault types in the fault diagnosis analysis results between the optimization demand groups where there is a deviation, a method for identifying and processing collaborative monitoring devices in the rotating equipment is determined. The collaborative monitoring devices are identified and processed using the identification and processing method. Based on the update results of collaborative monitoring devices in different optimization demand groups, and considering the update results of the degree of overlap of fault types in the fault diagnosis analysis results between the optimization demand groups and other optimization groups where there is a deviation, a collaborative monitoring optimization scheme for the optimization demand groups is determined.

2. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, Rotating equipment is divided into different groups, specifically including: Rotary equipment of the same type should be grouped together.

3. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The data on rotating devices in the group includes the number of rotating devices in the group.

4. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The fault diagnosis data of the rotating equipment includes the number of times the rotating equipment was diagnosed under different fault types.

5. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The method for determining the cloud-edge collaborative control method for the group is as follows: Based on the rotating equipment data in the group, determine the number of rotating equipment in the group; Using the fault diagnosis data of the rotating equipment, determine the number of times the rotating equipment in the group was identified under different fault types in history; The cloud-edge collaborative control method for the group is determined based on the number of identifications and the number of rotating devices in the group.

6. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 5, characterized in that, If the number of rotating devices in the group is greater than a preset threshold for the number of rotating devices, then the cloud-edge collaborative control method for the group is determined to be that, for all rotating devices in the group, if no fault is identified within the most recent preset time period, fault diagnosis and processing are performed simultaneously using the cloud platform and the edge device.

7. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The deviation of the fault diagnosis analysis results of the rotating equipment in the group is determined based on the degree of consistency between the fault diagnosis analysis results of the rotating equipment in the group and the edge nodes of the rotating equipment on the cloud platform.

8. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The method for determining the optimization requirement group in the aforementioned group is as follows: S21 Based on the aforementioned deviation, determine the type of fault where there is a deviation in the fault diagnosis analysis results between the cloud platform and the edge node of the rotating equipment, and use it as the type of fault to identify the deviation. S22 will select the identification deviation fault type as the fault type in which the number of times the fault diagnosis analysis results between the cloud platform and the edge node of the rotating equipment deviates from the identified deviation fault type is greater than the preset deviation number threshold. S23 Based on the identified deviation fault type, filter the degree of overlap between the fault type and the risk fault type in the group, and determine whether the group belongs to the optimization requirement group.

9. The fault diagnosis and analysis of rotating equipment based on cloud-edge collaboration as described in claim 1, characterized in that, The method for determining the collaborative monitoring optimization scheme for the optimization demand group is as follows: S41 determines the number of collaborative monitoring devices in the optimization demand groups based on the update results of the collaborative monitoring devices in different optimization demand groups; S42 determines the updated data of the associated groups for the screened fault types of the optimization requirement group based on the updated results of the degree of overlap of fault types in the fault diagnosis analysis results between the optimization requirement group and other optimization groups where there is a deviation; S43 determines the collaborative monitoring optimization scheme for the optimization demand group based on the number of collaborative monitoring devices in the optimization demand group and the updated data of the associated groups of the filtered fault types of the optimization demand group.

10. A computer system, comprising: A memory and processor connected by communication, and a computer program stored in the memory and capable of running on the processor, characterized in that, when the processor runs the computer program, it executes a fault diagnosis and analysis method for a rotating device based on cloud-edge collaboration as described in any one of claims 1-9.

Images