A production test line fault diagnosis method

Abstract

The application provides a production test line fault diagnosis method, and relates to the technical field of production line fault diagnosis. First, the test stage sequence, test items and test parameters of a product are set; a test process is executed based on the set test stage sequence, and an abnormal value is actively injected in the test result according to a preset fault type, the test result containing the abnormal value is recorded, and a corresponding fault type label is automatically marked for the unqualified product test result according to whether the test result is qualified; further, multi-dimensional feature data is extracted from the product test result; finally, a multi-classification model is trained by using the multi-dimensional feature data, and the trained model is used for fault diagnosis of a to-be-diagnosed production line and output of a fault type; the scheme solves the problems of scarcity of fault samples, high cost and low accuracy of manual labeling in the field of industrial diagnosis; combined with the multi-dimensional feature learning ability of the multi-classification model, the automation degree and diagnosis accuracy of production line fault root cause positioning are significantly improved.

Description

Technical Field

[0001] This invention relates to the technical field of production line fault diagnosis, and more specifically, to a method for diagnosing faults in a production testing line. Background Technology

[0002] In the manufacturing process of electronic products, automated product testing lines are a core component in ensuring product quality. During testing, products typically undergo multiple consecutive testing phases, including voltage, current, temperature, and efficiency tests, each containing several specific test items. Current testing systems primarily determine product quality by comparing real-time measured values ​​with preset upper and lower threshold values.

[0003] When non-conforming test results occur, production line engineers must conduct a root cause analysis to trace the reasons for the non-conformity. In actual production environments, the causes of non-conformity are usually diverse, mainly including: design or process defects in the product itself, varying degrees of aging or damage to the test trays, and sensor or circuit failures in the test platform. Currently, this root cause analysis heavily relies on the past experience of engineers to set judgment rules. However, due to the complex and variable conditions of production lines, rule bases often cannot cover all failure scenarios, and the maintenance and updating of rules are extremely costly and inflexible. Based on this, in recent years, academia and industry have begun to explore diagnostic solutions based on machine learning. By collecting time-series sensor signal data, a time-series fault signal dataset is constructed, and then multi-stage transfer learning is used to achieve high-precision and interpretable production line fault classification. Existing solutions can enhance the model's ability to identify faults at different time scales and improve the diagnostic accuracy of complex fault modes, but the learning focus is on static or short-term signal fluctuations, which relies heavily on existing fault label data and does not consider incorporating the aging and maintenance of vulnerable equipment as a feature dimension into the model. This severely limits the model's accuracy and generalization ability in the face of intermittent failures caused by equipment aging, due to the lack of business logic support. Summary of the Invention

[0004] To address the issues of existing production line fault diagnosis methods relying heavily on existing fault cause label data, having low generalization ability, and poor accuracy in identifying production line faults, this invention proposes a production test line fault diagnosis method. This method proactively generates training data with fault cause labels, performs supervised training based on the training data, accurately diagnoses the causes of production line faults, and improves the generalization ability of the production line fault diagnosis method by simulating the maintenance requirements of vulnerable parts as the number of uses increases.

[0005] To achieve the above-mentioned technical effects, the technical solution of the present invention is as follows: Firstly, this application proposes a method for diagnosing faults in a production testing line, comprising the following steps: Set the product's testing phase sequence, and set test items and test parameters for each testing phase; The product testing process is executed according to the set testing phase sequence. Anomalies are injected into the test results according to the preset fault types, and the test results, including the anomalies, are recorded. The preset fault types include product faults, product support component faults, and test platform faults. Based on the product test results, determine whether the product has failed the test in this test item. If the test result is unqualified, mark the product test result for that test item with the corresponding fault type label; if the test result is qualified, continue to execute the product test process. Obtain product test results and extract multidimensional feature data of the product test from the product test results; The multidimensional feature data is used to train a pre-set multi-classification model, and the trained multi-classification model is used to diagnose the production line faults to be diagnosed, and output the fault type.

[0006] In this technical solution, the product's testing phase sequence, test items, and test parameters are first set. The testing process is then executed based on the set testing phase sequence, and outliers are actively injected into the test results according to preset fault types. Test results containing outliers are recorded, and the corresponding fault type labels are automatically assigned to product test results that fail to meet the requirements. Furthermore, multi-dimensional feature data is extracted from the product test results. Finally, a multi-classification model is trained using the multi-dimensional feature data, and the trained model is used to diagnose faults in the production line to be diagnosed and output the fault type. This solution solves the problems of scarce fault samples, high cost and low accuracy of manual labeling in the industrial diagnostics field. Combined with the multi-dimensional feature learning capability of the multi-classification model, it significantly improves the automation level and diagnostic accuracy of production line fault root cause localization.

[0007] Preferably, the product testing phase sequence includes: a test preparation phase, a product performance testing phase, and a test exit phase performed sequentially. The product performance testing phase includes several test items. The test parameters for each test item include: the normal value range of the test result, the duration range of the test, and the usage threshold of the vulnerable parts on which the test item is based. The vulnerable parts include the product support and the vulnerable hardware of the test platform.

[0008] Preferably, the test items include the product's input voltage calibration value, auxiliary start-up current, and auxiliary start-up voltage; The step of injecting outlier values ​​into the corresponding test results according to the preset fault type includes: If the fault type is a product fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's input voltage calibration value. If the fault type is a product support component fault, then an abnormal value that deviates from the normal range of the test results will be injected into the product's auxiliary starting current test results. If the fault type is a test platform fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's auxiliary start-up voltage. If the fault type is normal and there is no fault, then a random value within the normal value range will be generated in the product's test results.

[0009] Preferably, the product testing process further includes maintaining the vulnerable parts based on the number of times the test item relies on the vulnerable parts, the process of which is as follows: When testing products using the aforementioned consumable parts, the cumulative number of times the consumable parts are used is increased and recorded; Determine whether the number of times a vulnerable part has been used has reached a preset threshold. If so, mark the corresponding vulnerable part as being in maintenance status and set a maintenance end time. In maintenance status, the vulnerable part cannot be used for testing. After maintenance, the cumulative number of uses is cleared and the vulnerable part is restored to normal status. If not, continue product testing according to the product testing process.

[0010] Preferably, if the product fails the test for the first time in the test item, a retest is performed based on a preset failure mode, and the process is as follows: Determine the type of the preset fault mode. If the fault mode is product fault and test platform fault, replace the test platform and product support, perform the same test item retest, record and judge the retest results. If the retest result is still unqualified, the test platform and product support will be replaced again, and the same test item will be retested a second time. If the retest result is qualified, record the retest result and continue to execute the product testing process; If the failure mode is pallet failure, replace the test platform and product support, perform the same test items again, record the retest results, and return to the original test platform and original product support for a second retest, and record the second retest results.

[0011] Preferably, the process of extracting multidimensional feature data of product testing from product test results is as follows: Obtain the original product test results, which include unstructured descriptive text, measured values ​​of each test item, test results characterizing whether the test item is qualified or not, classification features of the test process, and fault type labels. Remove unstructured descriptive text from the original test results; Convert the measured values ​​of each test item into a unified numerical type; The test results, which characterize whether a test item passes or fails, are mapped to Boolean logic values. The classification features of the test process are processed by one-hot encoding to generate sparse binary feature vectors; The fault type labels are mapped to integer features using an encoder; The Boolean logic values, numerically converted measurement values, sparse binary feature vectors, and integer features are combined to construct the feature matrix for training the multi-classification model.

[0012] Preferably, training a pre-set multi-classification model using the multi-dimensional feature data includes: Based on a preset partitioning ratio, the feature matrix input into the multi-classification model for training is divided into training dataset, validation dataset, and validation dataset. Set the objective function of the multi-classification model, input the training dataset into the classifier of the multi-classification model for iterative training, and evaluate the loss value using the validation dataset after each iteration. If the loss value exceeds a preset loss value threshold, training continues until the loss value does not exceed the preset loss value threshold. If the loss value does not exceed the preset loss value threshold, then the training is completed, and the model parameters of the current iteration are saved as the parameters of the trained multi-classification model.

[0013] Preferably, the process of using the trained multi-classification model to diagnose the production line fault to be diagnosed and outputting the fault type includes: Acquire real-time test records from the production line to be diagnosed, extract multi-dimensional feature data, and perform feature alignment and numerical normalization to construct the feature vector to be inferred. The feature vector to be reasoned is input into the trained multi-classification model to perform logical reasoning, and outputs the probability distribution vectors of the records to be diagnosed as normal, product failure, product support component failure and test platform failure, respectively. The fault category corresponding to the maximum value in the probability distribution vector is determined as the fault type of the current production line.

[0014] Secondly, this application also proposes a computer device, which includes a memory, a processor, and a computer program stored in the memory that can be run by the processor. The processor executes the computer program to implement a production test line fault diagnosis method.

[0015] Thirdly, this application also proposes a computer storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform a production test line fault diagnosis method.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention proposes a fault diagnosis method for production testing lines. First, it sets the product's testing phase sequence, test items, and test parameters. Based on the set testing phase sequence, the testing process is executed, and outliers are actively injected into the test results according to preset fault types. Test results containing outliers are recorded. Based on whether the test results are qualified, the corresponding fault type label is automatically assigned to the product test results for unqualified items. Further, multi-dimensional feature data is extracted from the product test results. Finally, a multi-classification model is trained using the multi-dimensional feature data, and the trained model is used to diagnose faults in the production line to be diagnosed and output the fault type. This solution solves the problems of scarce fault samples, high cost and low accuracy of manual labeling in the industrial diagnostic field. Combined with the multi-dimensional feature learning capability of the multi-classification model, it significantly improves the automation level and diagnostic accuracy of production line fault root cause localization. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the production testing line fault diagnosis method proposed in Embodiment 1 of the present invention; Figure 2 This is another flowchart illustrating the production testing line fault diagnosis method proposed in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of the computer device proposed in Embodiment 3 of the present invention. Detailed Implementation

[0018] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent. To better illustrate this embodiment, some parts of the accompanying drawings may be omitted, enlarged, or reduced, and do not represent the actual dimensions; It is understandable to those skilled in the art that some well-known details may be omitted from the accompanying drawings.

[0019] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0020] The positional relationships depicted in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent. Example 1 This embodiment proposes a fault diagnosis method for a production testing line. A flowchart illustrating this method can be found here. Figure 1 This includes the following steps: S1. Set the product's test phase sequence, and set test items and test parameters for each test phase; S2. Execute the product testing process according to the set test phase sequence, inject outliers into the test results according to the preset fault types, and record the test results including the outliers; the preset fault types include product faults, product support component faults, and test platform faults; S3. Based on the product test results, determine whether the product has failed the test in this test item. If the test result is unqualified, label the product test result for this test item with the corresponding fault type label; if the test result is qualified, continue to execute the product test process. S4. Obtain product test results and extract multidimensional feature data of the product test from the product test results; S5. Use the multidimensional feature data to train a pre-set multi-classification model, and use the trained multi-classification model to diagnose the production line fault to be diagnosed, and output the fault type.

[0021] In this embodiment, the product's testing phase sequence, test items, and test parameters are first set. The testing process is executed based on the set testing phase sequence, and outliers are actively injected into the test results according to preset fault types. Test results containing outliers are recorded. Based on whether the test results are qualified, the corresponding fault type label is automatically assigned to the product test results for unqualified items. Multidimensional feature data is further extracted from the product test results. Finally, a multi-classification model is trained using the multi-dimensional feature data, and the trained model is used to diagnose faults in the production line to be diagnosed and output the fault type. This solution solves the problems of scarce fault samples, high cost and low accuracy of manual labeling in the industrial diagnostic field. Combined with the multi-dimensional feature learning capability of the multi-classification model, it significantly improves the automation level and diagnostic accuracy of production line fault root cause localization.

[0022] Example 2 In this embodiment, the product testing phase sequence includes: a test preparation phase, a product performance testing phase, and a test exit phase performed sequentially. The product performance testing phase includes several test items. The test parameters for each test item include: the normal value range of the test result, the duration range of the test, and the usage threshold of the vulnerable parts on which the test item is based. The vulnerable parts include the product support and the vulnerable hardware of the test platform.

[0023] Specifically, the product performance testing phase includes a voltage testing phase, a temperature testing phase, a current testing phase, and an efficiency testing phase; the test items include the product's input voltage calibration value, auxiliary starting current, and auxiliary starting voltage; the product support is a test tray; the vulnerable parts of the test tray and test platform include test sensors, test pins, and other test circuits.

[0024] Specifically, the production line fault diagnosis method proposed in this application can be applied to automated production test lines for electronic products such as power modules, inverters, and controllers. It simulates the testing process, generates tagged test data, and automatically identifies fault types based on test records. It can be deployed in a Manufacturing Execution System (MES) or independent test data analysis software.

[0025] Specifically, the product's test phase sequence simulates the actual production test cycle. In the test preparation phase, the equipment is initialized and reset, and in the voltage test phase, the auxiliary start-up voltage and input voltage calibration value of the product under test are measured. The auxiliary startup voltage refers to the output voltage value of the auxiliary power supply used to drive the internal control circuits, drive circuits, and sensors of the product before the main power supply starts or operates normally. The auxiliary startup voltage is highly dependent on the test platform during testing. If this value is abnormal during testing, this method tends to assume that there is a fault or accuracy drift in the measuring instruments, power supply bus, or voltage acquisition module inside the test equipment, rather than a problem with the tray or the product itself. In this embodiment, the normal range of the auxiliary startup voltage is 11.8~12.2V.

[0026] The input voltage calibration value characterizes the sampling accuracy of the internal voltage sampling of the product under test relative to the reference voltage. If the input voltage calibration value is abnormal during testing, this method tends to assume that the product itself is faulty. In this embodiment, the normal range of the input voltage calibration value is 360~400V.

[0027] The auxiliary startup current refers to the current magnitude on the auxiliary power supply output path of the product at the moment of main circuit startup or in standby mode. Testing the auxiliary startup current is highly dependent on the product support, as current transmission is extremely dependent on the contact resistance between the probes on the support and the test points on the product. If the probes on the support are worn, oxidized, or have weakened elasticity, the contact resistance will increase, causing abnormal fluctuations or significant drops in the collected current value. The normal range for the calibrated auxiliary startup current is 0.1~0.7A.

[0028] Specifically, the duration of the test is 10 ± 1 seconds, and the threshold number of times the vulnerable parts on which the test item is based includes the auxiliary starting current test item on the tray, which requires maintenance after 100 uses.

[0029] Specifically, after determining the product's testing phase sequence, test items, and test parameters, the process also includes generating one or more task orders, each containing a fixed number of 50 products. Test platforms and product supports are randomly selected from the platform list and tray list, randomly assigned to each product and product support, and the test start time is determined, ensuring that the interval between two tests on the same platform is between 5 and 60 seconds.

[0030] In this embodiment, the preset fault types include product faults, product support component faults, and test platform faults; The step of injecting outlier values ​​into the corresponding test results according to the preset fault type includes: If the fault type is a product fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's input voltage calibration value. If the fault type is a product support component fault, then an abnormal value that deviates from the normal range of the test results will be injected into the product's auxiliary starting current test results. If the fault type is a test platform fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's auxiliary start-up voltage. If the fault type is normal and there is no fault, then a random value within the normal value range will be generated in the product's test results.

[0031] Specifically, when the preset fault type is product fault, when generating the test result, based on the preset normal value range of the input voltage calibration value, an abnormal value with significant deviation characteristics, such as 350V or 420V, is injected outside the normal value range; this simulates the sampling distortion caused by the internal voltage divider resistor of the product due to resistance value offset or poor soldering.

[0032] Specifically, when the preset fault type is product support component failure, when generating the test result, based on the preset normal value range of auxiliary starting current, an abnormal value with significant deviation characteristics, such as 0.02A, is injected outside the normal value range; this simulates the weak current generated by poor contact of the simulated probe; at the same time, the abnormal value is spatiotemporally correlated with the cumulative number of uses of the current product support component to simulate the failure trajectory caused by hardware wear and tear.

[0033] Specifically, when the preset fault type is test platform fault, when generating the test result, based on the preset normal value range of auxiliary start voltage, an abnormal value that deviates significantly from the characteristics, such as 0V, is injected outside the normal value range; this simulates damage to the test platform power module, and this injection method can simulate false faults caused by instrument drift.

[0034] Specifically, to establish a baseline control group, when the preset fault type is normal, the system generates random values ​​within the normal value range corresponding to each test item using a random number generator. For example, the input voltage calibration value is generated as 380.2V, the auxiliary starting current as 0.52A, and the auxiliary starting voltage as 12.01V. These data represent the operating performance of the production line under ideal and controlled conditions, serving as the basis for the multi-classification model to identify fault-free modes.

[0035] Specifically, during the product testing process, the measured value, binary result, normal value range, fault type, and the number of times each vulnerable component on the pallet and platform has been used at the current moment are recorded for each test item. The binary result includes pass (PASS) and fail (FAIL). If a test item results in a fail (FAIL) result, the remaining test items in the current stage are skipped, and the test exit stage is entered directly. A corresponding outlier is generated in the exit stage to ensure the overall test result is fail (FAIL). The fault types include: normal, product_issue, pallet_issue, and platform_issue. The tags are consistent with the fault injection logic and are used for subsequent supervised learning.

[0036] In this embodiment, the product testing process also includes maintaining the vulnerable parts based on the number of times the test item relies on the vulnerable parts. The process is as follows: When testing products using the aforementioned consumable parts, the cumulative number of times the consumable parts are used is increased and recorded; Determine whether the number of times a vulnerable part has been used has reached a preset threshold. If so, mark the corresponding vulnerable part as being in maintenance status and set a maintenance end time. In maintenance status, the vulnerable part cannot be used for testing. After maintenance, the cumulative number of uses is cleared and the vulnerable part is restored to normal status. If not, continue product testing according to the product testing process.

[0037] Specifically, this embodiment introduces a dynamic maintenance scheduling algorithm to simulate the impact of hardware wear and tear on production cycle time and data distribution in a real production line. Whenever a test item is assigned to a specific product support or test platform for execution, the background counter of that resource is automatically retrieved, and the cumulative usage count is incremented. During recording, not only is the current count value recorded, but this count value is also strongly bound to the corresponding current and voltage test results as a set of state characteristics and stored in the original database.

[0038] After each count increment, a threshold determination logic is immediately executed, comparing the current cumulative usage count with a preset threshold (set to 100 times in this embodiment). If the count reaches 100 times, the status of the tray or platform is immediately changed from "idle" to "maintenance." During the maintenance state, the scheduling algorithm automatically masks the resource to ensure it cannot be invoked by subsequent test tasks. This step simulates the downtime for maintenance caused by probe replacement or equipment calibration in a real production line.

[0039] To ensure the logical consistency of the timeline in the simulated dataset, a time dimension is also set for maintenance actions. Based on the preset maintenance time, simulating a probe replacement taking 10 minutes, the "maintenance end time" is calculated and set. Once the system clock reaches the maintenance end time, the cumulative usage count of the vulnerable component will be automatically reset to zero, and its health status bit will be restored to "idle," allowing it to re-enter the resource pool for test scheduling.

[0040] In this embodiment, if the product fails the test for the first time in the test item, a retest is performed based on a preset failure mode. The process is as follows: Determine the type of the preset fault mode. If the fault mode is product fault and test platform fault, replace the test platform and product support, perform the same test item retest, record and judge the retest results. If the retest result is still unqualified, the test platform and product support will be replaced again, and the same test item will be retested a second time. If the retest result is qualified, record the retest result and continue to execute the product testing process; If the failure mode is pallet failure, replace the test platform and product support, perform the same test items again, record the retest results, and return to the original test platform and original product support for a second retest, and record the second retest results.

[0041] Specifically, when a product fails any test, this method does not immediately determine the product's final state. Instead, it executes a differentiated retesting strategy based on the currently recorded failure mode type. The specific process includes: First, read the fault mode tag associated with the product when the test failed. The fault mode tag includes at least three types: product fault (product_issue), test platform fault (platform_issue), and product support component fault (pallet_issue).

[0042] If the current failure mode is determined to be a product failure or a test platform failure, execute the following retesting process: The testing resources for this product were reallocated. Specifically, a different testing platform was selected from the available resource pool, and a different product support was selected. This replacement of the testing platform and product support aimed to eliminate misjudgments of the product's condition caused by occasional malfunctions of a single device.

[0043] After a preset first waiting period (e.g., a random duration between 4 and 10 minutes), the product is subjected to the first retest of the same test items using the reassigned test platform and product support, and the measured values ​​and test results of this retest are recorded.

[0044] The system evaluates the results of the first retest. If the first retest result is pass (PASS), the system archives the retest record and considers the product to have passed the current test item, then continues with the subsequent testing procedures for that product. If the first retest result is still fail (FAIL), the test resources are changed again. That is, a different set of test platforms and product supports are selected, which are different from the current test platform and product supports.

[0045] After a preset second waiting period (e.g., a random duration between 4 and 10 minutes), the same test items are performed on the product a second time using the test platform and product support that were changed again in the first retest, and the measured values ​​and test results of this retest are recorded.

[0046] Judge the result of the second retest. If the result is qualified, continue to execute the subsequent testing process; if the result is still unqualified, the system can mark the product as a final unqualified product according to the preset rule of reaching the maximum number of retests, and terminate the subsequent testing process of the product, or transfer it to the manual re-judgment queue.

[0047] If the current failure mode is determined to be a product support component failure, perform the following retesting procedure to verify whether the failure is indeed caused by a specific product support component: The first retest was conducted with different resources. A different test platform and a different product support were assigned to the product than those used in the first test.

[0048] After a preset third waiting period (e.g., a random duration between 4 and 10 minutes), the same test items are performed on the product for the first time using the replaced test platform and product support. The measured values ​​and test results of this retest are recorded. In pallet failure mode, since the influence of the original problematic pallet has been eliminated, the expected result of this retest is pass.

[0049] Perform a second retest under the restored environment. After completing the first retest, after a very short interval (e.g., 1 to 2 seconds), the system reschedules the product to the original test platform used in the first test, and uses the original product support used in the first test to perform a second retest of the same test items on the product, and records the measurement values ​​and test results of the second retest.

[0050] In this case, due to potential faults in the original product's support components (such as contact aging), the second retest is expected to result in a failure (FAIL). By comparing the PASS result in the second retest with the FAIL result in the first retest, time-series data features with significant discriminative power are generated, thus providing crucial data support for subsequent multi-classification models to identify pallet fault types.

[0051] Each test record generated during all the above retesting processes is simultaneously labeled with the corresponding fault type according to its corresponding fault injection logic, to ensure that the generated dataset can fully support the training of supervised machine learning models.

[0052] In this embodiment, the process of extracting multidimensional feature data of product testing from product testing results is as follows: Obtain the original product test results, which include unstructured descriptive text, measured values ​​of each test item, test results characterizing whether the test item is qualified or not, classification features of the test process, and fault type labels. Remove unstructured descriptive text from the original test results; Convert the measured values ​​of each test item into a unified numerical type; The test results, which characterize whether a test item passes or fails, are mapped to Boolean logic values. The classification features of the test process are processed by one-hot encoding to generate sparse binary feature vectors; The fault type labels are mapped to integer features using an encoder; The Boolean logic values, numerically converted measurement values, sparse binary feature vectors, and integer features are combined to construct the feature matrix for training the multi-classification model.

[0053] Specifically, the multi-classification model can use the XGBoost model.

[0054] Specifically, the original test results also include a unique identifier column and unstructured descriptive text. The unique identifier column refers to fields that are unique globally, such as the product serial number PN and the test phase name R1_Testname. Although such fields can be used for traceability, they do not provide generalization feature information for model training and are considered noise input, so they are deleted. The descriptive text column refers to issue_details, which describes the details of the problem. Specifically, regular expression matching or a predefined field blacklist is used to remove the aforementioned descriptive text column containing free text comments and notes from the dataset.

[0055] The test results, representing whether the test item passes or fails, are represented in the original test results by the binary representation of "Pass" (PASS) and "Fail" (FAIL). In this embodiment, all result columns named with "Result" or a preset keyword are traversed, and their values ​​are checked. If the value is "PASS", it is mapped to a first Boolean logical value (e.g., Boolean value True); if the value is "FAIL", it is mapped to a second Boolean logical value (e.g., Boolean value False). For unexpected abnormal values ​​(such as null values ​​or garbled characters), a default logical value can be preset or marked as missing.

[0056] In this embodiment, a numeric type casting function is called for the measured value field of each test item. For normally recorded numeric strings (such as "12.5"), their floating-point values ​​are extracted; for specific placeholders indicating invalid tests or unexecuted states (such as the symbol " / ", the text "N / A", or an empty string), they are uniformly replaced with predefined missing value identifiers. Since the multi-class classification model has inherent sparsity awareness, these missing value identifiers can be automatically processed by the model during training without additional imputation.

[0057] The classification features are typically used to represent discrete, non-continuous variables, including task order number, test platform name, test phase name, and test item name. One-hot encoding transformation is performed on the classification features. The fault type labels, which serve as the target variable for supervised learning, are encoded. A mapping dictionary is defined, for example: {"normal"=0, "product_issue"=1, "pallet_issue"=2, "platform_issue"=3}. The label columns are iterated through, and the text labels are replaced with their corresponding integer category identifiers according to this mapping. This array of integer-encoded labels serves as the supervision signal during the model training phase.

[0058] In this embodiment, training a pre-set multi-classification model using the multi-dimensional feature data includes: Based on a preset partitioning ratio, the feature matrix input into the multi-classification model for training is divided into training dataset, validation dataset, and validation dataset. Set the objective function of the multi-classification model, input the training dataset into the classifier of the multi-classification model for iterative training, and evaluate the loss value using the validation dataset after each iteration. If the loss value exceeds a preset loss value threshold, training continues until the loss value does not exceed the preset loss value threshold. If the loss value does not exceed the preset loss value threshold, then the training is completed, and the model parameters of the current iteration are saved as the parameters of the trained multi-classification model.

[0059] Specifically, the process of training a pre-defined multi-classification model using the multi-dimensional feature data first involves the scientific partitioning and preprocessing of the feature matrix. Based on a pre-defined ratio of 7:2:1 for the training, validation, and test sets, the multi-dimensional feature matrix extracted and constructed in the aforementioned steps, containing measured values, classification feature codes, and hardware lifetime counts, is divided into training, validation, and test datasets. The training set is used for gradient boosting learning of the decision tree, the validation set is used for hyperparameter tuning and overfitting prevention monitoring during training, and the test set is used to ultimately verify the model's diagnostic accuracy for unknown fault samples. During model initialization, a specific objective function is configured for the classifier of the multi-classification model, targeting the multi-fault root cause determination scenario on the production line. A multi-classification logistic regression loss function is used, combined with a regularization penalty term to balance the model's bias and variance. The training dataset is input into the classifier of the multi-classification model to perform gradient boosting iterative training. During this process, the model continuously generates new decision trees through multiple iterations to fit the predicted residuals. After each iteration, the system uses a validation dataset in real time to evaluate the performance of the current model and calculates the logarithmic loss value, which represents the difference between the prediction accuracy and the true label. To ensure the accuracy of the diagnostic logic, the system continuously monitors the convergence of this loss value. If, after a certain iteration, the loss value does not exceed the preset loss threshold of 0.05, the system determines that the model has fully learned the fault features and has reached the training termination condition. At this point, the system completes the training process and solidifies and saves key parameters such as the decision tree weights, split thresholds, and model topology of the current iteration as parameters for the trained multi-classification model. This builds an expert system with automated diagnostic capabilities, which can be directly applied to real-time fault type output and root cause localization on the production line.

[0060] In this embodiment, the process of using the trained multi-classification model to diagnose the production line fault to be diagnosed and outputting the fault type includes: Acquire real-time test records from the production line to be diagnosed, extract multi-dimensional feature data, and perform feature alignment and numerical normalization to construct the feature vector to be inferred. The feature vector to be reasoned is input into the trained multi-classification model to perform logical reasoning, and outputs the probability distribution vectors of the records to be diagnosed as normal, product failure, product support component failure and test platform failure, respectively. The fault category corresponding to the maximum value in the probability distribution vector is determined as the fault type of the current production line.

[0061] Specifically, the process begins by acquiring raw test records generated in real-time during the production process of the production line to be diagnosed. Following the same logic as the model training phase, multi-dimensional feature data is extracted. Feature alignment is then performed to ensure that the dimensions of the input variables strictly match the splitting nodes of the decision tree within the model. Simultaneously, the extracted dimensional values ​​are normalized to eliminate differences in magnitude between different physical units, constructing a feature vector for forward inference. After data preparation, this feature vector is input into a trained multi-classification model with pre-defined parameters. Logical inference calculations are performed through a series of decision tree clusters integrated within the model. Utilizing the Softmax function's equal-probability transformation mechanism, probability distribution vectors are output, indicating whether the record to be diagnosed belongs to one of four pre-defined labels: normal, product fault, product support component fault, or test platform fault. A probability maximization search logic is then executed, determining the fault category corresponding to the highest probability value in the probability distribution vector as the fault type of the current production line. This achieves automated and precise mapping from multi-dimensional measurement features to physical root cause types, providing a decision-making basis for subsequent differentiated maintenance and closed-loop control of the production line.

[0062] Specifically, another flowchart of the production test line fault diagnosis method is shown below. Figure 2 As shown, see Figure 2 Starting with the initial configuration of test parameters, the system sequentially generates task orders and products under test, and assigns corresponding test platforms and tray resources to each product. In the core test loop, the system traverses test phases and specific test items through nested loops, introducing a decision branch at the execution of each test item to determine whether to inject a fault: if injection is determined, an outlier value deviating from the standard is generated; if not, a random value within the normal range is generated. The generated measurement values, along with their judgment results and upper and lower limit specifications, are recorded in real time. The system then enters the fault circuit interruption stage; if the current test fails and the phase has not ended, the process jumps directly to the Testexit stage to forcibly terminate the current product test; otherwise, it continues to execute the next test item. After completing the complete product test sequence, the system automatically labels the data with fault types according to the preset injection logic and sequentially performs feature engineering and numerical coding processing. These preprocessed multidimensional features are input into a multi-classification model for iterative training. The trained model parameters are fixed and saved for online prediction of newly collected real-time data in subsequent production, ultimately accurately outputting the corresponding fault root cause type.

[0063] Example 3 In this embodiment, a computer device 100 is proposed, which includes a memory 101, a processor 102, and a computer program stored in the memory 101 that can be executed by the processor. The processor 102 executes the computer program to implement a production line fault diagnosis method. A schematic diagram of the computer device is shown below. Figure 3 As shown.

[0064] In this embodiment, a computer storage medium is also proposed, on which a computer program is stored. The computer program includes program instructions, which, when executed by a computer device, cause the computer device to perform a production testing line fault diagnosis method.

[0065] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for diagnosing faults in a production testing line, characterized in that, Includes the following steps: Set the product's testing phase sequence, and set test items and test parameters for each testing phase; The product testing process is executed according to the set test phase sequence, and outliers are injected into the test results according to the preset fault types. The test results, including outliers, are recorded. The preset fault types include product faults, product support component faults, and test platform faults. Based on the product test results, determine whether the product has failed the test in this test item. If the test result is unqualified, mark the product test result for this test item with the corresponding fault type label. If the test results are satisfactory, the product testing process will continue. Obtain product test results and extract multidimensional feature data of the product test from the product test results; The multidimensional feature data is used to train a pre-set multi-classification model, and the trained multi-classification model is used to diagnose the production line faults to be diagnosed, and output the fault type.

2. The production line fault diagnosis method according to claim 1, characterized in that, The product testing phase sequence includes: a test preparation phase, a product performance testing phase, and a test exit phase, performed sequentially. The product performance testing phase includes several test items. The test parameters for each test item include: the normal value range of the test result, the duration range of the test, and the usage threshold of the vulnerable parts on which the test item is based. The vulnerable parts include the product support and the vulnerable hardware of the test platform.

3. The production line fault diagnosis method according to claim 2, characterized in that, The test items include the product's input voltage calibration value, auxiliary startup current, and auxiliary startup voltage; The step of injecting outlier values ​​into the corresponding test results according to the preset fault type includes: If the fault type is a product fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's input voltage calibration value. If the fault type is a product support component fault, then an abnormal value that deviates from the normal range of the test results will be injected into the product's auxiliary starting current test results. If the fault type is a test platform fault, then an abnormal value that deviates from the normal range of the test results will be injected into the test results of the product's auxiliary start-up voltage. If the fault type is normal and there is no fault, then a random value within the normal value range will be generated in the product's test results.

4. The production line fault diagnosis method according to claim 3, characterized in that, The product testing process also includes maintaining the vulnerable parts based on the number of times they have been used for the test items. The process is as follows: When testing products using the aforementioned consumable parts, the cumulative number of times the consumable parts are used is increased and recorded; Determine whether the number of times a vulnerable part has been used has reached a preset threshold. If so, mark the corresponding vulnerable part as being in maintenance status and set a maintenance end time. In maintenance status, the vulnerable part cannot be used for testing. After maintenance, the cumulative number of uses is cleared and the vulnerable part is restored to normal status. If not, continue product testing according to the product testing process.

5. The production line fault diagnosis method according to claim 4, characterized in that, If the product fails the test for the first time in the test item, a retest will be conducted based on the preset failure mode, and the process is as follows: Determine the type of the preset fault mode. If the fault mode is product fault and test platform fault, replace the test platform and product support, perform the same test item retest, record and judge the retest results. If the retest result is still unqualified, the test platform and product support will be replaced again, and the same test item will be retested a second time. If the retest result is qualified, record the retest result and continue to execute the product testing process; If the failure mode is pallet failure, replace the test platform and product support, perform the same test items again, record the retest results, and return to the original test platform and original product support for a second retest, and record the second retest results.

6. The production line fault diagnosis method according to claim 5, characterized in that, The process of extracting multidimensional feature data from product test results is as follows: Obtain the original product test results, which include unstructured descriptive text, measured values ​​of each test item, test results characterizing whether the test item is qualified or not, classification features of the test process, and fault type labels. Remove unstructured descriptive text from the original test results; Convert the measured values ​​of each test item into a unified numerical type; The test results, which characterize whether a test item passes or fails, are mapped to Boolean logic values. The classification features of the test process are processed by one-hot encoding to generate sparse binary feature vectors; The fault type labels are mapped to integer features using an encoder; The Boolean logic values, numerically converted measurement values, sparse binary feature vectors, and integer features are combined to construct the feature matrix for training the multi-classification model.

7. The production line fault diagnosis method according to claim 6, characterized in that, The step of training a pre-set multi-classification model using the multi-dimensional feature data includes: Based on a preset partitioning ratio, the feature matrix input into the multi-classification model for training is divided into training dataset, validation dataset, and validation dataset. Set the objective function of the multi-classification model, input the training dataset into the classifier of the multi-classification model for iterative training, and evaluate the loss value using the validation dataset after each iteration. If the loss value exceeds a preset loss value threshold, training continues until the loss value does not exceed the preset loss value threshold. If the loss value does not exceed the preset loss value threshold, then the training is completed, and the model parameters of the current iteration are saved as the parameters of the trained multi-classification model.

8. The production line fault diagnosis method according to claim 6, characterized in that, The trained multi-classification model diagnoses the production line faults to be diagnosed and outputs the fault type, including: Acquire real-time test records from the production line to be diagnosed, extract multi-dimensional feature data, and perform feature alignment and numerical normalization to construct the feature vector to be inferred. The feature vector to be reasoned is input into the trained multi-classification model to perform logical reasoning, and outputs the probability distribution vectors of the records to be diagnosed as normal, product failure, product support component failure and test platform failure, respectively. The fault category corresponding to the maximum value in the probability distribution vector is determined as the fault type of the current production line.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory that can be run on the processor, wherein the processor executes the computer program to implement the method according to any one of claims 1 to 8.

10. A computer storage medium, characterized in that, It stores a computer program, which includes program instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1 to 8.

Images