Method, system, device and medium for establishing equipment fault identification model

Abstract

The application discloses a kind of equipment failure identification model establishing method, system, equipment and medium, the establishing method includes: obtaining equipment failure identification model unit;The fault identification model unit is characterized in that several units are divided in the process of establishing equipment failure identification model;According to the equipment failure identification model unit, algorithm library is constructed;Based on the algorithm library, model component library is constructed;From model component library, obtain the model component matched with equipment failure identification model, and establish equipment failure identification model.The application realizes the automation light-weight modeling of equipment failure identification, and greatly reduces the modeling time and manpower cost in modeling process of equipment failure identification.

Description

Technical Field

[0001] This invention relates to the field of industrial intelligence, and in particular to a method, system, device, and medium for establishing an equipment fault identification model. Background Technology

[0002] In the process of data modeling and prediction in industrial data analysis, the following pain points exist in the field of intelligent operation and maintenance regarding fault identification technology under the current industrial internet context: First, traditional fault identification methods often rely on personnel experience and past project experience, resulting in slow development speed, low efficiency, and huge risk of trial and error for developers in new scenarios; Second, fault identification-related experience and knowledge are difficult to precipitate in a tangible form, and related technologies and data models lack room for continuous improvement and iterative derivation; Third, the amount of fault data that can be collected from equipment in actual industrial sites is relatively small, and it is usually difficult to obtain enough data for training data models.

[0003] With the continuous advancement of modern industry, manufacturing systems are becoming increasingly complex and diversified to meet the diverse production needs of the manufacturing industry. The reliability requirements, diagnostic needs, and application scope of various equipment are also rapidly expanding. In the field of industrial equipment fault identification, fault location and identification can typically be achieved through information collected by various sensors and control systems, relying on expert knowledge and field experience. However, this information is difficult to solidify into physical data, and its strong reliance on manual intervention results in low reliability. Therefore, using data-driven models to replace manual fault identification has become an inevitable trend for the future development of this industry.

[0004] However, using data-driven models to replace manual fault identification means that a large number of fault identification models need to be built for various working conditions, scenarios and objects. If traditional methods are used, a lot of manpower, material resources, data assets, computing power and development experience will be required. At the same time, the development of each new scenario will face huge risks of repetitive work and trial and error. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to overcome the shortcomings of the existing technology that requires a lot of manpower and material resources, and to provide a method, system, equipment and medium for establishing a device fault identification model.

[0006] The present invention solves the above-mentioned technical problems through the following technical solution:

[0007] This invention provides a method for establishing a device fault identification model, the method comprising:

[0008] Obtain equipment fault identification model units; the fault identification model units represent several units divided during the process of establishing the equipment fault identification model;

[0009] An algorithm library is constructed based on the aforementioned equipment fault identification model unit;

[0010] Based on the algorithm library, a model component library will be constructed;

[0011] Obtain model components that match the equipment fault identification model from the model component library, and build the equipment fault identification model.

[0012] Preferably, the step of constructing the algorithm library based on the equipment fault identification model unit includes:

[0013] Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

[0014] Preferably, the step of constructing a model component library based on the algorithm library includes:

[0015] Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

[0016] Preferably, the step of obtaining a model component matching the equipment fault identification model from the model component library includes:

[0017] Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the device fault identification model, thereby obtaining model components that match the device fault identification model.

[0018] The present invention also provides a system for establishing a device fault identification model, the system comprising:

[0019] The first acquisition module is used to acquire equipment fault identification model units; the fault identification model units represent several units divided in the process of establishing the equipment fault identification model.

[0020] The first construction module is used to construct an algorithm library based on the equipment fault identification model unit;

[0021] The second building module is used to build a model component library based on the algorithm library;

[0022] The second acquisition module is used to acquire model components that match the equipment fault identification model from the model component library and to establish the equipment fault identification model.

[0023] Preferably, the first building module is specifically used for:

[0024] Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

[0025] Preferably, the second building module is specifically used for:

[0026] Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

[0027] Preferably, the second acquisition module is specifically used for:

[0028] Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the device fault identification model, thereby obtaining model components that match the device fault identification model.

[0029] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein the processor executes the computer program to implement the method for establishing a device fault identification model as described above.

[0030] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the aforementioned method for establishing a device fault identification model.

[0031] Based on common knowledge in the field, the above-mentioned preferred conditions can be combined arbitrarily to obtain various preferred embodiments of the present invention.

[0032] The positive and progressive effects of this invention are as follows:

[0033] This solution constructs an algorithm library based on the equipment fault identification model unit, then constructs a model component library based on the algorithm library, and finally obtains model components that match the equipment fault identification model from the model component library and establishes the equipment fault identification model. This achieves automated and lightweight modeling for equipment fault identification, significantly reducing the modeling time and manpower costs in the modeling process. Attached Figure Description

[0034] Figure 1 This is a flowchart of the method for establishing a device fault identification model according to Embodiment 1 of the present invention.

[0035] Figure 2 This is a schematic diagram illustrating the relationship between the various libraries in Embodiment 1 of the present invention.

[0036] Figure 3 This is a graphical schematic diagram of the graphical modeling interface in Embodiment 1 of the present invention.

[0037] Figure 4 This is a schematic diagram of the modeling process in Embodiment 1 of the present invention.

[0038] Figure 5 This is a schematic diagram of constructing a general algorithm library in Embodiment 1 of the present invention.

[0039] Figure 6 This is a schematic diagram of the method library displayed on the modeling management tool in Embodiment 1 of the present invention.

[0040] Figure 7 This is a schematic diagram of the component library displayed on the modeling management tool in Embodiment 1 of the present invention.

[0041] Figure 8 This is a schematic diagram of the graphical modeling interface in Embodiment 1 of the present invention.

[0042] Figure 9 This is a first schematic diagram of the interface of the modeling recommendation engine in Embodiment 1 of the present invention.

[0043] Figure 10 This is a second schematic diagram of the interface of the modeling recommendation engine in Embodiment 1 of the present invention.

[0044] Figure 11 This is a schematic diagram of the online debugging interface in an embodiment of the present invention.

[0045] Figure 12 This is a schematic diagram of the interface for constructing the mechanism library in Embodiment 1 of the present invention.

[0046] Figure 13 This is a schematic diagram of the modules of the system for establishing the equipment fault identification model in Embodiment 2 of the present invention.

[0047] Figure 14 This is a schematic diagram of the electronic device according to Embodiment 3 of the present invention. Detailed Implementation

[0048] The present invention will be further illustrated by way of embodiments below, but the present invention is not limited to the scope of the embodiments described herein.

[0049] Example 1

[0050] like Figure 1 As shown in the figure, this embodiment discloses a method for establishing a device fault identification model, the method comprising:

[0051] Step S101: Obtain the equipment fault identification model unit; the fault identification model unit represents several units divided during the process of establishing the equipment fault identification model;

[0052] Specifically, the process of building an equipment fault identification model can be broken down into units such as preprocessing, feature extraction, regression, clustering, and classification. Simultaneously, the algorithms corresponding to all units are standardized using standard rules. For example, the role and input / output information of each unit are clearly defined, the required adjustment parameters are determined, and the functions of the algorithms under each unit are standardized. This provides a streamlined modeling method for fault identification data models. For instance, based on the characteristics of the fault identification model, the modeling process is divided into n units, and the order of their use is determined. Taking power plant equipment fault identification as an example, the modeling process is divided into six units: data preprocessing, feature engineering, classification / clustering / regression model, and visualization.

[0053] This solution addresses the challenges of diverse fault identification model scenarios, significant environmental variations, complex and variable modeling processes, and the lack of unified, clear, and standardized modeling specifications. This results in poor reusability of fault identification models and related technologies built with substantial human and material resources. To address these issues, this solution proposes a modeling approach tailored to the specific characteristics of data models in this industry. The modeling process is broken down into preprocessing, feature extraction, regression, clustering, and classification units, with clear definitions of the role and input / output information for each unit. This provides a streamlined modeling method for fault identification data models.

[0054] Step S102: Construct an algorithm library based on the equipment fault identification model unit;

[0055] Step S103: Based on the algorithm library, construct a model component library;

[0056] Step S104: Obtain the model components that match the equipment fault identification model from the model component library, and establish the equipment fault identification model.

[0057] This solution constructs an algorithm library based on the equipment fault identification model unit, then constructs a model component library based on the algorithm library, and finally obtains model components that match the equipment fault identification model from the model component library and establishes the equipment fault identification model. This achieves automated and lightweight modeling for equipment fault identification, significantly reducing the modeling time and manpower costs in the modeling process.

[0058] In one implementable manner, step S102 includes:

[0059] Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

[0060] Specifically, based on the equipment fault identification model units and existing fault identification models, general algorithm components for fault identification scenarios are managed and developed, and a standardized general algorithm library is constructed. Furthermore, refined classification and updates can be performed through the tags of the equipment fault identification model units. For example, based on experience with historical fault identification models for power plant equipment, a general algorithm library related to data preprocessing, feature extraction, and machine learning (classification / regression / clustering) is listed and saved in Python file format.

[0061] This solution provides a unified method for storing, calling, and connecting each unit of the fault identification data model. It encapsulates each unit in the fault identification model into callable model components and model component libraries in a standardized manner, thereby enabling cross-scenario and cross-task code reuse. By accumulating relevant code for each unit in advance, relevant component code can be directly reused when there is a new modeling task, improving modeling efficiency and reducing trial and error risks.

[0062] In one implementable manner, step S103 includes:

[0063] Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

[0064] Specifically, based on existing fault identification models composed of code, the parameters for calling general algorithms are fixed as default values ​​for components. Here, the existing fault identification model refers to executable code developed for fault identification tasks using Python code; such code models are difficult to rewrite and reuse. Taking a general algorithm, `association`, as an example, its general algorithm calling method is `association(parameter A, parameter B, parameter C)`. Then, the component used in a certain scenario can be defined as follows:

[0065] def tubine_association(a,b,c)

[0066] association(parameter A = a, parameter B = b, parameter C = c)

[0067] This allows the parameters for general algorithm calls in specific scenarios to be stored in the component in the format of a Python file, which facilitates subsequent modeling, use, and iterative optimization.

[0068] Meanwhile, users can integrate various components into a component module library in advance according to their needs. Each component and component module can be queried and edited in the management subsystem and can be freely called in the graphical interface by dragging and dropping.

[0069] This solution provides a unified method for storing, calling, and connecting each unit of the fault identification data model. It encapsulates each unit in the fault identification model into callable model components and model component libraries in a standardized manner, thereby enabling cross-scenario and cross-task code reuse. By accumulating relevant code for each unit in advance, relevant component code can be directly reused when there is a new modeling task, improving modeling efficiency and reducing trial and error risks.

[0070] In one implementable manner, step S104 includes:

[0071] Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the device fault identification model, thereby obtaining model components that match the device fault identification model.

[0072] Specifically, by combining expert experience with historical modeling records, the system automatically provides component recommendations to users during the modeling process. Based on historical modeling records, the recommendation engine automatically recommends components based on their tags when calling another component after the previous one has been used. The engine displays available component or module recommendations, which users can then access by clicking on a specific component or module. The main principles of the component engine recommendation are as follows:

[0073] First, the engine recommends components by automatically matching the relationships between them from the existing mechanistic model library;

[0074] Second, based on the output parameters of the current component, the feasibility recommendations are made by matching the input parameters of each component in the component library with the output parameters of the current component.

[0075] Third, benign tag components should be given priority; components and component modules should not be allowed to be called or used when their output parameters do not match their input parameters.

[0076] This solution addresses the component selection issue in lightweight modeling by constructing a component recommendation engine. By combining expert experience with historical modeling records, it automatically provides component recommendations to users during the modeling process, achieving automated and lightweight modeling of fault identification models. This significantly reduces modeling time and labor costs. Furthermore, this solution embeds the personnel and project experience of fault identification models into the model components, improving development efficiency through component reuse and reducing the risk of trial and error for developers by directly calling existing components.

[0077] This solution connects and facilitates the interoperability of method libraries, component libraries, component module libraries, and mechanism libraries through a component management subsystem. Underlying algorithms are encapsulated into fixed, general-purpose algorithm modules. When building a diagnostic model for a specific scenario, these pre-encapsulated modules are called to perform preprocessing, feature extraction, regression, clustering, classification, and other unit functions. The parameters used by each algorithm module are stored in the component for direct use and iterative derivation in other scenarios. The final diagnostic model assembled from these components is stored in the mechanism library for easy knowledge reuse in similar scenarios. This solution manages the underlying algorithms in the model component management and graphical configuration tools by managing the method library, component library, component module library, and mechanism library. The relationships between methods, components, component modules, and mechanism models are as follows: Figure 2 As shown, components are developed using methods in the method library. Combinations of several different components form component modules, and the construction of components or component modules forms a mechanism model.

[0078] This solution, based on the aforementioned model component library, recommends model components that match the equipment fault identification model through a pre-built recommendation engine. This process of obtaining model components that match the equipment fault identification model is also the construction process of the mechanism library. The mechanism library mainly stores the component flow composed of components or component modules using graphical modeling tools, as well as the final generated model Python files. The usage flow of the model components will provide a reference for the recommendation engine. Simultaneously, the modeling experience of the final fault identification model can also be accumulated in the mechanism library for subsequent iterations and reuse. Specific tasks are as follows:

[0079] First, the mechanism library includes functions for adding, deleting, editing, and querying mechanism models;

[0080] Second, it supports the classification and management of mechanism models in the mechanism library, and allows for the creation and management of custom multi-level mechanism classifications;

[0081] Third, when adding a new mechanism model to the mechanism library, you need to add information such as mechanism name, mechanism type, applicable objects, performance evaluation criteria, and remarks before entering the process-oriented modeling tool to create the mechanism model;

[0082] Fourth, when a new mechanism model in the mechanism library contains a custom component from the component library, the user should specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component.

[0083] Fifth, the mechanism library supports the management of labels for mechanisms that have been calculated and evaluated for performance, and assigns these labels to the components used, such as the mechanism accuracy label, to provide historical experience for subsequent use.

[0084] This solution addresses the challenge of accumulating and iteratively developing fault identification models for equipment. The invention divides the modeling process into three stages: a general algorithm, model components, and fault identification mechanisms. First, the underlying algorithms are encapsulated into fixed, general algorithm modules, and their calling methods are standardized within a component library, facilitating the reuse of the same algorithms in different scenarios. When building a diagnostic model for a specific scenario, the pre-encapsulated algorithm modules are called to perform functions such as preprocessing, feature extraction, regression, clustering, and classification. The parameters used by each algorithm module are stored in the components for direct use and iterative development in other scenarios. This allows for the pre-reservation of each component of the fault identification model and, based on the results of new scenarios, the parameters and labels of the components are readjusted, avoiding redundant development while simultaneously expanding and iteratively optimizing each component.

[0085] In this embodiment, a device fault identification model can be established graphically. Specifically, during operation, the user can establish the device fault identification model in the modeling interface. This interface allows users to freely select and drag component units from the constructed component library. Furthermore, the interface displays the sequential relationships and input-output relationships between the various model components, determining the correspondence between the output parameters of the previous model component and the input parameters of the next model component. Simultaneously, this interface also has the following basic functions:

[0086] First, it enables quick access to component modules in the component and model component libraries, which can be accessed via drag and drop.

[0087] Second, to achieve a visual display of each component module in the model component library;

[0088] Third, enable rapid connections between components or between component modules;

[0089] Fourth, enable rapid creation of parallel components;

[0090] Fifth, achieve rapid alignment and screen adaptation of the entire model;

[0091] Sixth, achieve real-time association and management with the mechanism model library and component module library;

[0092] Seventh, when using a custom editing component from the component library, the user should be able to specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component.

[0093] Taking a steam turbine fault identification scenario as an example, its graphical modeling interface is as follows: Figure 3 As shown.

[0094] In this solution, to achieve online compilation and debugging functionality, a compilation and debugging environment needs to be set up based on the components used. Python files for the models are generated according to the model connection order in the graphical modeling interface, replacing traditional code-level model building. For example, the code generated by connecting components model1 and model2 is shown below:

[0095] TestInput1 = Testdf

[0096] #TestInput1 is the input data for component Model1;

[0097] TestResult1=Model1(TestInput1,md1)

[0098] #Model1 is the function that calls component 1;

[0099] #TestResult1 is the output result of component Model1;

[0100] TestInput2 = TestResult1

[0101] #TestInput2 is the input data for component Model2, and also the output of component 1;

[0102] TestResult2=Model2(TestInput2,md2)

[0103] #Model2.test is the function that calls component Model2;

[0104] #TestResult2 is the output result of component Model2;

[0105] This solution uses a visual configuration approach to quickly build existing algorithm models, monitor the simulation process, and display the results. It replaces pure code-based models with visual components, allowing users to have comprehensive control over the modeling process and simplifying modeling and debugging. Simultaneously, users can control the workflow and check and save intermediate results to ensure rapid feedback.

[0106] To better understand this invention, the following example illustrates the construction of a fault identification model for steam turbine equipment manufactured by a steam turbine manufacturer. The fault identification of this steam turbine equipment primarily involves predicting and identifying pressure anomalies in the regulating stage. The specific implementation steps are as follows:

[0107] The first step is to define the fault identification model units and their order of use. Based on the characteristics of the fault identification model, the modeling process is divided into six units: data preprocessing, feature engineering, classification / clustering / regression model, and visualization. The workflow is as follows: Figure 4 As shown.

[0108] The second step is to construct a general algorithm. For example... Figure 5 As shown, based on the number of units divided in the first step and the existing fault identification model, general algorithm components for fault identification scenarios are managed and developed, a standardized general algorithm library is constructed, and fine-grained classification and updates are performed through unit tags. The case study, based on experience with historical fault identification models for power plant equipment, lists examples of general algorithm libraries related to data preprocessing, feature extraction, and machine learning (classification / regression / clustering), and saves the records in Python file format.

[0109] The method libraries displayed on the modeling management tool are as follows: Figure 6 As shown.

[0110] The third step is to build a model component library. Based on the existing fault identification model, the parameters for calling general algorithms are fixed as default values ​​for the components. In the process of modeling the pressure regression task of the turbine regulating stage, the random forest regression algorithm component is used as the machine learning prediction unit, and its component calling method at the code level is as follows:

[0111] model_abs_url,model_svm_reg,reg_result,y_test,y_predict=

[0112] random_forest_reg.train(data_train_test)

[0113] The function `random_forest_reg` is a general algorithm for random forest regression from the algorithm library. The parameters used when calling it are re-encapsulated into the turbine regulating stage pressure regression_random forest component. The encapsulation process is as follows:

[0114] def svr_pressure(data,

[0115] feature_tags,

[0116] target_tag,

[0117] test_size = 0.25,

[0118] scaler=None,

[0119] kernel="rbf",

[0120] c = 1,

[0121] gamma = "auto",

[0122] tol = 0.01,

[0123] max_iter = 5000,

[0124] cv = 3,

[0125] model_url = '.\\my_svr_model.pkl'):

[0126] # Model training

[0127] model_abs_url, model_svm_reg, reg_result, y_test, y_predict =

[0128] support_vector_re.train(data_aligned = data,

[0129] feature_tags = feature_tags,

[0130] target_tag = target_tag,

[0131] test_size = test_size,

[0132] scaler = scaler,

[0133] kernel = kernel,

[0134] c = c,

[0135] gamma = gamma,

[0136] tol = tol,

[0137] max_iter = max_iter,

[0138] cv = cv,

[0139] model_url = model_url)

[0140] return model_abs_url, model_svm_reg, reg_result, y_test, y_predict

[0141] Among which, the key parameter feature_tags,

[0142] target_tag,

[0143] test_size = 0.25,

[0144] scaler=None,

[0145] kernel="rbf",

[0146] c = 1,

[0147] gamma = "auto",

[0148] tol = 0.01,

[0149] max_iter = 5000,

[0150] cv=3,

[0151] model_url='.\\my_svr_model.pkl'

[0152] The parameters are fully recorded in the component definition and do not need to be set again when using the component. If the modeling results are not ideal, professional users can also adjust the parameters to extend and optimize the original component algorithm.

[0153] The fourth step is to build a component management subsystem. The management system lists all the method libraries and component libraries required for fault identification modeling. Users can also pre-integrate these components into a component module library based on their needs. Each component and component module can be accessed at any time through the graphical modeling interface in the fifth step, displaying the results as shown below. Figure 7 , Figure 8 As shown.

[0154] Step 5: Construct a graphical modeling interface. This involves creating an interface where users can freely select and drag components from the library built in Step 3 to model the model units. The interface should define the order and input / output relationships between the model components, establish the correspondence between the output parameters of the previous model component and the input parameters of the next model component, and present the modeling process within the interface as follows: Figure 8 As shown.

[0155] Step 6: Build the modeling recommendation engine. Based on the model component library and historical modeling records, build the modeling recommendation engine. Its user interface is as follows: Figure 9 , Figure 10 As shown.

[0156] Step 7: Build the online debugging module. After connecting the component units using a graphical modeling tool via drag and drop, you can run and debug directly on the canvas. Simultaneously, you can check the component's output, input, and error information, and automatically generate and display the corresponding Python code. The results are as follows: Figure 11 As shown.

[0157] Step 8: Mechanism library construction. (For example...) Figure 12 As shown, the newly constructed model is saved and automatically stored in the mechanism library.

[0158] Example 2

[0159] like Figure 13 As shown in the figure, this embodiment discloses a system for establishing a device fault identification model, the system comprising:

[0160] The first acquisition module 1 is used to acquire equipment fault identification model units; the fault identification model units represent several units divided in the process of establishing the equipment fault identification model.

[0161] Specifically, the process of building an equipment fault identification model can be broken down into units such as preprocessing, feature extraction, regression, clustering, and classification. Simultaneously, the algorithms corresponding to all units are standardized using standard rules. For example, the role and input / output information of each unit are clearly defined, the required adjustment parameters are determined, and the functions of the algorithms under each unit are standardized. This provides a streamlined modeling method for fault identification data models. For instance, based on the characteristics of the fault identification model, the modeling process is divided into n units, and the order of their use is determined. Taking power plant equipment fault identification as an example, the modeling process is divided into six units: data preprocessing, feature engineering, classification / clustering / regression model, and visualization.

[0162] This solution addresses the challenges of diverse fault identification model scenarios, significant environmental variations, complex and variable modeling processes, and the lack of unified, clear, and standardized modeling specifications. This results in poor reusability of fault identification models and related technologies built with substantial human and material resources. To address these issues, this solution proposes a modeling approach tailored to the specific characteristics of data models in this industry. The modeling process is broken down into preprocessing, feature extraction, regression, clustering, and classification units, with clear definitions of the role and input / output information for each unit. This provides a streamlined modeling method for fault identification data models.

[0163] The first construction module 2 is used to construct an algorithm library based on the equipment fault identification model unit;

[0164] The second construction module 3 is used to construct a model component library based on the algorithm library;

[0165] The second acquisition module 4 is used to acquire model components that match the equipment fault identification model from the model component library and to establish the equipment fault identification model.

[0166] This solution constructs an algorithm library based on the equipment fault identification model unit, then constructs a model component library based on the algorithm library, and finally obtains model components that match the equipment fault identification model from the model component library and establishes the equipment fault identification model. This achieves automated and lightweight modeling for equipment fault identification, significantly reducing the modeling time and manpower costs in the modeling process.

[0167] In one implementable manner, the first building module is specifically used for:

[0168] Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

[0169] Specifically, based on the equipment fault identification model units and existing fault identification models, general algorithm components for fault identification scenarios are managed and developed, and a standardized general algorithm library is constructed. Furthermore, refined classification and updates can be performed through the tags of the equipment fault identification model units. For example, based on experience with historical fault identification models for power plant equipment, a general algorithm library related to data preprocessing, feature extraction, and machine learning (classification / regression / clustering) is listed and saved in Python file format.

[0170] This solution provides a unified method for storing, calling, and connecting each unit of the fault identification data model. It encapsulates each unit in the fault identification model into callable model components and model component libraries in a standardized manner, thereby enabling cross-scenario and cross-task code reuse. By accumulating relevant code for each unit in advance, relevant component code can be directly reused when there is a new modeling task, improving modeling efficiency and reducing trial and error risks.

[0171] In one implementable manner, the second building module is specifically used for:

[0172] Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

[0173] Specifically, based on existing fault identification models composed of code, the parameters for calling general algorithms are fixed as default values ​​for components. Here, the existing fault identification model refers to executable code developed for fault identification tasks using Python code; such code models are difficult to rewrite and reuse. Taking a general algorithm, `association`, as an example, its general algorithm calling method is `association(parameter A, parameter B, parameter C)`. Then, the component used in a certain scenario can be defined as follows:

[0174] def tubine_association(a,b,c)

[0175] association(parameter A = a, parameter B = b, parameter C = c)

[0176] This allows the parameters for general algorithm calls in specific scenarios to be stored in the component in the format of a Python file, which facilitates subsequent modeling, use, and iterative optimization.

[0177] Meanwhile, users can integrate various components into a component module library in advance according to their needs. Each component and component module can be queried and edited in the management subsystem and can be freely called in the graphical interface by dragging and dropping.

[0178] This solution provides a unified method for storing, calling, and connecting each unit of the fault identification data model. It encapsulates each unit in the fault identification model into callable model components and model component libraries in a standardized manner, thereby enabling cross-scenario and cross-task code reuse. By accumulating relevant code for each unit in advance, relevant component code can be directly reused when there is a new modeling task, improving modeling efficiency and reducing trial and error risks.

[0179] In one implementable manner, the second acquisition module is specifically used for:

[0180] Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the device fault identification model, thereby obtaining model components that match the device fault identification model.

[0181] Specifically, by combining expert experience with historical modeling records, the system automatically provides component recommendations to users during the modeling process. Based on historical modeling records, the recommendation engine automatically recommends components based on their tags when calling another component after the previous one has been used. The engine displays available component or module recommendations, which users can then access by clicking on a specific component or module. The main principles of the component engine recommendation are as follows:

[0182] First, the engine recommends components by automatically matching the relationships between them from the existing mechanistic model library;

[0183] Second, based on the output parameters of the current component, the feasibility recommendations are made by matching the input parameters of each component in the component library with the output parameters of the current component.

[0184] Third, benign tag components should be given priority; components and component modules should not be allowed to be called or used when their output parameters do not match their input parameters.

[0185] This solution addresses the component selection issue in lightweight modeling by constructing a component recommendation engine. By combining expert experience with historical modeling records, it automatically provides component recommendations to users during the modeling process, achieving automated and lightweight modeling of fault identification models. This significantly reduces modeling time and labor costs. Furthermore, this solution embeds the personnel and project experience of fault identification models into the model components, improving development efficiency through component reuse and reducing the risk of trial and error for developers by directly calling existing components.

[0186] This solution connects and facilitates the interoperability of method libraries, component libraries, component module libraries, and mechanism libraries through a component management subsystem. Underlying algorithms are encapsulated into fixed, general-purpose algorithm modules. When building a diagnostic model for a specific scenario, these pre-encapsulated modules are called to perform preprocessing, feature extraction, regression, clustering, classification, and other unit functions. The parameters used by each algorithm module are stored in the component for direct use and iterative derivation in other scenarios. The final diagnostic model assembled from these components is stored in the mechanism library for easy knowledge reuse in similar scenarios. This solution manages the underlying algorithms in the model component management and graphical configuration tools by managing the method library, component library, component module library, and mechanism library. The relationships between methods, components, component modules, and mechanism models are as follows: Figure 2 As shown, components are developed using methods in the method library. Combinations of several different components form component modules, and the construction of components or component modules forms a mechanism model.

[0187] This solution, based on the aforementioned model component library, recommends model components that match the equipment fault identification model through a pre-built recommendation engine. This process of obtaining model components that match the equipment fault identification model is also the construction process of the mechanism library. The mechanism library mainly stores the component flow composed of components or component modules using graphical modeling tools, as well as the final generated model Python files. The usage flow of the model components will provide a reference for the recommendation engine. Simultaneously, the modeling experience of the final fault identification model can also be accumulated in the mechanism library for subsequent iterations and reuse. Specific tasks are as follows:

[0188] First, the mechanism library includes functions for adding, deleting, editing, and querying mechanism models;

[0189] Second, it supports the classification and management of mechanism models in the mechanism library, and allows for the creation and management of custom multi-level mechanism classifications;

[0190] Third, when adding a new mechanism model to the mechanism library, you need to add information such as mechanism name, mechanism type, applicable objects, performance evaluation criteria, and remarks before entering the process-oriented modeling tool to create the mechanism model;

[0191] Fourth, when a new mechanism model in the mechanism library contains a custom component from the component library, the user should specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component.

[0192] Fifth, the mechanism library supports the management of labels for mechanisms that have been calculated and evaluated for performance, and assigns these labels to the components used, such as the mechanism accuracy label, to provide historical experience for subsequent use.

[0193] This solution addresses the challenge of accumulating and iteratively developing fault identification models for equipment. The invention divides the modeling process into three stages: a general algorithm, model components, and fault identification mechanisms. First, the underlying algorithms are encapsulated into fixed, general algorithm modules, and their calling methods are standardized within a component library, facilitating the reuse of the same algorithms in different scenarios. When building a diagnostic model for a specific scenario, the pre-encapsulated algorithm modules are called to perform functions such as preprocessing, feature extraction, regression, clustering, and classification. The parameters used by each algorithm module are stored in the components for direct use and iterative development in other scenarios. This allows for the pre-reservation of each component of the fault identification model and, based on the results of new scenarios, the parameters and labels of the components are readjusted, avoiding redundant development while simultaneously expanding and iteratively optimizing each component.

[0194] In this embodiment, a device fault identification model can be established graphically. Specifically, during operation, the user can establish the device fault identification model in the modeling interface. This interface allows users to freely select and drag component units from the constructed component library. Furthermore, the interface displays the sequential relationships and input-output relationships between the various model components, determining the correspondence between the output parameters of the previous model component and the input parameters of the next model component. Simultaneously, this interface also has the following basic functions:

[0195] First, it enables quick access to component modules in the component and model component libraries, which can be accessed via drag and drop.

[0196] Second, to achieve a visual display of each component module in the model component library;

[0197] Third, enable rapid connections between components or between component modules;

[0198] Fourth, enable rapid creation of parallel components;

[0199] Fifth, achieve rapid alignment and screen adaptation of the entire model;

[0200] Sixth, achieve real-time association and management with the mechanism model library and component module library;

[0201] Seventh, when using a custom editing component from the component library, the user should be able to specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component.

[0202] Taking a steam turbine fault identification scenario as an example, its graphical modeling interface is as follows: Figure 3 As shown.

[0203] In this solution, to achieve online compilation and debugging functionality, a compilation and debugging environment needs to be set up based on the components used. Python files for the models are generated according to the model connection order in the graphical modeling interface, replacing traditional code-level model building. For example, the code generated by connecting components model1 and model2 is shown below:

[0204] TestInput1 = Testdf

[0205] #TestInput1 is the input data for component Model1;

[0206] TestResult1=Model1(TestInput1,md1)

[0207] #Model1 is the function that calls component 1;

[0208] #TestResult1 is the output result of component Model1;

[0209] TestInput2 = TestResult1

[0210] #TestInput2 is the input data for component Model2, and also the output of component 1;

[0211] TestResult2=Model2(TestInput2,md2)

[0212] #Model2.test is the function that calls component Model2;

[0213] #TestResult2 is the output result of component Model2;

[0214] This solution uses a visual configuration approach to quickly build existing algorithm models, monitor the simulation process, and display the results. It replaces pure code-based models with visual components, allowing users to have comprehensive control over the modeling process and simplifying modeling and debugging. Simultaneously, users can control the workflow and check and save intermediate results to ensure rapid feedback.

[0215] Example 3

[0216] Figure 14 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of the present invention. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method for establishing the device fault identification model provided in Embodiment 1. Figure 14 The electronic device 40 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0217] like Figure 14 As shown, the electronic device 40 can be manifested as a general-purpose computing device, such as a server device. The components of the electronic device 40 may include, but are not limited to: at least one processor 41, at least one memory 42, and a bus 43 connecting different system components (including memory 42 and processor 41).

[0218] Bus 43 includes a data bus, an address bus, and a control bus.

[0219] The memory 42 may include volatile memory, such as random access memory (RAM) 421 and / or cache memory 422, and may further include read-only memory (ROM) 423.

[0220] The memory 42 may also include a program / utility 425 having a set (at least one) of program modules 424, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0221] The processor 41 executes various functional applications and data processing by running computer programs stored in the memory 42, such as the method for establishing a device fault identification model provided in Embodiment 1 of the present invention.

[0222] Electronic device 40 can also communicate with one or more external devices 44 (e.g., keyboard, pointing device, etc.). This communication can be performed via input / output (I / O) interface 45. Furthermore, the model-generated device 40 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public network, such as the Internet) via network adapter 46. As shown, network adapter 46 communicates with other modules of the model-generated device 40 via bus 43. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the model-generated device 40, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems.

[0223] It should be noted that although several units / modules or sub-units / modules of the electronic device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0224] Example 4

[0225] This embodiment provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method for establishing a device fault identification model provided in Embodiment 1.

[0226] The readable storage medium may be more specifically adopted, including but not limited to: portable disk, hard disk, random access memory, read-only memory, erasable programmable read-only memory, optical storage device, magnetic storage device, or any suitable combination thereof.

[0227] In a possible implementation, the present invention can also be implemented as a program product comprising program code, which, when the program product is run on a terminal device, is used to cause the terminal device to execute the method for establishing the device fault identification model provided in Embodiment 1.

[0228] The program code for executing the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0229] While specific embodiments of the present invention have been described above, those skilled in the art should understand that these are merely illustrative examples, and the scope of protection of the present invention is defined by the appended claims. Those skilled in the art can make various changes or modifications to these embodiments without departing from the principles and essence of the present invention, but all such changes and modifications fall within the scope of protection of the present invention.

Claims

1. A method for establishing a device fault identification model, characterized in that, The establishment method includes: Obtain equipment fault identification model units; the fault identification model units represent several units divided during the process of establishing the equipment fault identification model; An algorithm library is constructed based on the aforementioned equipment fault identification model unit; Based on the algorithm library, a model component library will be constructed; Obtain model components that match the equipment fault identification model from the model component library, and build the equipment fault identification model; The step of obtaining model components that match the equipment fault identification model from the model component library includes: Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the equipment fault identification model, thereby obtaining model components that match the equipment fault identification model. The process of building the mechanism library involves recommending model components that match the device fault identification model using a pre-built recommendation engine, based on the model component library. The tasks of the mechanism library are as follows: First, the mechanism library includes functions for adding, deleting, editing, and querying mechanism models; Second, it supports the classification and management of the mechanism models in the mechanism library and allows for the creation and management of custom multi-level mechanism classifications; Third, when adding a new mechanism model to the mechanism library, the mechanism name, mechanism type, applicable objects, performance evaluation criteria, and remarks information must be added before the model is created using the workflow modeling tool. Fourth, when a new mechanism model in the mechanism library contains a custom component from the component library, the user should specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component. Fifth, the mechanism library supports tag management for mechanisms that have been calculated and evaluated for performance, and assigns the tags to the components that use them.

2. The method for establishing a device fault identification model as described in claim 1, characterized in that, The step of constructing the algorithm library based on the equipment fault identification model unit includes: Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

3. The method for establishing a device fault identification model as described in claim 1, characterized in that, The steps for constructing a model component library based on the algorithm library include: Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

4. A system for establishing a device fault identification model, characterized in that, The system establishment includes: The first acquisition module is used to acquire equipment fault identification model units; the fault identification model units represent several units divided in the process of establishing the equipment fault identification model. The first construction module is used to construct an algorithm library based on the equipment fault identification model unit; The second building module is used to build a model component library based on the algorithm library; The second acquisition module is used to acquire model components that match the equipment fault identification model from the model component library and to build the equipment fault identification model. The second acquisition module is specifically used for: Based on the aforementioned model component library, a pre-built recommendation engine is used to recommend model components that match the equipment fault identification model, thereby obtaining model components that match the equipment fault identification model. The process of building the mechanism library involves recommending model components that match the device fault identification model using a pre-built recommendation engine, based on the model component library. The tasks of the mechanism library are as follows: First, the mechanism library includes functions for adding, deleting, editing, and querying mechanism models; Second, it supports the classification and management of the mechanism models in the mechanism library and allows for the creation and management of custom multi-level mechanism classifications; Third, when adding a new mechanism model to the mechanism library, the mechanism name, mechanism type, applicable objects, performance evaluation criteria, and remarks information must be added before the model is created using the workflow modeling tool. Fourth, when a new mechanism model in the mechanism library contains a custom component from the component library, the user should specify the correspondence between the output parameters of the previous component and the input parameters of the custom component, or the correspondence between the output parameters of the custom component and the input parameters of the next component. Fifth, the mechanism library supports tag management for mechanisms that have been calculated and evaluated for performance, and assigns the tags to the components that use them.

5. The system for establishing an equipment fault identification model as described in claim 4, characterized in that, The first building module is specifically used for: Based on the equipment fault identification model unit and the existing fault identification model, obtain the general algorithm components corresponding to the fault identification scenario to build an algorithm library.

6. The system for establishing a device fault identification model as described in claim 4, characterized in that, The second building module is specifically used for: Based on the fault identification model composed of code, the parameters of the general algorithm are called as the default values ​​of the components and the components are integrated into a model component library.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and for running on the processor, characterized in that, When the processor executes the computer program, it implements the method for establishing a device fault identification model as described in any one of claims 1 to 3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for establishing a device fault identification model as described in any one of claims 1 to 3.

Images