Group product-oriented fault detection, diagnosis and verification platform architecture design method

Abstract

The embodiment of the invention provides a group product-oriented fault detection, diagnosis and verification platform architecture design method, which is applied to a fault diagnosis and verification platform, and the fault diagnosis and verification platform comprises a master control system operation module, a sample generation module, a model operation module and an evaluation system operation module. The method comprises the following steps: configuring a verification task corresponding to a to-be-verified fault diagnosis model through a master control system running in a master control system running module, and sending the verification task to a sample generation module; receiving a verification task through a sample generation module, generating a fault sample corresponding to the verification task, and sending the fault sample to a model operation module; calling the to-be-verified fault diagnosis model through the model operation module to process the fault sample, and obtaining a processing result output by the to-be-verified fault diagnosis model; and receiving the processing result through an evaluation system running in an evaluation system running module, and verifying and evaluating the processing result based on a preset verification index to generate a corresponding verification and evaluation result.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a fault detection, diagnosis and verification platform architecture design method for group products. Background Technology

[0002] As enterprises undergo digital transformation, they are building an increasing number of application systems to support various business operations. However, many enterprises, in their initial pursuit of rapid business growth, have neglected systematic architectural design for these applications. Among these, fault diagnosis is crucial for ensuring system security and reliability. For example, in the aviation industry, fault diagnosis can significantly reduce maintenance costs and time while improving flight safety and reliability. In data center servers, fault diagnosis enables rapid identification of fault causes, reducing system downtime.

[0003] However, modern industrial systems (such as aerospace, automotive, and data centers) are complex and have diverse failure modes. For example, an aircraft engine failure may involve the interaction of multiple subsystems, including mechanical, electrical, and hydraulic systems. Therefore, the required fault diagnosis algorithms are also complex and diverse. Current fault diagnosis algorithms (such as machine learning-based algorithms) may suffer from overfitting and insufficient generalization ability, making it difficult to guarantee the accuracy of fault diagnosis results. Therefore, how to select a suitable fault diagnosis algorithm and how to ensure the accuracy of fault diagnosis results are urgent problems that need to be solved. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a fault diagnosis and verification platform. One or more embodiments of this specification also relate to a fault detection, diagnosis, and verification platform architecture design method for group products, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a fault diagnosis verification platform is provided, comprising: The overall control system operation module is used to configure the verification task corresponding to the fault diagnosis model to be verified through the overall control system, and send the verification task to the sample generation module; The sample generation module is used to receive the verification task, generate a fault sample corresponding to the verification task, and send the fault sample to the model running module. The model running module is used to call the fault diagnosis model to be verified to process the fault sample and obtain the processing result output by the fault diagnosis model to be verified. The evaluation system operation module is used to receive the processing results through the evaluation system, and to verify and evaluate the processing results based on preset verification indicators, thereby generating corresponding verification and evaluation results.

[0006] Optionally, the fault diagnosis and verification platform further includes: The model development module is used to develop different fault diagnosis models based on different algorithms, and send the developed fault diagnosis models to the model running module, wherein the fault diagnosis model to be verified is one of the developed fault diagnosis models.

[0007] Optionally, the overall control system operation module is further configured to: The registration information of the equipment and fault diagnosis model in the operation module of the central control system is obtained through the central control system. The registration information includes the equipment name, equipment model and operating conditions of at least one equipment. The registration information also includes the function, model name and verification indicators of at least one fault diagnosis model. Based on the registration information, a verification requirement is generated corresponding to the fault diagnosis model to be verified. The verification requirement includes the device type, operating conditions, number of samples, and data type of the samples of the target device. The target device is one of the at least one devices. Configure the verification task corresponding to the fault diagnosis model to be verified based on the verification requirements, wherein the fault diagnosis model to be verified is one of the at least one fault diagnosis models.

[0008] Optionally, the overall control system operation module is further configured to: The system receives task execution phase information returned by the sample generation module and displays it through an interactive interface. Upon receiving a task status control instruction submitted by the user through the interactive interface, the task status control instruction is sent to the sample generation module.

[0009] Optionally, the sample generation module is further configured to: The target devices that meet the conditions are determined based on the device type of the target devices included in the verification task; Based on a predetermined correspondence between devices and sample files, a target sample file corresponding to the qualified target device is determined, wherein the target sample file is used to store sample data of the qualified target device; The target sample file is invoked, and the sample data contained in the target sample file is extracted according to the operating conditions of the target equipment, the number of samples, the data type of the samples, and the sampling method of the fault samples contained in the verification task to obtain the corresponding fault samples.

[0010] Optionally, the sample generation module is further configured to: A sufficiency evaluation is performed on the fault samples, and corresponding evaluation results are generated; If, based on the evaluation results, it is determined that the faulty sample does not meet the preset sufficiency conditions, a corresponding prompt message is generated and displayed through the interactive interface of the sample generation module; and / or, The prompt message is sent to the central control system operation module.

[0011] Optionally, the sample generation module is further configured to send the verification task to the model running module; The model running module is also used to receive the verification task, determine the resource occupancy ratio corresponding to the verification task based on the resource occupancy level of the verification task, and run non-verification tasks that meet the conditions according to the resource occupancy ratio.

[0012] Optionally, the model running module is further configured to: Add at least one probe to the running program corresponding to the verification task; The hardware and software resource usage during the verification task is determined by executing at least one probe. The performance monitoring information during the execution of the verification task is obtained by statistically analyzing the hardware and software resource usage determined by each probe.

[0013] Optionally, the evaluation system operation module is further configured to: Based on the verification requirements included in the verification task, determine the evaluation indicators used to verify and evaluate the fault diagnosis model to be verified. Calculate the index value corresponding to the evaluation index based on the processing result; The verification and evaluation results corresponding to the fault diagnosis model to be verified are obtained by analyzing the index values.

[0014] According to a second aspect of the embodiments of this specification, a fault detection, diagnosis, and verification platform architecture design method for group products is provided, applied to a fault diagnosis and verification platform, the fault diagnosis and verification platform including a central control system operation module, a sample generation module, a model operation module, and an evaluation system operation module, the method comprising: The verification task corresponding to the fault diagnosis model to be verified is configured by the overall control system running in the overall control system operation module, and the verification task is sent to the sample generation module. The sample generation module receives the verification task, generates a fault sample corresponding to the verification task, and sends the fault sample to the model execution module. The model running module calls the fault diagnosis model to be verified to process the fault sample and obtains the processing result output by the fault diagnosis model to be verified. The evaluation system, which runs on the evaluation system operation module, receives the processing results and evaluates the processing results based on preset verification indicators, generating corresponding verification evaluation results.

[0015] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the steps of the fault detection, diagnosis and verification platform architecture design method for group products described in the computer-executable instructions.

[0016] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the fault detection, diagnosis and verification platform architecture design method for group products.

[0017] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described fault detection, diagnosis and verification platform architecture design method for group products.

[0018] The fault diagnosis verification platform provided in this embodiment includes: a central control system operation module, used to configure the verification task corresponding to the fault diagnosis model to be verified through the central control system, and send the verification task to the sample generation module; the sample generation module, used to receive the verification task, generate a fault sample corresponding to the verification task, and send the fault sample to the model operation module; the model operation module, used to call the fault diagnosis model to be verified to process the fault sample, and obtain the processing result output by the fault diagnosis model to be verified; and an evaluation system operation module, used to receive the processing result through the evaluation system, and perform verification evaluation on the processing result based on preset verification indicators, and generate corresponding verification evaluation results. The fault diagnosis verification platform can perform real-time simulation based on an embedded system, thereby verifying the actual effect of the fault diagnosis model to be verified. Developing a new fault diagnosis verification platform can provide a more flexible and efficient fault diagnosis solution, which is beneficial to improving the accuracy and efficiency of fault diagnosis, and can better test and optimize real-time diagnostic algorithms, thereby improving the automation level of the system. Attached Figure Description

[0019] Figure 1 This is an architecture diagram of a fault diagnosis verification platform provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating an embodiment of a fault detection, diagnosis, and verification platform architecture design method for group products provided in this specification. Figure 3 This is a schematic diagram of a general operation support method for multiple models for general verification of fault detection and diagnosis of typical mechanical and electronic products, provided in one embodiment of this specification. Figure 4 This is a schematic diagram of a layered interactive modeling provided in one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a general verification system for fault detection and diagnosis of typical mechanical and electronic products provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0020] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0021] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0022] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0023] This specification provides a fault diagnosis and verification platform, and also relates to a fault detection, diagnosis and verification platform architecture design method for group products, a computing device, a computer-readable storage medium, and a computer program, which are described in detail in the following embodiments.

[0024] Figure 1 An architecture diagram of a fault diagnosis verification platform according to an embodiment of this specification is shown, specifically including: The overall control system operation module 102 is used to configure the verification task corresponding to the fault diagnosis model to be verified through the overall control system, and send the verification task to the sample generation module 104. The sample generation module 104 is used to receive the verification task, generate a fault sample corresponding to the verification task, and send the fault sample to the model running module 106. The model running module 106 is used to call the fault diagnosis model to be verified to process the fault sample and obtain the processing result output by the fault diagnosis model to be verified. The evaluation system operation module 108 is used to receive the processing results through the evaluation system, and to verify and evaluate the processing results based on preset verification indicators, and generate corresponding verification and evaluation results.

[0025] The fault diagnosis verification platform provided in the embodiments of this specification includes a central control system operation module 102, a sample generation module 104, a model operation module 106, and an evaluation system operation module 108.

[0026] The overall control system operation module 102 provides the operating conditions for the overall control system. As the core of the entire verification task process, the overall control system is responsible for proposing verification requirements, configuring verification tasks, and receiving verification evaluation results from the evaluation system operation module. Verification requirements may include the type of target equipment, operating conditions, number of samples, and data type of the samples.

[0027] The function of the sample generation module 104 is to generate the fault samples required for the verification task after receiving the instructions from the central control system, and to provide the fault samples to the model running module 106 so as to use the fault samples as input to the fault diagnosis model to be verified.

[0028] The model running module 106 aims to reproduce the data transmission quality, timing, and computing resource usage relationships between various tasks in a real equipment fault diagnosis environment, so as to support the smooth implementation of fault diagnosis verification tasks in different fields and for different services.

[0029] The evaluation system operation module 108 provides the operating conditions for the evaluation system. The evaluation system mainly realizes the performance evaluation capability and fault diagnosis capability analysis and evaluation of the fault diagnosis model to be verified. By selecting different measurement evaluation indicators according to different fault diagnosis models to be verified, the system performs verification analysis, and finally compares the results with the specified values ​​to determine the pass / fail status and draws the verification analysis conclusion.

[0030] In one optional implementation, the fault diagnosis and verification platform further includes: The model development module is used to develop different fault diagnosis models based on different algorithms, and send the developed fault diagnosis models to the model running module, wherein the fault diagnosis model to be verified is one of the developed fault diagnosis models.

[0031] Specifically, the fault diagnosis verification platform provided in this embodiment also includes a model development module. This module uses relevant programming software to develop different fault diagnosis models based on different algorithms. The developed fault diagnosis model can then be used as a fault diagnosis model to be verified. It is provided by the model development module to the model execution module 106 via Ethernet, USB, or other means for verification tasks to call.

[0032] In an optional implementation, the central control system operation module 102 is further configured to: The registration information of the equipment and fault diagnosis model in the operation module of the central control system is obtained through the central control system. The registration information includes the equipment name, equipment model and operating conditions of at least one equipment. The registration information also includes the function, model name and verification indicators of at least one fault diagnosis model. Based on the registration information, a verification requirement is generated corresponding to the fault diagnosis model to be verified. The verification requirement includes the device type, operating conditions, number of samples, and data type of the samples of the target device. The target device is one of the at least one devices. Configure the verification task corresponding to the fault diagnosis model to be verified based on the verification requirements, wherein the fault diagnosis model to be verified is one of the at least one fault diagnosis models.

[0033] Specifically, the main control system operation module 102 has a task configuration function, which can make necessary settings for the currently established verification task.

[0034] Before configuring verification tasks, it is necessary to register the equipment (electronic or mechanical equipment, etc.) and the corresponding fault diagnosis models. Specifically, this involves entering the relevant information of the equipment and fault diagnosis models into the central control system, and generating an information table based on this information. This information table contains the equipment and fault diagnosis models already entered in the central control system. When configuring verification tasks, the equipment and fault diagnosis models to be verified can be directly filtered based on this information table. The relevant information for the equipment may include the equipment name, equipment model, and modeling / operating conditions; the relevant information for the fault diagnosis model may include the function of the fault diagnosis model, model name, and verification indicators.

[0035] In addition, the central control system supports the management and indexing of various devices and fault diagnosis models through a database. After the above information entry process is completed, each time a new verification task is created, detailed information about the target device to be verified and the fault diagnosis model to be verified can be entered to complete the creation of the verification task.

[0036] In practical applications, the scale of the group products needs to be clearly defined in the configuration of verification tasks for group products.

[0037] In an optional implementation, the central control system operation module 102 is further configured to: The system receives task execution phase information returned by the sample generation module and displays it through an interactive interface. Upon receiving a task status control instruction submitted by the user through the interactive interface, the task status control instruction is sent to the sample generation module.

[0038] Specifically, the overall control system operation module 102 also has the function of monitoring and controlling the running status of the verification task. During the operation of the verification task, it can monitor the running stage of the verification task and provide feedback through the interactive interface. At the same time, it provides the permissions and functions to control the running status of the task in real time and perform the operation of continuing or stopping the task.

[0039] In practical applications, the overall control system operation module 102 can monitor and control the task operation phases of the sample generation module 104, the model operation module 106, and the evaluation system operation module 108. The task operation phases of the sample generation module 104 can include starting to generate samples and ending sample generation; the task operation phases of the model operation module 106 can include starting to run the fault diagnosis model to be verified and ending the operation of the fault diagnosis model to be verified; and the task operation phases of the evaluation system operation module 108 can include starting to run the evaluation system and ending the operation of the evaluation system.

[0040] Task status control instructions may include instructions to continue execution or instructions to pause execution.

[0041] After receiving the task execution phase information returned by the sample generation module 104 and displaying it through the interactive interface, if a pause execution command is received from the user through the interactive interface (the user needs to confirm whether the generated fault sample meets the requirements, so the verification task needs to be paused first), the pause execution command is sent to the sample generation module 104 so that the sample generation module 104 can pause the process of sending fault samples to the model execution module 106.

[0042] In addition, the central control system operation module 102 also has communication capabilities, enabling it to interact with modules of the fault diagnosis verification platform via Ethernet, USB, or other means. Specifically, this includes two main aspects: after creating a new verification task, it sends the task to the sample generation module 104 to generate fault samples; after the evaluation system operation module 108 completes its operation, it receives the verification and evaluation results returned by the module, collects, and records them. Furthermore, it can also receive task operation stage information returned by the sample generation module 104, the model operation module 106, and the evaluation system operation module 108.

[0043] In an optional implementation, the sample generation module 104 is further configured to: The target devices that meet the conditions are determined based on the device type of the target devices included in the verification task; Based on a predetermined correspondence between devices and sample files, a target sample file corresponding to the qualified target device is determined, wherein the target sample file is used to store sample data of the qualified target device; The target sample file is invoked, and the sample data contained in the target sample file is extracted according to the operating conditions of the target equipment, the number of samples, the data type of the samples, and the sampling method of the fault samples contained in the verification task to obtain the corresponding fault samples.

[0044] In an optional implementation, the sample generation module 104 is further configured to: A sufficiency evaluation is performed on the fault samples, and corresponding evaluation results are generated; If, based on the evaluation results, it is determined that the faulty sample does not meet the preset sufficiency conditions, a corresponding prompt message is generated and displayed through the interactive interface of the sample generation module; and / or, The prompt message is sent to the central control system operation module.

[0045] Specifically, the sample generation module 104 has display control and data processing functions. It can generate fault samples according to the requirements of the central control system and process the data in the verification database using the data processing function. At the same time, it is responsible for controlling the entire sample generation queue process and can call different sample files based on different types of sample generation tasks.

[0046] Furthermore, the sample generation module 104 can read the required verification object, i.e. the target device that meets the conditions and the target sample file corresponding to the target device that meets the conditions, from the verification database according to the fault sample generation requirements in the verification task, and obtain the corresponding fault sample based on the sample data of the target device that meets the conditions contained in the target sample file.

[0047] In practical applications, the target sample file contains all the sample data of the target device that meets the conditions. For example, it may contain current and voltage data throughout the entire life cycle of the target device. However, when verifying and evaluating the processing results of the fault diagnosis model to be verified based on the relevant data of the target device, only a small segment of data close to the fault may be needed. Furthermore, the arrangement or storage method of this part of the sample data may not meet the usage conditions of the embodiments of this specification. Therefore, the embodiments of this specification need to sample the sample data in the target sample file. Alternatively, if the target device is a mechanical device, the bearings of the mechanical device have multiple speeds, including low speed and high speed, and will switch between different speeds during actual operation. If the operating condition of the target device included in the verification task is a low speed condition, then the data under the low speed condition needs to be extracted and then reassembled.

[0048] In addition, the sampling method for fault samples can include the number of samples, the sampling method (random sampling, probability sampling, etc.), and some parameters involved in the sampling method. After determining the target equipment and the corresponding target sample file, the target sample file can be called, and the sample data contained in the target sample file can be extracted, segmented, and recombined according to the operating conditions of the target equipment, the number of samples, the data type of the samples, and the sampling method of the fault samples contained in the verification task, to generate a fault sample set that meets the characteristics of the fault diagnosis model to be verified and the task requirements. The verification database needs to store historical fault data of the products related to the test verification, and also receive and store newly generated fault sample sets for use in subsequent verification tasks. In the process of generating verification samples for a group of products, it is necessary to consider the commonalities of the products and the individual differences of the products, and generate multiple sets of fault samples based on the scale of the group of products.

[0049] In addition, the sample generation module 104 also has a sample sufficiency evaluation function, which can conduct sufficiency evaluation on the fault sample set set for the verification task, and perform comprehensive coverage analysis by combining the results of three typical sufficiency measures: unit coverage sufficiency, functional coverage sufficiency, and test coverage sufficiency. For samples that do not meet the sufficiency requirements, a prompt is issued. For example, if the evaluation results determine that the fault sample does not meet the preset sufficiency conditions, a corresponding prompt message is generated and displayed through the interactive interface of the sample generation module 104; and / or, the prompt message is sent to the main control system operation module 102.

[0050] The sample generation module 104 also has communication functions. It can receive verification tasks from the central control system via Ethernet, USB, etc., and communicate with the model running module 106 via common buses (such as Ethernet, 1553B, CAN, RS422, 1394B, USB, etc.) to provide the generated fault samples to the model running module 106.

[0051] In an optional implementation, the sample generation module 104 is further configured to send the verification task to the model running module; The model running module 106 is further configured to receive the verification task, determine the resource occupancy ratio corresponding to the verification task based on the resource occupancy level of the verification task, and run non-verification tasks that meet the conditions according to the resource occupancy ratio.

[0052] In an optional implementation, the model running module 106 is further configured to: Add at least one probe to the running program corresponding to the verification task; The hardware and software resource usage during the verification task is determined by executing at least one probe. The performance monitoring information during the execution of the verification task is obtained by statistically analyzing the hardware and software resource usage determined by each probe.

[0053] Specifically, the model running module 106 has the function of running algorithms. It can read the fault samples sent by the sample generator 104, call the fault diagnosis model to be verified to process the fault samples and obtain the corresponding processing results. The fault diagnosis model to be verified is developed on the model development module.

[0054] In addition, the model execution module 106 also has an equivalent resource occupancy function. To reproduce the resource consumption of non-verification tasks in a real airborne computing environment, it sets the resource consumption ratio by parsing the resource consumption level of the verification task and injecting high-priority tasks to preempt the computing resources of the verification task, thus achieving the effect of equivalent resource occupancy. In verification tasks for group products, it is necessary to simulate the resource consumption caused by multiple products performing verification tasks simultaneously.

[0055] In addition, the model running module 106 also has a task running status monitoring function, which can statistically analyze the hardware and software resource usage during each verification task. Specifically, monitoring points can be added to the running program corresponding to the verification task by instrumentation, and then the hardware and software resource usage during the verification task is determined by executing probes. Finally, the hardware and software resource usage information of each monitoring point is summarized and statistically analyzed to obtain the performance monitoring information during the verification task.

[0056] The model running module 106 also has communication functions. It can receive fault samples from the sample generation module 104 via common buses (such as Ethernet, 1553B, CAN, RS422, 1394B, USB, etc.); receive the fault diagnosis model to be verified provided by the model development module via Ethernet, USB, etc.; and output the processing results generated by the fault diagnosis model to be verified to the evaluation system running module 108.

[0057] In an optional implementation, the evaluation system operation module 108 is further configured to: Based on the verification requirements included in the verification task, determine the evaluation indicators used to verify and evaluate the fault diagnosis model to be verified. Calculate the index value corresponding to the evaluation index based on the processing result; The verification and evaluation results corresponding to the fault diagnosis model to be verified are obtained by analyzing the index values.

[0058] Specifically, the evaluation system operation module 108 has an indicator selection function, which can select the indicators used to evaluate the fault diagnosis model to be verified according to the verification requirements. In verification tasks for group products, evaluation indicators related to group verification need to be selected.

[0059] The evaluation system operation module 108 also has an indicator calculation function, which can calculate the selected indicators based on the processing results provided by the model operation module 106.

[0060] To address the diversity, scale, and individual differences among group products, suitable evaluation indicators are designed to validate the effectiveness and accuracy of the model. The fault diagnosis evaluation method for group products mainly includes the following important dimensions: Diagnostic accuracy rate: refers to the proportion of faults correctly diagnosed by the fault diagnosis system.

[0061]

[0062] Diagnostic coverage: This measures whether the model can cover all possible failure types. For product groups, diagnostic coverage should consider not only common failure modes but also failures under boundary conditions or special use cases.

[0063]

[0064] Fault detection rate: measures the ability of a fault diagnosis system to detect faults in a timely manner.

[0065]

[0066] False diagnosis rate: refers to the proportion of faults incorrectly identified by a diagnostic system, that is, incorrectly identifying a fault as a fault when there is no fault.

[0067]

[0068] Recall rate: Measures the comprehensiveness of a fault diagnosis system, that is, the proportion of all actual fault samples that the system can identify. For a group of products, it ensures that faults of different products and under different usage conditions are not missed.

[0069]

[0070] Accuracy: Measures the proportion of correct fault diagnoses in the fault diagnosis results, avoiding misdiagnosis.

[0071]

[0072] Diagnostic model stability: Stability assessment evaluates the consistency of the model's performance across different devices, environments, and usage scenarios. In validation of a group of products, the model needs to maintain high stability across multiple individual instances.

[0073]

[0074] Resource utilization: Product verification tasks may consume varying amounts of computing resources. This metric evaluates the performance of the fault diagnosis model under resource constraints. It is applicable when the product group is large-scale and the verification tasks are complex.

[0075]

[0076] Comprehensive Evaluation Index for Fault Diagnosis of Group Products: The comprehensive evaluation index is a weighted average of various key indicators to provide an overall performance assessment.

[0077]

[0078] in, The weight of each indicator is determined based on task requirements, product characteristics, and industry standards.

[0079] Implementation steps of the group product fault diagnosis and evaluation method: Step 1: Collect fault sample data of the group of products and classify them into "faulty" and "non-faulty" samples.

[0080] Step 2: Use the fault diagnosis model to be verified to diagnose these samples and obtain the prediction results.

[0081] Step 3: Calculate the above evaluation indicators (such as accuracy, recall, etc.) based on the diagnostic results.

[0082] Step 4: Evaluate the overall performance of the model using the Comprehensive Evaluation Index (CEI).

[0083] Step 5: If the evaluation results meet the preset performance standards, the model is considered to meet the verification requirements; otherwise, adjustments and optimizations are required.

[0084] The evaluation system operation module 108 also has a result analysis function, which can analyze the index calculation results, compare the results with the specified values ​​to determine the qualification, and draw verification analysis conclusions.

[0085] In addition, the evaluation system operation module 108 also has communication functions, and can receive the processing results of the model operation module 106 via Ethernet, USB or other means; and return the verification evaluation results to the main control system operation module 102 via Ethernet, USB or other means.

[0086] The fault diagnosis verification platform provided in this embodiment includes: a central control system operation module, used to configure the verification task corresponding to the fault diagnosis model to be verified through the central control system, and send the verification task to the sample generation module; the sample generation module, used to receive the verification task, generate a fault sample corresponding to the verification task, and send the fault sample to the model operation module; the model operation module, used to call the fault diagnosis model to be verified to process the fault sample, and obtain the processing result output by the fault diagnosis model to be verified; and an evaluation system operation module, used to receive the processing result through the evaluation system, and perform verification evaluation on the processing result based on preset verification indicators, and generate corresponding verification evaluation results. The fault diagnosis verification platform can perform real-time simulation based on an embedded system, thereby verifying the actual effect of the fault diagnosis model to be verified. Developing a new fault diagnosis verification platform can provide a more flexible and efficient fault diagnosis solution, which is beneficial to improving the accuracy and efficiency of fault diagnosis, and can better test and optimize real-time diagnostic algorithms, thereby improving the automation level of the system.

[0087] Figure 2 The flowchart illustrates a fault detection and diagnosis verification platform architecture design method for group products according to an embodiment of this specification. The method is applied to a fault diagnosis verification platform, which includes a central control system operation module, a sample generation module, a model operation module, and an evaluation system operation module. The method specifically includes the following steps.

[0088] Step 202: Configure the verification task corresponding to the fault diagnosis model to be verified through the overall control system running in the overall control system operation module, and send the verification task to the sample generation module.

[0089] Step 204: Receive the verification task through the sample generation module, generate the fault sample corresponding to the verification task, and send the fault sample to the model running module.

[0090] Step 206: The model running module calls the fault diagnosis model to be verified to process the fault sample and obtains the processing result output by the fault diagnosis model to be verified.

[0091] Step 208: The evaluation system, which runs on the evaluation system operation module, receives the processing result and evaluates the processing result based on preset verification indicators to generate the corresponding verification evaluation result.

[0092] In an optional implementation, the method further includes: Different fault diagnosis models are developed based on different algorithms through the model development module, and the developed fault diagnosis models are sent to the model running module. The fault diagnosis model to be verified is one of the developed fault diagnosis models.

[0093] In an optional implementation, the method further includes: The registration information of the equipment and fault diagnosis model in the operation module of the central control system is obtained through the central control system. The registration information includes the equipment name, equipment model and operating conditions of at least one equipment. The registration information also includes the function, model name and verification indicators of at least one fault diagnosis model. Based on the registration information, a verification requirement is generated corresponding to the fault diagnosis model to be verified. The verification requirement includes the device type, operating conditions, number of samples, and data type of the samples of the target device. The target device is one of the at least one devices. Configure the verification task corresponding to the fault diagnosis model to be verified based on the verification requirements, wherein the fault diagnosis model to be verified is one of the at least one fault diagnosis models.

[0094] In an optional implementation, the method further includes: The overall control system operation module receives task operation stage information returned by the sample generation module and displays it through an interactive interface; Upon receiving a task status control instruction submitted by the user through the interactive interface, the task status control instruction is sent to the sample generation module.

[0095] In an optional implementation, the method further includes: The sample generation module determines the eligible target devices based on the device type of the target devices included in the verification task. Based on a predetermined correspondence between devices and sample files, a target sample file corresponding to the qualified target device is determined, wherein the target sample file is used to store sample data of the qualified target device; The target sample file is invoked, and the sample data contained in the target sample file is extracted according to the operating conditions of the target equipment, the number of samples, the data type of the samples, and the sampling method of the fault samples contained in the verification task to obtain the corresponding fault samples.

[0096] In an optional implementation, the method further includes: The sufficiency evaluation of the faulty samples is performed by the sample generation module, and corresponding evaluation results are generated. If, based on the evaluation results, it is determined that the faulty sample does not meet the preset sufficiency conditions, a corresponding prompt message is generated and displayed through the interactive interface of the sample generation module; and / or, The prompt message is sent to the central control system operation module.

[0097] In an optional implementation, the method further includes: The verification task is sent to the model execution module through the sample generation module; The model running module receives the verification task, determines the resource occupancy ratio corresponding to the verification task based on the resource occupancy level of the verification task, and runs non-verification tasks that meet the conditions according to the resource occupancy ratio.

[0098] In an optional implementation, the method further includes: The model running module adds at least one probe to the running program corresponding to the verification task. The hardware and software resource usage during the verification task is determined by executing at least one probe. The performance monitoring information during the execution of the verification task is obtained by statistically analyzing the hardware and software resource usage determined by each probe.

[0099] In an optional implementation, the method further includes: The evaluation system operation module determines the evaluation indicators for verifying and evaluating the fault diagnosis model to be verified based on the verification requirements included in the verification task. Calculate the index value corresponding to the evaluation index based on the processing result; The verification and evaluation results corresponding to the fault diagnosis model to be verified are obtained by analyzing the index values.

[0100] The above is an illustrative scheme of a fault detection, diagnosis, and verification platform architecture design method for group products according to this embodiment. It should be noted that the technical solution of this fault detection, diagnosis, and verification platform architecture design method for group products belongs to the same concept as the technical solution of the aforementioned fault diagnosis and verification platform. Details not described in detail in the technical solution of the fault detection, diagnosis, and verification platform architecture design method for group products can be found in the description of the technical solution of the aforementioned fault diagnosis and verification platform.

[0101] This specification also provides a general operation support method for multiple models for general verification of fault detection and diagnosis of mechanical and electronic products, 106, which is applied to the model operation module and includes: The multi-mode algorithms used for fault detection and diagnosis are uniformly expressed and encapsulated to obtain multiple algorithm component models; Construct information interaction rules between the multiple algorithm component models; Based on the multiple algorithm component models and the interaction rules, a graph flow operation mechanism for the multiple algorithm component models is constructed; The runtime environment of the multiple algorithm component models is simulated, wherein the runtime environment simulation includes: data transmission environment simulation and computation thread simulation; Based on the simulated graph flow operation mechanism and the simulated operation environment of the constructed multiple algorithm components, a general host machine for fault detection and diagnosis algorithms is built. Based on the general host machine for the fault detection and diagnosis algorithm that has been built, the fault detection and diagnosis of mechanical and electronic products is verified, and the diagnostic verification results are obtained.

[0102] In practical implementation, given the diverse types of fault detection and diagnosis algorithms for mechanical and electronic products, a unified data interface can be constructed to uniformly express and encapsulate algorithms of various types and levels, achieving standardization and management under a unified architecture. Each fault detection and diagnosis algorithm establishes a unified expression form and abstracts it into an algorithm component model (also referred to as an algorithm component). This algorithm component model balances openness, integration, flexibility, and modularity.

[0103] In one optional embodiment, the method of uniformly expressing and encapsulating the multi-mode algorithm used for fault detection and diagnosis to obtain multiple algorithm component models may include the following sub-steps: Sub-step 1: Based on object-oriented component technology, standardize and encapsulate the multi-mode algorithm used for fault detection and diagnosis, and extract key information; among which, key information includes but is not limited to: structure type, global variables, function declarations, functions, and rules; Sub-step 2: Generate algorithm component models based on the key information corresponding to each algorithm.

[0104] Each algorithm component model includes: an input port, an internal function node, and an output port; the input port is used to receive data, the output port is used to send data, and the internal function node is used to provide the core functions of the algorithm.

[0105] By constructing information interaction rules between multiple algorithm component models, the complexity of information modeling can be reduced.

[0106] An optional approach to constructing information interaction rules between multiple algorithm component models is to adopt a hierarchical interaction modeling method, dividing the information interaction between multiple algorithm component models into a function node layer, an algorithm component layer, and an algorithm model layer.

[0107] The information interaction of the function node layer exists within the algorithm component model. Data is transferred between function nodes through internal interfaces, and one-way data information interaction is carried out in accordance with the sequential logic between functions. The information interaction between the algorithm component models in the algorithm component layer is carried out through the input and output terminals. The information interaction between the algorithm component models in the algorithm model layer is designed based on the specific application scenario of the fault detection and diagnosis task.

[0108] In this alternative implementation, a hierarchical interactive modeling method is used to divide the information interaction of the fault detection and diagnosis algorithm model into three levels, which can reduce the complexity of information modeling.

[0109] An optional graph flow operation mechanism that constructs multiple algorithm component models based on multiple algorithm component models and interaction rules can be as follows: First, it was determined that a two-layer stream transmission mechanism would be used as the data transmission mechanism. The two-layer streaming mechanism includes control flow and data flow.

[0110] Secondly, it was determined that the component operation adopts an object-oriented event-triggered concurrent queue mechanism; Finally, based on the data transmission mechanism, the object-oriented event-triggered concurrent queue mechanism, multiple algorithm component models, and interaction rules, a graph flow operation mechanism for multiple algorithm component models is constructed.

[0111] The step of simulating the runtime environment of multiple algorithm component models reproduces the data transmission quality, timing, and computational resource usage relationships between tasks in a real fault detection and diagnosis environment, so as to accurately simulate a typical data transmission environment.

[0112] The runtime environment simulation includes, but is not limited to: data transmission environment simulation and computation thread simulation. Data transmission environment simulation includes, but is not limited to: latency simulation, packet loss simulation, and sampling rate fluctuation simulation; computation thread simulation includes, but is not limited to: real-time matching simulation and computation resource usage simulation.

[0113] Based on the simulated graph flow operation mechanism and the simulated operation environment of multiple algorithm components, the general host machine for fault detection and diagnosis of typical mechanical and electronic products is designed and developed in the step of building a general host machine for fault detection and diagnosis. It supports rich data interfaces to meet the data transmission needs of verification tasks in various fields.

[0114] An optional method for verifying fault detection and diagnosis of mechanical and electronic products and obtaining diagnostic verification results based on the established general-purpose host machine for fault detection and diagnosis algorithms can be as follows: The user selects the target algorithm component model in the display screen of the general host machine for fault detection and diagnosis algorithms; inputs the data to be verified into the target algorithm component model, and sets the data transmission quality and computing resource usage, triggering the general host machine for fault detection and diagnosis algorithms to simulate the running environment of the target algorithm component model and output the diagnostic verification results.

[0115] The diagnostic validation results are used to characterize the capabilities of the fault monitoring and diagnostic model.

[0116] The general operation support method for multi-model general verification of fault detection and diagnosis of mechanical and electronic products provided in the embodiments of this specification unifies and encapsulates the multi-model algorithms used in fault detection and diagnosis to obtain multiple algorithm component models; constructs information interaction rules between multiple algorithm component models; constructs a graph flow operation mechanism for multiple algorithm component models based on the multiple algorithm component models and interaction rules; simulates the operation environment of multiple algorithm component models; builds a general host machine for fault detection and diagnosis algorithms based on the constructed graph flow operation mechanism and the multiple algorithm component models after the operation environment simulation; and performs fault detection and diagnosis verification for mechanical and electronic products based on the built general host machine for fault detection and diagnosis algorithms, and obtains diagnostic verification results. The general host machine for fault detection and diagnosis algorithms built by the method provided in the embodiments of this specification can perform general verification of fault detection and diagnosis for typical mechanical and electronic products in various fields and scenarios, and the verification results are accurate and reliable.

[0117] Figure 3 This is a schematic diagram illustrating a general operational support method for multiple models used in the universal verification of fault detection and diagnosis of typical mechanical and electronic products. (For example...) Figure 3 As shown, the process consists of four parts: Part 1: Unified expression and encapsulation of multi-mode fault detection and diagnosis algorithms; Part 2: Layered interaction and graph flow operation of multi-layer algorithm models; Part 3: Typical operating environment model; Part 4: Design and development of a general host machine for fault detection and diagnosis algorithms. Each of these four parts will be described in detail below.

[0118] Part 1: Unified Expression and Encapsulation of Multi-Mode Fault Detection and Diagnosis Algorithms Fault detection and diagnosis algorithms for typical mechanical and electronic products are cross-technical in nature and include different types such as model-driven and data-driven algorithms. Therefore, it is necessary to unify the expression and encapsulation of algorithms at various levels. Specifically, adaptive component encapsulation technology is used to standardize and encapsulate fault detection and diagnosis algorithms. Key information (including structure types, global variables, function declarations, functions, rules, etc.) is extracted to form algorithm component models. Each algorithm component model is a set of functional objects with input / output ports. The input ports are used to receive data, and the output ports are used to send data. The internal function nodes are highly cohesive specific functions that process the algorithm and realize its core functionality.

[0119] An exemplary unified encapsulation structure for algorithm component models is shown below: def run(params,context=None,task=None): """ Component single execution function Args: params(dict): key is the name of the input parameter of the component. context(runtime.context.ComponentContest): The component context, containing data storage interface, file storage interface, queue interface, and properties. algo_contest: Algorithm context task(disk): Information related to the algorithm component model execution task, including key descriptions: "component_key": A unique key for the component in the algorithm, which remains unchanged; "counter": The key for the component in this execution. Number of times, run count, changes, restart running task reset to 0 Returns: dict: key is the name of the component's output parameter """ It should be noted that the above is only an example of a unified encapsulation structure for algorithm component models, and the implementation process is not limited to this. Those skilled in the art can flexibly set the unified encapsulation structure for algorithm component models.

[0120] Part Two: Layered Interaction and Graph Flow Execution of Multi-Layer Algorithm Model; In practical applications, the operation of a fault detection and diagnosis algorithm model is often based on the interaction and cooperation of multiple algorithm component models. During the operation, there is complex and frequent information interaction between the algorithm component models. Therefore, it is necessary to construct the information interaction rules between the fault detection and diagnosis algorithm component models.

[0121] Specifically, to reduce the complexity of information modeling, a layered interactive modeling approach is adopted, dividing information interaction into three layers: the function node layer, the algorithm component layer, and the algorithm model layer. Information interaction at the function node layer occurs within the algorithm component model; data is transferred between function nodes through internal interfaces, following the sequential logic between functions for unidirectional data exchange. Information interaction between algorithm component models occurs through the component's input and output terminals. Figure 4 To illustrate a layered interactive modeling diagram of an embodiment of this specification, the information interaction of the algorithm model needs to be guided by the fault detection and diagnosis task design scheme according to the actual application scenario.

[0122] Based on the unified expression technology of multi-mode fault detection and diagnosis algorithms and the hierarchical interaction technology of fault detection and diagnosis algorithm model elements, a graph flow operation mechanism for fault detection and diagnosis algorithm models is constructed. Specifically, the data transmission mechanism adopts a two-layer stream transmission mechanism, namely control flow and data flow. Component operation adopts an object-oriented event-triggered concurrent queue mechanism.

[0123] In the event-triggered concurrent queue mechanism, each algorithm component model has its own independent running thread for the computation of internal function nodes. Component models with different priorities can be represented by thread nodes with different priorities. For fault detection and diagnosis tasks where the computation time of nodes in the training and testing streams differs, and multiple tests and uses occur after training, edge connections with first-in-first-out queues are added between different thread nodes to prevent data loss during runtime. Algorithm component model ports can be seen as interfaces for external connections, and connections between components can be seen as middleware for establishing these port connections. The connections between algorithm component models are not predetermined but determined by the user. The execution of algorithm components is triggered by events. The target component is triggered by information indicating the completion of the source component model's execution, and simultaneously receives the output data from the source component model. When multiple source component models are connected to the input port, all source component models can trigger the target component's execution capability, and whether the target algorithm component model runs depends on whether the received parameters meet the algorithm's execution requirements. During execution, the data stream scheduler is activated by a predefined message. Upon completion of the scheduler's execution, it can trigger a data transmission event, notifying the thread output node that it can output data.

[0124] Part Three: Typical Operating Environment Model To achieve realistic simulation of fault detection and diagnosis in various fields and scenarios, this study simulates the limitations of data transmission quality and computing resource consumption on the host machine where the algorithm model runs, in order to match the latency, packet loss, sampling rate fluctuations and limited computing resources in real scenarios, while meeting the computing power requirements of the fault detection and diagnosis algorithm model.

[0125] Part Four: Design and Development of a General Host Machine for Fault Detection and Diagnosis Algorithms

[0126] This paper describes the development of a general verification system for fault detection and diagnosis of typical mechanical and electronic products. An exemplary structural diagram of such a system is shown below. Figure 5 As shown, the system mainly includes a fault detection and diagnosis model development platform and a general-purpose host machine for running algorithm models (i.e., algorithm component models). Its data interface supports Ethernet, USB, and bus transmission via 1553B, CAN, RS422, and 1394B to support the smooth implementation of fault detection and diagnosis system testing and verification tasks for products in different fields. The real-time requirements of the general-purpose fault detection and diagnosis host machine are achieved through efficient information interaction between the aforementioned algorithm model elements.

[0127] A general-purpose verification system for fault detection and diagnosis of typical mechanical and electronic products serves as the core of the verification algorithm. It is responsible for processing the input data and outputting the algorithm results as the verification input. During a single verification run, the system can perform the following operations: First, the existing typical mechanical or electronic product fault detection and diagnosis models are systematically and uniformly formatted, so that their external interfaces, such as the "unified encapsulation structure of algorithm components", are encapsulated into the system, and their input parameters, output parameters and global parameters are all displayed in the system, so as to achieve unified standardization and management of algorithm components by the system.

[0128] Secondly, the system abstracts the encapsulated algorithm components into algorithm blocks, which system users can freely combine to obtain a complete algorithm model, provided that the interface corresponds to the block.

[0129] Next, the user selects the data to be analyzed and inputs it into the algorithm model, sets the data transmission quality and simulates the computing resource usage, and then runs the algorithm model.

[0130] Finally, the system outputs the analysis results of the algorithm model, which are used to verify the capability of the fault monitoring and diagnosis model.

[0131] The general host machine for fault detection and diagnosis algorithms built by the method provided in the embodiments of this specification can perform general verification of fault detection and diagnosis for typical mechanical and electronic products in various fields and scenarios, and the verification results are accurate and reliable.

[0132] This specification also provides a sample generation method for joint verification of fault detection and diagnosis of group products, applied to the evaluation sample generation module 104, including: According to the project requirements of the target project, the initial samples stored in the database are filtered to obtain the first intermediate samples related to the target project; If it is determined that the sample size of the first intermediate sample is insufficient, a second intermediate sample is generated by interpolation. Determine the failure mode corresponding to each first intermediate sample and the second intermediate sample, and extract the failure modes that meet the consistency index from each failure mode to obtain the set of failure modes to be verified. Determine the sample to be verified for each fault mode in the set of fault modes to be verified, and perform a sufficiency test on the sample to be verified. Based on the sufficiency test results, target samples related to the target project are identified from the samples to be verified.

[0133] Specifically, the target project can be a verification system for mechanical and electronic products targeting a group of products. The project requirements can be the number and type of target samples needed to detect and diagnose typical failure modes of the target project.

[0134] Based on this, in the process of screening and obtaining the required target samples, the initial samples stored in the database can be screened according to the project requirements of the target project to obtain the first intermediate sample related to the target project.

[0135] In practical applications, an in-depth analysis of the initial samples stored in the database can be performed first to extract useful information and features. Specifically, when determining fault detection and diagnosis samples for typical failure modes in a product verification system, the basis for sample selection must first be clarified. Based on a summary of the basic process of fault detection and diagnosis in verification systems and the theoretical methods and experimental operations involved in each step, an in-depth analysis of the sample library for typical failure mode detection and diagnosis of verification systems was conducted. A set of sample attribute information was selected to adequately characterize the applicability of comprehensive test samples for various verification systems, serving as the basis for determining system detection and diagnosis samples.

[0136] To build an industry ecosystem for fault detection and diagnosis that involves both manufacturers and users of group products, this specification's embodiments define group products from multiple perspectives. Group products refer to a set of products used for a specific purpose, possessing similar principles and functional characteristics, employing similar condition monitoring schemes, and having similar fault prediction and diagnosis needs. They may originate from different manufacturers and be operated and maintained by different users under different conditions. The characteristic of group products is that they belong to the same category of products, with identical or similar main functions and structures. This results in their fault or degradation tag sets being identical or having significant overlap, thus laying the foundation for comprehensive analysis of group condition monitoring data.

[0137] (1) Product characteristic analysis.

[0138] Identify the core functionalities and structural characteristics of the product group and ensure that the sample covers these characteristics.

[0139] (2) Fault mode identification.

[0140] Identify all possible failure modes that the product group may encounter, including but not limited to mechanical failures, electronic failures, and software failures.

[0141] (3) Simulation of working conditions.

[0142] Simulate the performance changes of the group of products under different operating conditions, such as temperature, humidity, and pressure, to ensure that the samples can reflect these changes.

[0143] (4) Sample diversity.

[0144] Ensure that the sample set includes product data from different manufacturers, users, operating regions, and application environments.

[0145] (5) The sample is representative.

[0146] The analysis examines whether the sample can represent the overall product group, including data on different failure types and normal operating conditions.

[0147] In one alternative implementation, after obtaining the first intermediate sample related to the target project, the method further includes: The target sample size related to the target project is determined based on the project requirements.

[0148] Specifically, after obtaining the first intermediate sample through the aforementioned screening method, it is necessary to determine whether the number of the first intermediate sample meets the requirements. If not, a certain number of samples need to be generated so that the sum of the number of generated samples and the number of intermediate samples meets the requirements.

[0149] In the embodiments of this specification, based on the intensional analysis, a sample size determination algorithm is used to evaluate whether the sample size of the intermediate samples meets the requirements. The algorithm considers the following factors: Fault type diversity: Ensure sufficient samples for each fault type; Feature coverage: Ensure that the selected samples can cover all changes in key features; Model complexity: More complex models may require more data to avoid overfitting.

[0150] Based on this, the embodiments of this specification employ a sample size determination algorithm based on sequential sampling inspection theory to evaluate whether the sample size of the intermediate sample meets the requirements. The specific steps are as follows: Step 1: Based on the system-level index constraints and risk constraints of the fault detection and diagnosis system, calculate the sequential verification chart parameters s, h1, and h2, and draw the relative accuracy sequential verification chart.

[0151] Step 2: Randomly select fault modes Fault samples.

[0152] Step 3: Based on fault mode F i Based on the indicator requirements and risk requirements, determine the failure mode F. i Number of samples N in the degradation process i1 When fault mode F cannot be obtained i When determining the required index and risk values, the sample size N for the degradation process can be determined using fault diagnosis system-level index constraints and risk constraints. i1 .

[0153] Step 4: For fault mode F i The relative accuracy of the obtained sample sequence is denoted as ,remember Fault mode F i The j-th relative accuracy sample value:

[0154] Step 5: Let ,calculate:

[0155] Test sample points Plotted on the sequential test chart.

[0156] Step Six: Based on the test sample points Given its position in the sequential test graph, make a decision: when When it is in the acceptor domain, the conclusion is "accepted"; when When it is located in the rejection region, the conclusion is "reject"; when If the test is located in the continued testing area, the test will continue.

[0157] Step 7: If you need to continue the experiment after completing Step 6, repeat Steps 2 through 6 until you get a "receive" or "reject" conclusion.

[0158] Alternatively, the embodiments of this specification may also employ a fault detection rate verification sample size determination algorithm with equal risk for both parties to evaluate whether the sample size of the first intermediate sample meets the requirements. The specific steps are as follows: (1) Determine the q1 and q0 values ​​of the fault detection rate.

[0159] If the project requirements specify the required value and minimum acceptable value for the fault detection rate, then q1 is the minimum acceptable value and q0 is the required value.

[0160] If the project requirements only specify a required value for the fault detection rate, then q1 is that required value, and q0 needs to be determined through the evaluation and verification outline. The specific method for determining the value of q0 is as follows: If the expected value of the fault detection rate is greater than the required value, then q0 can be taken as the expected value; If the expected value of the fault detection rate is less than the required value, or there is no expected value, then a fault detection rate greater than the required value is re-determined and used as the q0 value.

[0161] (2) Determine the risks α and β for both parties.

[0162] If the project requirements clearly specify the risk values ​​α and β to be verified, then those values ​​should be used directly. If the project requirements specify the confidence level C for verification (only one C value needs to be given under the condition α=β), then take α=β=1-C; If the project requirements do not include relevant requirements, they need to be determined through evaluation and verification of the outline, and α=β=0.2 can usually be taken.

[0163] (3) Determine the lower limit of the sample size.

[0164] In determining , and , Subsequently, by consulting the binomial distribution evaluation table for verifying the fault detection rate of both parties with equal risk, the parameter combination that meets the verification requirements was obtained. ,in This indicates the minimum required sample size.

[0165] Let the sample size be:

[0166] in, This represents the function for determining the sample size based on a binomial distribution lookup table. Sample size As a statistical lower limit constraint for determining the sample size.

[0167] The embodiments in this specification have a lower sample size limit. Based on this, a sample size correction mechanism is introduced to improve the engineering rationality of the sample size determination results.

[0168] To further consider the distribution of samples in the feature space, a feature coverage coefficient is introduced. This is used to characterize the extent to which a sample covers the range of changes in key features. When the sample coverage in the feature space is insufficient, the required sample size should be increased accordingly.

[0169] in, For adjustment coefficients, Indicates feature coverage.

[0170] Based on the combined requirements of the lower limit of the sample size for verifying the fault detection rate and the feature coverage correction requirements, the final sample size was determined as follows:

[0171] Once the sample size is determined, tests for imbalance and sufficiency can be performed.

[0172] Based on the following imbalance metric, check whether the current sample size meets the requirements for imbalanced sample occurrence in fault detection and diagnosis capability verification. If not, adjust the sample size determination parameters and redetermine the sample size.

[0173] Based on the proficiency testing requirements under imbalanced sample conditions for the fault detection and diagnosis model, and referring to historical data and FMEA analysis results, the expected fault mode distribution can be set as follows: The fault mode distribution output in (2) is as follows Calculate the KL divergence of the failure mode distribution:

[0174] like If the sample size is less than the given threshold, it means that the distribution of the generated failure modes meets the expectations and the requirements.

[0175] Based on the following sample sufficiency metrics, check whether the current sample size meets the sample sufficiency requirements for a certain type of sample in the fault detection and diagnosis capability verification. If not, adjust the sample size determination parameters and redetermine the sample size.

[0176] Failure modes The half-width of the confidence interval for its incidence rate is calculated as follows:

[0177] in, The total number of samples, .

[0178] like ,in If the given threshold is not met, it indicates that the sample size for this type of sample is too small, and the sample size for this category needs to be increased.

[0179] When the current sample size satisfies At the time, it is assumed that the sample size meets the training and validation requirements of the fault detection and diagnosis model in terms of both statistical significance and engineering structure; when the sample size is insufficient, the sample size needs to be expanded by supplementing or generating samples.

[0180] In one optional implementation, generating the second intermediate sample through interpolation includes: Obtain fault data generated by performing forward diffusion noise injection on initial samples, and determine the target condition variable corresponding to the fault data; The fault data and the target condition variable are input into the trained sample generation model for processing to generate a second intermediate sample.

[0181] Furthermore, the sample generation model includes a generator network, a discriminator network, and a degenerate feature reconstruction network; Accordingly, the method further includes: Construct training samples, wherein the training samples contain historical fault data; The training samples are input into the training sample generation model, and the generator network processes the training samples to generate corresponding generated samples. The generated sample is input into the degradation feature reconstruction network, and the degradation features of the generated sample are reconstructed by the degradation feature reconstruction network to generate a first degradation feature; Based on the generated samples and the historical fault data, interpolation samples are generated; The training samples, the generated samples, and the interpolated samples are input into the discriminator network for processing to generate corresponding discrimination results. The loss value is calculated based on the discrimination result, the interpolation sample, and the first degradation feature. The model parameters of the sample generation model to be trained are adjusted based on the loss value to obtain the trained sample generation model.

[0182] Furthermore, the construction of training samples includes: Acquire multiple historical fault data related to the target project, extract features from the target historical fault data, and obtain at least two degradation features, wherein the target historical fault data is each of the multiple historical fault data; Initial condition variables corresponding to the target historical fault data are constructed based on the at least two degradation trend features; The target historical fault data is generated by performing forward diffusion noise injection on the target fault data according to a preset number of diffusion steps. Training samples are constructed based on the target fault data, the initial condition variables, and the preset diffusion steps.

[0183] Specifically, for the initial sample Noise is added to it according to the preset number of diffusion steps to obtain :

[0184] in, , The diffusion scheduling parameters are determined by the preset noise schedule. It is the identity matrix, representing It is a "standard Gaussian noise vector with each dimension being independent and the variance being equal to 1". Indicates the first In each diffusion step, the sample is composed of the original sample. Compared with standard Gaussian noise According to the cumulative signal retention factor It is obtained by performing a linear combination.

[0185] In practical applications, The signal retention coefficient is the single-step signal retention coefficient / noise scheduling coefficient. Cumulative signal retention (cumulative alpha); t is the diffusion time step / noise step count, assuming the diffusion step count is... ,but .

[0186] In one optional implementation, determining the target condition variable corresponding to the fault data includes: Feature extraction is performed on the initial sample to obtain at least two second degenerate features; Interpolation is performed on the at least two second degradation features to generate target condition variables corresponding to the fault data.

[0187] Specifically, for each initial sample (time-series signal segment) under a known fault level, extract... Dimensional degeneracy features constitute the set of condition variables:

[0188] Where i is one of the n initial samples; It can be composed of time-domain / frequency-domain / time-frequency-domain features (such as RMS, kurtosis, dominant frequency energy, envelope spectrum amplitude, etc.) and used to characterize the degree of degradation, the direction of degradation and the rate of change.

[0189] For the set of condition variables Interpolation is performed to obtain the conditional variable representing the unknown degree of the target fault. For example, under linear interpolation:

[0190] in, Let be the set of condition variables corresponding to the a-th sample out of n initial samples; Let b be the set of condition variables corresponding to the b-th sample out of n initial samples; The interpolation coefficient is used to control the linear interpolation position of the target condition variable between two known fault states.

[0191] Furthermore, by constructing a sample generation model, it is possible to generate samples for unknown fault levels based on this model. The specific process can be divided into three stages: data preparation, model training, and sample generation under unknown fault levels.

[0192] In one optional implementation, the step of inputting the fault data and the target condition variable into the trained sample generation model for processing to generate a second intermediate sample includes: The fault data and the target condition variable are input into the trained sample generation model, and the generator network processes the fault data and the target condition variable to generate the corresponding second intermediate sample.

[0193] Specifically, the second intermediate sample, corresponding to the sample generation stage under the unknown fault degree, is generated using a sample generation model. This stage first samples fault samples and then concatenates the degradation trend condition variable (target condition variable) under the target fault degree onto these samples. The fault samples and the target condition variable are then input into the trained sample generation model, where the generator network processes them to obtain the generator network's output. This output represents the fault sample corresponding to the input degradation trend condition variable for the fault degree. By interpolating the degradation trend condition variables extracted from existing fault samples, the degradation trend condition variable under the unknown fault degree is calculated, thus completing the interpolation generation of missing fault samples under the unknown fault degree.

[0194] In practical applications, for a known set of condition variables Interpolation is performed to obtain the conditional variable representing the unknown degree of the target fault. For example, under linear interpolation:

[0195] Then, the sample generation is gradually inverted from pure noise, that is, the sample generation stage starts with high noise initialization:

[0196] right Stepwise noise reduction:

[0197] in, This is a random noise term in the back diffusion process, used to characterize the uncertainty of the back conditional distribution, thereby ensuring that the generation process has randomness and diversity.

[0198] The final generated sample is:

[0199] In addition, the data preparation stage is mainly used to extract conditional variables of known failure sample degradation trends and to construct a training sample set composed of failure samples and conditional variables.

[0200] In the degradation trend condition variable extraction stage, the fault samples with known fault levels, i.e., historical fault data, are sent to the degradation trend condition variable extraction module. From each fault sample, k degradation features that can characterize the degree of equipment fault are extracted, i.e., k data carrying fault information are extracted and spliced ​​together to form the degradation trend condition variable, i.e., the initial condition variable.

[0201] As mentioned earlier, the initial condition variable can be expressed as:

[0202] in, It can be composed of time-domain / frequency-domain / time-frequency-domain features (such as RMS, kurtosis, dominant frequency energy, envelope spectrum amplitude, etc.) and used to characterize the degree of degradation, the direction of degradation and the rate of change.

[0203] In practical applications, the extracted k features that characterize the degree of equipment failure can be the mean, variance, and standard deviation of the equipment failure degree. Taking k = 3, failure samples 1 and 2, and the extracted features being the mean, variance, and standard deviation as an example, the mean, variance, and standard deviation of the equipment failure degree are extracted from failure samples 1 and 2 respectively. The three features extracted from failure sample 1 are concatenated to generate the initial condition variable for failure sample 1; the three features extracted from failure sample 2 are also concatenated to generate the initial condition variable for failure sample 2.

[0204] After obtaining the initial condition variables, forward diffusion noise injection is performed on the target historical fault data according to the preset diffusion step number to generate target fault data: Assuming the target historical fault data (initial sample) is The forward diffusion noise is injected according to the preset diffusion step number to obtain... :

[0205] in, , These are the diffusion scheduling parameters (determined by a preset noise schedule).

[0206] Let the number of diffusion steps be ,but .

[0207] The target fault data, initial condition variables, and preset diffusion steps are then concatenated to generate training samples.

[0208] In practical applications, for a sample set with a known fault severity (historical fault data, also known as fault samples) After the degradation trend condition variable extraction module, feature data carrying fault information is calculated for each sample. Then, each historical fault data is compared with its respective... The fault sample pairs are combined to form the training dataset. ,in k were extracted by different methods The conditional variable composed of the values ​​(second degenerate characteristic). .

[0209] During the model training phase, forward propagation is first performed using fault samples generated in the data preparation phase to calculate the generated samples, interpolated samples, and the discrimination results of the discriminator network. The discriminator network's loss is calculated based on its discrimination results for fault samples and generated samples. The generator network's loss is calculated based on its discrimination results for generated samples. The conditional mutual information maximization loss between the generator network and the Q network is calculated based on the reconstruction result of the degradation trend conditional variable contained in the generated samples by the degradation feature reconstruction network Q (i.e., the first degradation feature). Based on these loss terms, the discriminator network, generator network, and Q network are sequentially optimized and updated until the loss converges, completing the model training and obtaining the trained sample generation model.

[0210] Specifically, after generating fault samples, the fault samples are input into the generator network for processing to obtain generated samples under the control of condition variable c. .

[0211] Let the generator (denoising network) be The input is The output is a prediction of the noise:

[0212] Depend on An estimate of the original sample can be obtained:

[0213] Then, linear interpolation is performed on the fault samples and the generated samples to obtain the interpolated samples. ,in, , is a random number that is uniformly distributed between 0 and 1.

[0214] Next, the fault samples, generated samples, and interpolated samples are input into the discriminator network for processing to generate corresponding discrimination results. Based on the first discrimination result corresponding to the fault sample, the second discrimination result corresponding to the generated sample, and the interpolated sample, the first loss value corresponding to the discriminator network is calculated; based on the second discrimination result corresponding to the generated sample, the second loss value of the generator network is calculated.

[0215] The first loss value of the discriminator network is calculated as follows:

[0216] The second loss value of the generator network is calculated as follows:

[0217] For fault sample generation tasks that include conditional information, the more information about the input conditional variables the generated fault samples contain, the better; that is, the degradation information contained in the input conditional variables should be preserved to the greatest extent possible in the generated samples. Mutual information can measure the degree of dependence between two random variables:

[0218] Therefore, consider using the mutual information between the input condition variables and the generated samples. This is used to measure the degree of preservation of degraded information and is defined as conditional mutual information. Therefore, in addition to the loss values ​​of the generator and discriminator networks, it is necessary to optimize this conditional mutual information to its maximum during training. However, directly... Performing the calculations is very difficult, so an auxiliary distribution is constructed. This provides a lower bound for conditional mutual information: At this point, the objective of maximizing conditional mutual information is to maximize... At this point, a network Q is constructed to predict the mean and standard deviation of the condition variable. Assuming the condition variable follows a normal distribution, for a mean of... Standard deviation is For a random variable, its probability density function is:

[0219] To calculate Part 1 It means to calculate ,Right now Assume the mean and standard deviation of the condition variable output by network Q are respectively... and The objective of maximizing conditional mutual information can be written as:

[0220] Since the distribution of the condition variable c is fixed, Equivalent to:

[0221] If not considered The impact of this further optimizes the target. Equivalent to:

[0222] Therefore, the output of network Q is a vector with the same dimension as the condition variable c.

[0223] In actual training, besides calculating the loss values ​​of the generator and discriminator networks in the Conditional Temporal Deep Generative Adversarial Network (CTGAN) module, the generated samples can also be input into the degradation feature reconstruction network. The degradation feature reconstruction network reconstructs the degradation features of the generated samples to generate the first degradation feature. Based on the first degradation feature, the conditional mutual information maximization loss value between the generator network and the degradation feature reconstruction network is calculated. The specific processing method is as follows: Introducing degradation trends to rebuild networks This allows the degenerate semantics of the generated samples to revert to the condition variable:

[0224] Additionally, diffusion uniformity can be calculated using standard noise to predict MSE:

[0225] After calculating the aforementioned loss value, we can obtain: Total loss of generator (denoising network):

[0226] Reconstructing network loss (can be shared with generator) ):

[0227] Discriminator loss is .

[0228] Based on this, the model parameters of the sample generation model to be trained are adjusted according to each loss value to obtain the trained sample generation model. Specifically, according to... , , The generator network, discriminator network, and degradation trend reconstruction network are trained separately to obtain the trained sample generation model G. .

[0229] Then, the fault data and target condition variables can be input into the trained sample generation model, and the generator network can process the fault data and target condition variables to generate the corresponding second intermediate samples.

[0230] In one optional implementation, the step of extracting fault modes that meet the consistency index from each fault mode to obtain a set of fault modes to be verified includes: Divide each fault mode into sets to generate at least two initial fault mode sets; Determine the hierarchical fault data corresponding to each fault mode in the target initial fault mode set, wherein each hierarchical fault data consists of fault modes at different levels, and the target initial fault mode set is each of the at least two initial fault mode sets; A judgment matrix is ​​constructed based on the hierarchical fault data, and the fault modes that meet the consistency index in each fault mode contained in the hierarchical fault data are extracted according to the judgment matrix to obtain a set of fault modes to be verified.

[0231] Furthermore, the step of extracting fault modes that meet the consistency index from each fault mode included in the hierarchical fault data according to the judgment matrix to obtain a set of fault modes to be verified includes: Solve the characteristic equation constructed based on the judgment matrix and the identity matrix to obtain the maximum eigenvalue of the judgment matrix; The consistency index value is determined based on the maximum eigenvalue, and the consistency ratio is calculated based on the index value. If the consistency ratio is determined to meet the condition, a set of failure modes to be verified is constructed based on the failure modes associated with the judgment matrix.

[0232] Specifically, due to the complex and uncertain relationships among the various characteristics of the evaluation indicators, these indicators may be incomparable, and each indicator may have a different degree of influence on the evaluation results. Therefore, the Analytic Hierarchy Process (AHP) is introduced to analyze the fault sample set and fault mode set, thereby obtaining the target sample.

[0233] In the embodiments of this specification, each fault mode is first divided into sets to generate at least two initial fault mode sets, that is, at least two replaceable units are generated.

[0234] Targeting the replaceable units of the fault mode set, where K is the number of replaceable units, and each replaceable unit U i By N i It consists of several failure modes.

[0235] Assuming replaceable unit U i The failure mode set is , For the fault mode set F i The corresponding hierarchical fault data. Hierarchical fault data refers to data that organizes and classifies fault modes according to a certain hierarchical structure. For example, fault modes can be divided into broad categories such as "functional faults," "hardware faults," and "software faults," and then further subdivided within each category. Specifically, all fault modes that may affect the unit can be identified through historical data, expert knowledge, fault reports, and system analysis, thus forming the hierarchical fault data corresponding to the unit's fault mode set.

[0236] Furthermore, after determining the hierarchical fault data corresponding to the fault mode set, the specific implementation process of the fault mode random extraction algorithm based on hierarchical analysis is as follows: Step 1: Construct the judgment matrix.

[0237] Statistical sets The number of fault modes k i and this k i Each failure mode is extracted and combined into a set. and order Construct a judgment matrix.

[0238] Where P is the judgment matrix. These are the eigenvalues ​​of the matrix.

[0239] The judgment matrix P is composed as follows: The goal is to identify failure modes that meet consistency metrics within a set of failure modes. , ( ) represents each fault mode in the fault mode set. express for The relative importance values. Then the judgment matrix P can be written as:

[0240] In the established indicator system, indicators (failure modes) at the same level are comparable. However, within the same level, each indicator has a different weight. Considering attributes such as experimental risk, accuracy, and confidence level, the 1-9 scaling method shown in Table 1 is used to measure the relative merits of the judgment objects when constructing the judgment matrix. This scaling method is simple, clear, and easy to use.

[0241] Table 1 Scale Description

[0242] Step 2: Solve the characteristic equation.

[0243] In the Analytic Hierarchy Process (AHP), the decision matrix P is used to represent the relative importance of each factor (failure mode). The eigenvector corresponding to the largest eigenvalue (eigenvalue) of the decision matrix P is obtained by solving the characteristic equation det(P-λI)=0, where I is the identity matrix.

[0244] Step 3: Perform a consistency check.

[0245] Specifically, the largest eigenvalue (eigenvalue) of the judgment matrix P is usually used for consistency testing. The consistency index can be determined based on the largest eigenvalue, and the consistency ratio can be calculated based on the index value. If the largest eigenvalue is close to the order n of the matrix (i.e., λmax≈n), the consistency of the judgment matrix is ​​considered to be good.

[0246] The test formula is as follows:

[0247]

[0248] In the formula, CR is the consistency ratio of the judgment matrix; CI is the general consistency index of the judgment matrix; and RI is the average random consistency index of the judgment matrix. The RI values ​​of judgment matrices of order 1 to 9 are shown in the table.

[0249] Table 2. Values ​​of the average random consistency index RI

[0250] When the CR of the judgment matrix P is less than 0.1 or When CI=0, P is considered to have satisfactory consistency; otherwise, the elements in P need to be adjusted to ensure satisfactory consistency.

[0251] Given that the consistency ratio meets the condition, a set of failure modes to be verified is constructed based on the failure modes associated with the judgment matrix. Specifically, failure modes that meet the consistency index are extracted from the failure mode set to construct the set of failure modes to be verified, F. Fi .

[0252] In one optional implementation, after obtaining the set of fault modes to be verified, the method further includes: Determine the weight corresponding to each fault mode in the set of fault modes to be verified; The fault modes in the set of fault modes to be verified are sorted according to the weights, and the target fault modes are filtered according to the sorting results. Accordingly, determining the sample to be verified corresponding to each fault mode in the set of fault modes to be verified includes: Identify the sample to be verified corresponding to the target fault mode in the set of fault modes to be verified.

[0253] Furthermore, the sufficiency test of the sample to be verified includes: The sample to be verified is split to generate at least two sample sets; Obtain the mapping relationship between the failure modes related to the target project and the project parameter values ​​of the target project, and determine the equivalent set of failure modes corresponding to each sample set based on the mapping relationship; The sufficiency measure of the corresponding sample set is determined based on the fault mode equivalence set.

[0254] Furthermore, determining the sufficiency metric of the corresponding sample set based on the fault mode equivalence set includes: Determine the number of fault modes included in the fault mode equivalence set; Determine the ratio between the number of failure modes and the total number of failure modes related to the target project, and use the ratio as a sufficiency measure of the sample set corresponding to the equivalent set of failure modes.

[0255] Specifically, after obtaining the set of failure modes to be verified, the weight corresponding to each failure mode in the set of failure modes to be verified can be determined, and the target samples related to the target project can be determined based on the weights.

[0256] In the Analytic Hierarchy Process (AHP), the relative weight of each factor (failure mode) can be calculated using the judgment matrix, thereby ranking their importance. Specifically, the eigenvector corresponding to the largest eigenvalue can be normalized, and the result can be used as the relative weight of each factor to rank their importance, i.e., weight allocation.

[0257] In the embodiments of this specification, indicators (failure modes) at the same level are comparable, but each indicator at the same level has a different weight. Furthermore, these indicators include both positive ("high-potential") and negative ("low-potential") indicators. Indicators with high potential include: minimum sample size requirement, critical function failure coverage, functional failure coverage, test activation rate, testability rate, test utilization rate, injection cost consumption rate (by default, costs are incurred whenever a fault injection test is conducted), fault injection rate, time-domain clustering Gini coefficient, frequency-domain uniform KL divergence, and statistical domain feature density coefficient of variation. Indicators with low potential include: fault undiagnostic rate, severe fault coverage, and injection hazard rate. Moreover, considering the test costs and the number of fault modes allocated, the unit fault allocation rate and complex unit allocation rate are mutually restrictive with the injected fault consumption rate. Therefore, as long as the required number of fault samples is met, these are also set as positive indicators in the embodiments of this specification. To make the analytic hierarchy process (AHP) better applicable to sample sampling, the inverse indicators in this specification are all reversed in the embodiments. That is, a reference value is set for each inverse indicator, which is equal to 1 minus the actual true value.

[0258] The sample imbalance index for multi-domain fault detection and diagnosis is defined as follows: 1) In the time domain, extract features including but not limited to the following: mean, variance, RMS, peak value, peak-to-peak value, skewness, kurtosis, waveform factor, impulse factor, margin factor, zero-crossing rate, and rise / fall time; based on the extracted time domain features, use the K-means algorithm to perform clustering and calculate the sample proportion of each cluster. ; Calculate the time-domain clustering Gini coefficient:

[0259] 2) In the frequency domain, for the Fourier-Bessel domain spectrum of the signal The following method is used to determine the local maxima in the spectrum. Frequency band boundary Assume the number of local maxima found is ,but: At that time, keep the previous one The maximum points are used as the frequency band boundaries; When resetting parameters ,make

[0260] For each sample, calculate the energy proportion of each frequency band, and take the dominant frequency band (the band with the highest energy) as its frequency domain category. Statistically calculate the proportion of samples in each category. .

[0261] Calculate the uniform KL divergence in the frequency domain:

[0262] 3) Within the statistical domain, extract statistical features including, but not limited to, the following: higher-order moment statistics such as 3rd-order skewness and 4th-order kurtosis, autocorrelation function decay rate, and information entropy. Calculate the local kernel density of the sample points within the statistical domain formed by these statistical features:

[0263] in, For bandwidth parameters, The number of statistical features. The total number of samples, For the first A vector formed by the statistical characteristics of each sample.

[0264] Calculate the coefficient of variation of the characteristic density in the statistical domain:

[0265] Once a unified set of judgment indicators for decision-making is established, the weights of the analytic hierarchy process (AHP) can be determined. Methods for calculating the AHP weight vector W include the geometric mean, arithmetic mean, eigenvector method, and least squares method, which will be introduced one by one below.

[0266] 1) Geometric mean method.

[0267]

[0268] The relevant calculation steps are as follows: a) Multiply the elements of the judgment matrix P by row to obtain a new vector; b) Calculate the nth root of each component of the new vector; c) Normalize the resulting vector into a weight vector.

[0269] 2) Arithmetic mean method.

[0270] Since each column in the judgment matrix P approximately reflects the distribution of weights, the weight vector is estimated by using the arithmetic mean of all column vectors, resulting in:

[0271] The relevant calculation steps are as follows: a) Obtain the results by normalizing the elements of the judgment matrix P column by column. ; b) Add the normalized columns together; c) Divide the summed vector by n to obtain the weight vector.

[0272] 3) Eigenvector method Multiply the judgment matrix P by the weight vector W on the right, as shown in the following formula:

[0273] In the formula, To determine the largest eigenvalue of matrix P, it must exist and be unique. All components of W are positive components.

[0274] Then, the obtained weight vector is normalized to obtain the desired result.

[0275] 4) Least squares method The weight vector is determined using a fitting method to minimize the sum of squared residuals for each term. The solution is as follows:

[0276]

[0277] Once the consistency check and weight determination of the fault mode set are completed, a better fault sample set can be determined based on the weight distribution of the hierarchical analysis.

[0278] Specifically, after sorting each fault mode in the set of fault modes to be verified in descending order of weight, a certain number of fault modes at the top of the sorting can be identified as target fault modes, and the corresponding samples to be verified can be identified. Then, a sufficiency test is performed on the samples to be verified. If the test passes, the samples to be verified are identified as target samples related to the target project.

[0279] In addition, after completing the consistency check of the judgment matrix and obtaining the weight vectors corresponding to each fault mode... Subsequently, to improve the randomness and representativeness of fault sample sampling, this embodiment of the specification introduces a weight-guided random sampling strategy while maintaining the weight calculation and consistency check process of the analytic hierarchy process (AHP). Specifically, the weight vector obtained by the AHP is... Normalization is performed, and the result is used as the probability distribution for the extraction of fault modes:

[0280] After determining the replaceable unit The number of fault modes to be extracted is Under the premise of probability distribution Using random sampling without replacement, from the failure mode set Randomly selected Each failure mode constitutes a failure sample set for this unit.

[0281] This method ensures that high-weighted fault modes have a high sampling probability while allowing medium- and low-weighted fault modes that meet consistency requirements to still be selected in multiple sampling processes, thereby improving the statistical diversity and coverage integrity of the fault sample set. By repeatedly executing the weighted random sampling process, the fault sample set used in the test validation experiment is finally determined, denoted as […]. .

[0282] In addition, the intermediate samples are sampled according to the preset sample size to generate at least two sample sets. Specifically, the intermediate samples and the intermediate samples to be screened are sampled according to the preset sample size to generate at least two sample sets.

[0283] After generating at least two sample sets, the sufficiency of the sample parameters of the target project contained in each sample set can be checked. If the check passes, the sample is identified as a target sample related to the target project. This target sample can be used for fault detection and diagnosis of the target project.

[0284] Because constructing imbalanced samples may disrupt the original sample set's coverage of fault conditions, the generated samples need to be sufficiency tested to ensure they can cover all possible fault conditions.

[0285] For test validation experiments, the sample size is fixed and the sample set is generated by sampling. Therefore, it is necessary to measure the sufficiency of the generated fault detection and diagnosis sample set and select the optimal sample set for subsequent experiments.

[0286] The sufficiency of validation samples for data-driven fault detection and diagnosis models is categorized into two types: fault distribution coverage sufficiency measures and data distribution coverage sufficiency measures. Fault distribution coverage sufficiency measures include fault importance coverage sufficiency measures and fault occurrence probability coverage sufficiency measures. Data distribution coverage sufficiency measures include time-domain feature distribution coverage sufficiency measures, frequency-domain feature distribution coverage sufficiency measures, statistical domain feature distribution coverage sufficiency measures, and comprehensive data distribution coverage sufficiency measures.

[0287] For measuring the adequacy of fault importance coverage, firstly, considering that fault importance is usually represented by ordered discrete levels, and the difference between adjacent levels is much smaller than the difference across levels, the absolute difference is used as the point-to-point distance in local matching to accurately reflect the inherent hierarchical relationship of fault importance. Secondly, to address inconsistencies between two sequences in terms of time scale or event density, Dynamic Time Warping (DTW) is used for flexible alignment. DTW constructs an optimal nonlinear mapping path, allowing sequences to be moderately stretched or compressed on the time axis, thereby capturing potential similar evolution patterns and avoiding the underestimation of similarity due to small offsets.

[0288] By dividing the cumulative distance of DTW by the actual alignment path length instead of directly using it, the average point-by-point difference can be obtained. This operation effectively isolates the influence of sequence length on the similarity score, thus achieving a fair assessment of coverage adequacy. Furthermore, by dividing this average difference by the theoretical maximum span of the fault importance level for normalization, the final similarity can be defined as:

[0289] in, The DTW average of fault importance between the overall population and the final generated sample set. The highest fault importance in the overall fault sample population. It represents the minimum fault importance in the overall fault sample population.

[0290] The range of values ​​for fault importance coverage adequacy is [0,1]. The closer the value is to 1, the more representative the sample is of the population in terms of fault importance, and the more adequate the coverage of critical faults. Conversely, there may be a risk of missing high-importance faults.

[0291] For the adequacy measure of fault occurrence probability coverage, this embodiment first uses DTW (Dynamic Data Wave) to flexibly align two probability sequences of unequal lengths to tolerate asynchrony caused by differences in modeling granularity or sampling frequency. Then, the mean absolute error (MAE) on the optimal alignment path is calculated and normalized relative to the maximum possible deviation in the probability space to form the adequacy measure of fault occurrence probability coverage. This measure not only effectively captures the overall trend consistency and local peak matching degree of the probability distribution, but also significantly reduces the interference of sequence length on the evaluation results by using average error instead of cumulative error, thus fairly reflecting the completeness and adequacy of the sample set's coverage of the baseline fault occurrence probability pattern. The closer the measure is to 1, the higher the fault probability distribution of the sample set is to the overall distribution, indicating sufficient coverage. Conversely, a lower measure indicates problems such as systematic underestimation, omission of high-risk faults, or false alarms of low-risk events. The mathematical definition of fault occurrence probability coverage adequacy is:

[0292] in, The DTW average of the failure occurrence probability between the overall population and the final generated sample set. This represents the highest probability of failure occurring in the overall failure sample population. It represents the minimum probability of failure in the overall failure sample population.

[0293] The time-domain feature distribution coverage adequacy measure is an index that quantifies the representativeness of a sampled signal subset to the overall distribution in a multi-dimensional time-domain feature space, with a value range of [0,1]. This method first extracts 10 time-domain features from each signal segment, including mean, variance, peak value, peak-to-peak value, skewness, kurtosis, waveform factor, impulse factor, margin factor, and zero-crossing rate. Then, each feature dimension is standardized to 0-1, and the empirical probability distributions of the population and subset are estimated separately, and their Jensen-Shannon (JS) distance is calculated. By normalizing the JS distance and inversely mapping it to a coverage score, the average of all dimensions is finally taken to obtain the comprehensive coverage adequacy measure. The index constructed by this method possesses good mathematical properties such as symmetry, boundedness, and sensitivity to distribution differences. The closer the value is to 1, the better the subset's coverage of the overall characteristics in the time-domain feature distribution. Its mathematical expression is:

[0294] in Features The JS distance can be calculated using the following formula:

[0295] For the first sample in the overall sample set The probability distribution of dimensional features This represents the probability distribution for extracting features from a subset. .

[0296] For a measure of the sufficiency of frequency domain feature distribution coverage, in the frequency domain, for the Fourier-Bessel domain spectrum of the signal... The following method is used to determine the local maxima in the spectrum. Frequency band boundary Assume the number of local maxima found is ,but: At that time, keep the previous one The maximum points are used as the frequency band boundaries; When resetting parameters ,make

[0297] For each sample, calculate the energy proportion of each frequency band, and take the dominant frequency band (the band with the highest energy) as its frequency domain category. Statistically analyze the frequency domain distribution of the sample proportions for each category. Based on the statistical results, the JS distance between the overall distribution and the fault sample set distribution is calculated. This is mapped to the sufficiency of frequency domain feature distribution coverage. Its mathematical expression is:

[0298] To measure the sufficiency of statistical domain feature distribution coverage, statistical features are first extracted from the statistical domain: higher-order moment statistics such as 3rd-order skewness and 4th-order kurtosis, autocorrelation function decay rate, and information entropy. Within the statistical domain formed by these statistical features, the JS distance between the overall distribution and the fault sample set distribution is calculated. This is mapped to the sufficiency of coverage of statistical domain feature distributions. Its mathematical representation is:

[0299] To comprehensively evaluate the representativeness of a subset of signals to the overall signal distribution across different feature space dimensions, a comprehensive data distribution coverage adequacy measure is proposed. This measure integrates the distribution coverage of features in the time, frequency, and statistical domains, providing a unified quantitative standard to evaluate the statistical representativeness of a sampled signal set. Specifically, the comprehensive data distribution coverage adequacy measure combines key features extracted from each feature domain and constructs its own distribution coverage adequacy measure based on these features, ultimately obtaining a comprehensive score through arithmetic averaging. The mathematical expression is as follows:

[0300] In the embodiments of this specification, to perform sufficiency measurement on at least two generated sample sets, it is necessary to first obtain the mapping relationship between the failure modes related to the target project and the project parameter values ​​of the target project, and then determine the equivalent set of failure modes corresponding to each sample set based on the mapping relationship.

[0301] When determining the mapping relationship between failure modes and project parameter values, firstly, determine the mapping relationship based on the design data of the target project. The elements included are: a set of failure modes (FU), a set of characteristic (project parameter) values ​​(AU), and a mapping relationship (PU). Then, the equivalent set of failure modes for each sample set is determined based on the PU. In this context, "design documents" refers to the project specification of the target project. The failure mode set (FU), the characteristic value set (AU), and the mapping relationship (PU) are key elements for conducting sample sufficiency testing. FU refers to the set of all possible failure modes the target project may encounter. AU refers to the set of all possible values ​​for the product characteristics, i.e., the project parameters of the target project. These characteristics may include performance parameters, environmental conditions, operating conditions, etc. PU refers to the mapping relationship between the failure modes in the failure mode set FU and the characteristic values ​​in the characteristic value set AU. It describes how a specific failure mode is caused by a specific characteristic value. PU is the bridge connecting failure modes and characteristic values; through it, we can understand which characteristic changes may lead to which failure modes. The failure mode equivalence set refers to different failure modes that lead to the same failure performance under specific conditions. These failure modes are considered equivalent in analysis and testing, and their impact on the system is similar.

[0302] Based on this, after obtaining the mapping relationship PU between failure modes and project parameter values, since it directly relates failure modes and project parameter values, the equivalent set of failure modes corresponding to each sample set is determined according to the mapping relationship. Specifically, the mapping relationship PU can be analyzed in detail to understand how different project parameter values ​​affect different failure modes, identify which failure modes will lead to the same system effect under specific conditions, and determine the equivalent set of failure modes corresponding to each sample set based on the result. This equivalent set of failure modes contains information such as the corresponding failure mode description, characteristic values, and system impact.

[0303] To address the practical engineering challenges of "limited sample set, complex failure modes, and multidimensional coverage" in test validation experiments, this specification's embodiments introduce a multi-index joint evaluation and statistical confidence constraint mechanism on the basis of the original sample sufficiency measurement and optimization process, forming a sample sufficiency testing method with stability constraints.

[0304] This method, without altering the original sample generation and sufficiency measurement calculation model, improves the reliability and engineering interpretability of the sample set optimization results by analyzing the statistical characteristics of the sufficiency measurement results. The specific implementation process is as follows: (1) Sample sufficiency test and selection.

[0305] 1) Determine the set of elements for the test object Determine the set of failure modes based on product design data. , characteristic value set and the mapping relationship between the two. And based on this, construct an equivalent set of product failure modes.

[0306] 2) Construct multiple sets of candidate fault sample sets Given a fixed sample size, a random sampling method that considers the failure rate distribution characteristics is used to generate multiple candidate failure sample sets:

[0307] 3) Calculate the multidimensional sufficiency measure index For each sample set, calculate one or more of the following sufficiency metrics: unit coverage sufficiency metric, functional coverage sufficiency metric, test coverage sufficiency metric, and comprehensive coverage sufficiency metric.

[0308] Record No. The sample set in the th case... The measurement results under each sufficiency indicator are as follows:

[0309] 4) Construct a multi-indicator joint sufficiency evaluation vector The results of various sufficiency measures are uniformly represented as a sufficiency vector of the sample set:

[0310] This vector can simultaneously reflect the sufficiency of the sample set under different coverage dimensions, avoiding the bias caused by a single indicator.

[0311] (2) Sample sufficiency optimization method based on statistical stability.

[0312] Given that the sample set is obtained through random sampling, its sufficiency measurement results exhibit random fluctuations. To improve the stability of the optimization results, this specification introduces a repeated sampling and statistical confidence constraint mechanism in its embodiments. The specific steps are as follows: 1) Statistical analysis of repeated sampling and sufficiency measurement For each candidate sample set By performing multiple independent samplings or rearrangements under the same sampling rules, the statistical distribution of its sufficiency measure is obtained, and its expected value is calculated:

[0313] If necessary, variance or confidence intervals can be calculated simultaneously to measure the stability of the sufficiency assessment of the sample set.

[0314] 2) Introducing a comprehensive sufficiency index with stability constraints Based on the existing sufficiency measure, a stability constraint is introduced to construct a comprehensive evaluation index for the sample set:

[0315] in, The weights of different sufficiency indicators can be determined by engineering experience or the aforementioned analytic hierarchy process.

[0316] 3) Sample set optimization rules From all candidate sample sets, select the sample set that satisfies the statistical stability requirement and has the largest comprehensive adequacy index:

[0317] When multiple sample sets When values ​​are similar, prioritize the sample set with smaller variance or better coverage balance.

[0318] (3) Final sample set analysis and remedial mechanism Sufficiency analysis and remedial suggestions: for the final selected sample set The adequacy measurement results are analyzed to identify weak coverage areas at the unit, functional, or test levels, providing a basis for subsequent permissible remedial measures (such as targeted resampling and critical fault annotation).

[0319] The purpose of performing a sufficiency test on the generated sample set is to check the fault conditions it can cover. Coverage is one of the most intuitive sufficiency measures, which measures the proportion of fault modes in the sample set that cover all possible fault modes.

[0320] Therefore, in the embodiments of this specification, the number of fault modes contained in each fault mode equivalence set can be determined first, and then the ratio between the number of each fault mode and the total number of fault modes related to the target project can be calculated, and this ratio can be determined as the sufficiency measure of the sample set corresponding to the fault mode equivalence set.

[0321] In one optional implementation, determining the target sample related to the target item from the sample to be verified based on the sufficiency test results includes: Determine the target sample set with the largest sufficiency metric value in each sample set, and identify the samples to be verified contained in the target sample set as target samples related to the target project.

[0322] Specifically, after determining the sufficiency measure of each sample set, the sample set containing the target sample set with the largest sufficiency measure in each sample set can be identified as the target sample related to the target project.

[0323] This embodiment of the specification filters initial samples stored in the database according to the project requirements of the target project to obtain first intermediate samples related to the target project. If the sample size of the first intermediate samples is insufficient, second intermediate samples are generated through interpolation. Fault modes corresponding to each first and second intermediate sample are determined, and fault modes that meet consistency indicators are extracted from each fault mode to obtain a set of fault modes to be verified. The samples to be verified corresponding to each fault mode in the set of fault modes to be verified are determined, and sufficiency checks are performed on the samples to be verified. Based on the sufficiency check results, target samples related to the target project are determined from the samples to be verified. By filtering samples according to the project requirements of different target projects to obtain qualified target samples, it is beneficial to ensure the accuracy and applicability of the generated samples, and also to ensure the accuracy of the detection results obtained through fault detection and diagnosis using the target samples.

[0324] Figure 6 A structural block diagram of a computing device 600 according to one embodiment of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0325] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0326] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0327] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 600 can also be a mobile or stationary server.

[0328] The processor 620 is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described fault detection, diagnosis and verification platform architecture design method for group products.

[0329] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the fault detection, diagnosis and verification platform architecture design method for group products described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the fault detection, diagnosis and verification platform architecture design method for group products described above.

[0330] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described fault detection, diagnosis, and verification platform architecture design method for group products.

[0331] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the fault detection, diagnosis, and verification platform architecture design method for group products described above. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the fault detection, diagnosis, and verification platform architecture design method for group products described above.

[0332] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described fault detection, diagnosis and verification platform architecture design method for group products.

[0333] The above is an illustrative example of a computer program in this embodiment. It should be noted that the technical solution of this computer program belongs to the same concept as the technical solution of the above-described fault detection, diagnosis, and verification platform architecture design method for group products. Details not described in detail in the computer program's technical solution can be found in the description of the above-described technical solution of the fault detection, diagnosis, and verification platform architecture design method for group products.

[0334] 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.

[0335] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0336] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0337] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0338] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A fault diagnosis and verification platform, comprising: The overall control system operation module is used to configure the verification task corresponding to the fault diagnosis model to be verified through the overall control system, and send the verification task to the sample generation module; The sample generation module is used to receive the verification task, generate a fault sample corresponding to the verification task, and send the fault sample to the model running module. The model running module is used to call the fault diagnosis model to be verified to process the fault sample and obtain the processing result output by the fault diagnosis model to be verified. The evaluation system operation module is used to receive the processing results through the evaluation system, and to verify and evaluate the processing results based on preset verification indicators, thereby generating corresponding verification and evaluation results.

2. The fault diagnosis verification platform according to claim 1 further includes: The model development module is used to develop different fault diagnosis models based on different algorithms, and send the developed fault diagnosis models to the model running module, wherein the fault diagnosis model to be verified is one of the developed fault diagnosis models.

3. The fault diagnosis and verification platform according to claim 1, wherein the central control system operation module is further configured to: The registration information of the equipment and fault diagnosis model in the operating module of the central control system is obtained through the central control system. The registration information includes the device name, device model and operating status of at least one device, and the registration information also includes the function, model name and verification indicators of at least one fault diagnosis model. Based on the registration information, a verification requirement is generated corresponding to the fault diagnosis model to be verified. The verification requirement includes the device type, operating conditions, number of samples, and data type of the samples of the target device. The target device is one of the at least one devices. Configure the verification task corresponding to the fault diagnosis model to be verified based on the verification requirements, wherein the fault diagnosis model to be verified is one of the at least one fault diagnosis models.

4. The fault diagnosis verification platform according to any one of claims 1 to 3, wherein the central control system operation module is further configured to: The system receives task execution phase information returned by the sample generation module and displays it through an interactive interface. Upon receiving a task status control instruction submitted by the user through the interactive interface, the task status control instruction is sent to the sample generation module.

5. The fault diagnosis verification platform according to claim 1 or 3, wherein the sample generation module is further configured to: The target devices that meet the conditions are determined based on the device type of the target devices included in the verification task; Based on a pre-determined correspondence between devices and sample files, the target sample file corresponding to the qualified target device is determined, wherein... The target sample file is used to store sample data of the target devices that meet the conditions; The target sample file is invoked, and the sample data contained in the target sample file is extracted according to the operating conditions of the target equipment, the number of samples, the data type of the samples, and the sampling method of the fault samples contained in the verification task to obtain the corresponding fault samples.

6. The fault diagnosis verification platform according to claim 1, wherein the sample generation module is further configured to: A sufficiency evaluation is performed on the fault samples, and corresponding evaluation results are generated; If, based on the evaluation results, it is determined that the faulty sample does not meet the preset sufficiency conditions, a corresponding prompt message is generated and displayed through the interactive interface of the sample generation module; and / or, The prompt message is sent to the central control system operation module.

7. The fault diagnosis verification platform according to claim 1, wherein the sample generation module is further configured to send the verification task to the model running module; The model running module is also used to receive the verification task, determine the resource occupancy ratio corresponding to the verification task based on the resource occupancy level of the verification task, and run non-verification tasks that meet the conditions according to the resource occupancy ratio.

8. The fault diagnosis verification platform according to claim 1, wherein the model running module is further configured to: Add at least one probe to the running program corresponding to the verification task; The hardware and software resource usage during the verification task is determined by executing at least one probe. The performance monitoring information during the execution of the verification task is obtained by statistically analyzing the hardware and software resource usage determined by each probe.

9. The fault diagnosis verification platform according to claim 1, wherein the evaluation system operation module is further configured to: Based on the verification requirements included in the verification task, determine the evaluation indicators used to verify and evaluate the fault diagnosis model to be verified. Calculate the index value corresponding to the evaluation index based on the processing result; The verification and evaluation results corresponding to the fault diagnosis model to be verified are obtained by analyzing the index values.

10. A fault detection, diagnosis, and verification platform architecture design method for group products, applied to a fault diagnosis and verification platform, wherein the fault diagnosis and verification platform includes a central control system operation module, a sample generation module, a model operation module, and an evaluation system operation module, the method comprising: The verification task corresponding to the fault diagnosis model to be verified is configured by the overall control system running in the overall control system operation module, and the verification task is sent to the sample generation module. The sample generation module receives the verification task, generates a fault sample corresponding to the verification task, and sends the fault sample to the model execution module. The model running module calls the fault diagnosis model to be verified to process the fault sample and obtains the processing result output by the fault diagnosis model to be verified. The evaluation system, which runs on the evaluation system operation module, receives the processing results and evaluates the processing results based on preset verification indicators, generating corresponding verification evaluation results.

Images