A fault simulation verification method, device and medium for SSD mass production

Abstract

This invention discloses a fault simulation verification method, device, and medium for SSD mass production, relating to the field of storage testing technology. The method includes: acquiring basic data and initial health status data of the SSD under test, generating a fault hypothesis map; receiving locking operations from testers on fault hypothesis nodes, generating a fault simulation verification task; performing operational state disturbances on the SSD under test, collecting actual operational response data, and generating a health baseline response trajectory; aligning the actual operational response data and the health baseline response trajectory with timestamps to obtain a response deviation sequence; generating a verification task under the same conditions and a de-triggered verification task when the response deviation sequence meets the anomaly observation conditions; and generating an SSD mass production release decision based on observability and repeatability results, data consistency verification results, and interactive confirmation results. This invention achieves closed-loop traceability from fault hypothesis construction, simulation verification, anomaly verification to mass production release decision.

Description

Technical Field

[0001] This invention relates to the field of storage testing technology, and in particular to a fault simulation verification method, equipment and media for SSD mass production. Background Technology

[0002] Mass production testing of solid-state drives (SSDs) is a critical process to ensure product quality and reliability before shipment. Current mainstream mass production testing methods typically employ a strategy combining functional testing and aging testing. This includes performing basic read / write checks, interface protocol consistency verification, power-off recovery testing, and high / low temperature environmental stress screening on the SSD. Simultaneously, the testing system assesses the SSD's health status by collecting controller logs and health status information (such as the number of bad blocks, erase / write cycle distribution, and error correction retry count). These methods focus on detecting obvious functional defects or performance degradation in SSDs under standardized testing conditions, effectively identifying early failure units generated during the manufacturing process.

[0003] However, the aforementioned conventional testing methods have two limitations when facing complex failure modes. First, the test stimulus modes are relatively fixed, making it difficult to actively simulate and quantify specific potential failure mechanisms (such as cumulative read interference, write amplification anomalies, firmware response hysteresis, etc.), resulting in some anomalies that only appear under specific load or boundary conditions being difficult to effectively trigger. Second, for abnormal response phenomena that occur during testing, there is a lack of a systematic mechanism to determine whether the anomaly is repeatable and its true correlation with specific test conditions, which can easily lead to misjudging occasional fluctuations as substantial defects or overlooking potential risks that require specific combinations of conditions to reproduce. Summary of the Invention

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

[0005] Therefore, this invention provides a fault simulation verification method for SSD mass production to solve the problems of insufficient proactive verification capability of fault modes and lack of causal correlation judgment mechanism for abnormal response in existing technologies.

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

[0007] In a first aspect, the present invention provides a fault simulation verification method for SSD mass production, comprising: acquiring basic data and initial health status data of the SSD under test, and generating a fault hypothesis graph consisting of fault hypothesis nodes and fault-related edges; receiving a locking operation of the fault hypothesis nodes by testers, and generating a fault simulation verification task; performing operational state perturbation on the SSD under test according to the fault simulation verification task, and collecting actual operational response data; generating a health baseline response trajectory based on the basic data of the SSD under test and the fault simulation verification task; aligning the actual operational response data and the health baseline response trajectory with timestamps to obtain a response deviation sequence; generating a verification task under the same conditions and a de-triggered verification task when the response deviation sequence meets the abnormal observation conditions, so as to determine the observability and repeatability of the locked fault hypothesis nodes; generating an SSD mass production release decision based on the observability and repeatability results, data consistency verification results, and interactive confirmation results; and finally, writing the fault hypothesis graph, fault simulation verification task, response deviation sequence, verification task results, and mass production release decision into a health management traceability record.

[0008] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the generation of a fault hypothesis graph consisting of fault hypothesis nodes and fault association edges includes: connecting the SSD under test to the mass production testing station; the mass production testing platform identifying the SSD under test through an interface protocol and reading the basic data and initial health status data of the SSD under test; generating media degradation hypothesis nodes, read interference anomaly hypothesis nodes, write amplification anomaly hypothesis nodes, power-down recovery anomaly hypothesis nodes, temperature deceleration anomaly hypothesis nodes, interface communication anomaly hypothesis nodes, and firmware response anomaly hypothesis nodes based on the basic data and initial health status data; generating fault association edges based on the triggering relationship, accompanying relationship, or causal relationship between different fault hypothesis nodes, and retaining the corresponding fault association edge when the edge association value reaches the association threshold, thus forming a fault hypothesis graph.

[0009] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the generation of fault simulation verification tasks includes: displaying a fault hypothesis map and displaying the node risk value of each fault hypothesis node; based on the node risk value, receiving locking, canceling, or combined operations performed by testers on the fault hypothesis nodes, and determining the locked fault hypothesis nodes as target nodes for entering fault simulation verification; generating fault simulation verification tasks based on the locked fault hypothesis nodes; the fault simulation verification tasks include simulated fault types, read / write access modes, command queue depth, access address range, power failure trigger time, temperature and pressure range, interface communication disturbance conditions, data verification methods, health status acquisition cycle, and counterfactual verification conditions; when testers lock two or more fault hypothesis nodes, the execution order of the fault simulation verification tasks is determined according to the fault association edges, or a fault simulation verification task queue is generated according to the node risk values ​​from high to low.

[0010] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the steps of performing operational state perturbation on the SSD under test according to the fault simulation verification task and collecting actual operational response data are as follows: parsing the fault simulation verification task to determine the simulated fault type of the SSD under test; converting the fault simulation verification task into test control instructions according to the simulated fault type; the test control instructions include at least one of read / write control instructions, access address control instructions, command queue control instructions, temperature and pressure control instructions, power-down control instructions, interface communication pressure control instructions, and firmware command detection instructions; performing operational state perturbation on the SSD under test according to the test control instructions, and collecting actual operational response data according to the health status acquisition cycle during the operational state perturbation process; adding a collection timestamp, fault simulation verification task identifier, locked fault hypothesis node identifier, and test station identifier to each actual operational response data, and generating an actual operational response sequence according to the collection timestamp.

[0011] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the generation of the health baseline response trajectory includes: selecting a set of qualified samples matching the current SSD from the qualified sample data of the mass production testing platform based on the basic data, initial health status data, and fault simulation verification task of the SSD under test; extracting historical response data corresponding to the simulated fault type, basic data, and health status acquisition cycle from the qualified sample set according to the fault simulation verification task, forming a candidate baseline response data set; performing state correction on the candidate baseline response data set based on the initial health status data of the current SSD under test; the state correction includes at least one of capacity correction, temperature correction, write / erase cycle correction, and firmware version correction; generating a health baseline response trajectory based on the state-corrected candidate baseline response data set, and adding the same timestamp as the actual running response data to each health baseline response value in the health baseline response trajectory.

[0012] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, adding the same timestamp as the actual operating response data to each health baseline response value includes: reading the acquisition timestamp, fault simulation verification task identifier, locked fault hypothesis node identifier, and health indicator type from the actual operating response data; reading the baseline timestamp, fault simulation verification task identifier, and health indicator type from the health baseline response trajectory; using the start time of the fault simulation verification task as a unified time zero point, converting the actual operating response data and the health baseline response trajectory to the same test time axis; for health indicators with completely consistent timestamps, establishing a correspondence between the actual operating response value and the health baseline response value; for health indicators with incompletely consistent timestamps, using the health status acquisition period as the base time window, grouping the actual operating response value and the health baseline response value within the same base time window into the same response comparison unit; generating response comparison data based on the response comparison unit, calculating the response deviation value based on the response comparison data, and generating a response deviation sequence according to the order of the test time windows.

[0013] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the determination of the observability and repeatability of the locked fault hypothesis node includes: judging whether the abnormal observation conditions are met based on the response deviation sequence and the node comprehensive deviation value; the abnormal observation conditions include at least one of single index abnormal conditions, node comprehensive abnormal conditions, and continuous window abnormal conditions; when the response deviation sequence meets the abnormal observation conditions, an abnormal observation window is recorded, and a same-condition verification task and a trigger-free verification task are generated based on the locked fault hypothesis node corresponding to the abnormal observation window; the same-condition verification task and the trigger-free verification task are executed, and same-condition verification response data and trigger-free verification response data are collected according to the same health status acquisition cycle as the first fault simulation verification task; the same-condition verification response data and trigger-free verification response data are aligned with the health baseline response trajectory according to the timestamp to generate the same-condition verification deviation sequence and the trigger-free verification deviation sequence; the first response deviation sequence, the same-condition verification deviation sequence, and the trigger-free verification deviation sequence are compared to determine the observability and repeatability of the locked fault hypothesis node.

[0014] As a preferred embodiment of the fault simulation verification method for SSD mass production described in this invention, the generation of SSD mass production release decisions includes: reading the observability results, repeatability results, data consistency verification results, and interactive confirmation results of the locked fault hypothesis nodes, and establishing a node decision data set for each locked fault hypothesis node; calculating the decision risk value of the locked fault hypothesis node based on the observability results, repeatability results, and data consistency verification results; generating the node decision status of the locked fault hypothesis node based on the decision risk value, data consistency anomaly flag, and interactive confirmation flag; the node decision status includes node pass, node watch, node re-inspection, and node isolation; generating an SSD mass production release decision based on the node decision status of all locked fault hypothesis nodes; the SSD mass production release decision includes qualified release, downgraded release, key sampling inspection, rework inspection, fault isolation, and batch warning; displaying the decision basis to the testers before generating the SSD mass production release decision, and determining the final SSD mass production release decision based on the testers' confirmation operation.

[0015] In a second aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein when the computer program is executed by the processor, it implements any step of the fault simulation verification method for SSD mass production as described in the first aspect of the present invention.

[0016] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any step of the fault simulation verification method for SSD mass production as described in the first aspect of the present invention.

[0017] The beneficial effects of this invention are as follows: By generating a fault hypothesis map and locking fault hypothesis nodes to generate fault simulation verification tasks, proactive and targeted simulation verification of potential SSD fault modes is achieved; by collecting actual operating response data and generating a health baseline response trajectory, and aligning it with timestamps to obtain a response deviation sequence, a quantitative measurement of the degree of deviation from the health status is achieved; by generating same-condition verification and de-trigger verification tasks and determining observability and repeatability, a systematic judgment of the causal relationship between abnormal responses and fault triggering conditions is achieved; by comprehensively considering observability, repeatability, data consistency, and interactive confirmation results to generate a mass production release decision and writing it into the health management traceability record, a closed-loop management and traceability of the entire process from fault hypothesis to release decision is achieved. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a fault simulation verification method for SSD mass production.

[0020] Figure 2 A flowchart generated for fault hypothesis mapping and fault simulation verification tasks.

[0021] Figure 3 A flowchart for generating trajectories and sequences.

[0022] Figure 4 A flowchart for the SSD mass production release decision.

[0023] Figure 5 This is a comparison chart of the overall deviation values ​​of nodes in the first fault simulation verification and review task.

[0024] Figure 6 This is a line chart comparing the proportion of abnormalities within the same production batch. Detailed Implementation

[0025] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0026] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0027] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0028] Reference Figures 1-6 This is one embodiment of the present invention, which provides a fault simulation verification method for SSD mass production, including the following steps:

[0029] S1. Obtain the basic data and initial health status data of the SSD under test, and generate a fault hypothesis graph consisting of fault hypothesis nodes and fault-related edges.

[0030] In this embodiment, after the SSD under test is connected to the mass production testing station, the mass production testing platform identifies the SSD under test through the interface protocol and establishes a data communication connection with the SSD under test.

[0031] The interface protocol includes any one of the following: NVMe protocol, SATA protocol, or PCIe protocol.

[0032] First, read the basic data of the SSD under test.

[0033] The basic data of the SSD under test includes the SSD's device identification information, capacity specifications, firmware version, flash memory chip type, interface protocol type, and mass production batch information.

[0034] Among them, the device identification information is used to uniquely identify the SSD under test; the capacity specification is used to determine the storage capacity level of the SSD under test; the firmware version is used to determine the current version of the control program running on the SSD under test; the flash memory chip type is used to distinguish between SLC, MLC, TLC or QLC and other chip types; the interface protocol is used to determine the data transmission protocol used by the SSD under test; and the mass production batch information is used to determine the production batch, production line number and test station number to which the SSD under test belongs.

[0035] Then, read the initial health status data of the SSD under test.

[0036] The initial health status data includes the number of bad blocks, the proportion of spare blocks used, the distribution of erase / write cycles, the count of read errors, the count of write errors, the number of error correction retries, the number of unrecoverable read errors, temperature data, read / write latency, the number of command timeouts, the number of interface retransmissions, the power-off recovery status, the firmware exception log, and the data consistency verification results.

[0037] Initial health status data can be obtained from the controller log, health status log, error log, firmware operation log, and initial read / write test commands set by the mass production test platform of the SSD under test.

[0038] Finally, based on the basic data and initial health status data of the SSD under test, a fault hypothesis map corresponding to the SSD under test is generated.

[0039] The fault hypothesis graph includes fault hypothesis nodes and fault-related edges.

[0040] Among them, fault hypothesis nodes are used to represent the types of faults that may need to be verified during the mass production testing of the SSD under test; fault association edges are used to represent the triggering relationship, accompanying relationship or causal relationship between different fault hypothesis nodes.

[0041] In this embodiment, the fault hypothesis nodes include media degradation hypothesis nodes, read interference anomaly hypothesis nodes, write amplification anomaly hypothesis nodes, power-down recovery anomaly hypothesis nodes, temperature deceleration anomaly hypothesis nodes, interface communication anomaly hypothesis nodes, and firmware response anomaly hypothesis nodes.

[0042] Among them, the media degradation hypothesis node is generated based on the number of bad blocks, the proportion of spare blocks used, the distribution of erase / write cycles, the number of error correction retries, and the number of unrecoverable read errors; the read interference anomaly hypothesis node is generated based on the read error count, the number of error correction retries, the number of unrecoverable read errors, and the read / write latency; the write amplification anomaly hypothesis node is generated based on the write error count, the distribution of erase / write cycles, the proportion of spare blocks used, and the write latency; the power-down recovery anomaly hypothesis node is generated based on the power-down recovery status, the power-down recovery time, the firmware anomaly log, and the data consistency verification results; the temperature degradation anomaly hypothesis node is generated based on temperature data, the rate of temperature change, changes in read / write throughput, and changes in read / write latency; the interface communication anomaly hypothesis node is generated based on the number of interface retransmissions, the number of command timeouts, and the interface protocol type; and the firmware response anomaly hypothesis node is generated based on the firmware version, the firmware anomaly log, the firmware anomaly return code, and the command response time.

[0043] The process of generating fault hypothesis nodes specifically involves calculating the node risk value for each fault hypothesis node.

[0044] Among them, the node risk value is used to indicate the necessity of triggering the corresponding fault hypothesis node on the current SSD under test.

[0045] The node risk value can be calculated based on the normalized deviation of the corresponding health status indicator.

[0046] In this embodiment, a method for calculating the node risk value is provided. Specifically, the formula for calculating the node risk value is expressed as follows:

[0047] ;

[0048] in, Indicates the first The node risk value of each faulty node. Indicates the first The fault hypothesis node corresponding to the first Normalized deviation of each health status indicator Indicates the first The health status indicator and the first The correlation coefficients between the fault hypothesis nodes Indicates participation in the calculation of the first The total number of health status indicators for each fault hypothesis node risk value. This indicates the sequence number of the health status indicator. This indicates the fault hypothesis node number.

[0049] In the formula, the normalized deviation value, correlation coefficient, and node risk value all range from 0 to 1.

[0050] The correlation coefficient is calculated by the mass production testing platform based on historical mass production test data and labeled faulty samples of SSDs of the same model, firmware version, and flash memory chip type. The health status indicator in the first The frequency of synchronization anomalies when a faulty node occurs is calculated and pre-written into the test rule base after normalization.

[0051] Among them, normalized deviation value The calculation formula is expressed as:

[0052] ;

[0053] in, Indicates the first The fault assumption node's first The current collected values ​​of each health status indicator. Indicates the first The fault assumption node's first The qualified sample benchmark value of each health status indicator. Indicates the first The fault assumption node's first The permissible fluctuation range of each health status indicator.

[0054] After generating fault hypothesis nodes, fault association edges are generated based on the association relationships between different fault hypothesis nodes.

[0055] The rules for establishing fault-related edges are as follows, in steps A1-A4:

[0056] A1. When the temperature data exceeds the temperature correlation threshold and the read / write latency increases synchronously relative to the previous window, establish a fault correlation edge between the temperature drop anomaly hypothesis node and the read interference anomaly hypothesis node.

[0057] A2. When the proportion of spare blocks used increases and the dispersion of erase / write counts increases, establish a fault association edge between the write amplification anomaly hypothesis node and the media degradation hypothesis node.

[0058] A3. When the power-down recovery status is abnormal and the data consistency verification result is abnormal, establish a fault association edge between the power-down recovery abnormal assumption node and the firmware response abnormal assumption node.

[0059] A4. When the number of interface retransmissions and command timeouts increases, establish a fault association edge between the interface communication anomaly assumption node and the firmware response anomaly assumption node.

[0060] For example, when the cumulative increase of the number of interface retransmissions relative to the corresponding health baseline value within three consecutive health status collection cycles is not less than 20%, and the cumulative increase of the number of command timeouts relative to the corresponding health baseline value is not less than 15%, a candidate fault association edge is established between the interface communication anomaly assumption node and the firmware response anomaly assumption node.

[0061] It should be noted that fault-related edges can have edge association values, where the edge association value is used to represent the association strength between two fault-possible nodes.

[0062] The edge association value can be determined by the degree of synchronous deviation of the health status indicators of two fault hypothesis nodes within the same time window. Specifically, the edge association value is determined by calculating the normalized deviation values ​​of the health status indicators corresponding to the two fault hypothesis nodes within the same time window, and taking the average of the products of the normalized deviation values ​​of the corresponding health status indicators of each group. When the deviation direction of the health status indicator is opposite to that of the two fault hypothesis nodes, the corresponding product is recorded as zero. When the edge association value reaches the association threshold, the corresponding fault association edge is retained. When the edge association value does not reach the association threshold, the corresponding fault association edge is not established.

[0063] It should be noted that the correlation threshold is determined by the mass production testing platform based on the distribution of edge correlation values ​​of different fault assumption nodes appearing in pairs in the historical mass production test data of SSDs of the same model, firmware version, and flash memory chip type. The smallest edge correlation value that can distinguish between real correlated faults and occasional synchronous fluctuations is selected as the correlation threshold of the corresponding fault-related edge; the value range is usually 0~1.

[0064] S2. Receive the lock operation of the fault hypothesis node by the tester and generate a fault simulation verification task.

[0065] Once the fault hypothesis map is generated, it will be displayed.

[0066] The fault hypothesis map can display fault hypothesis nodes in the form of a node graph, list, or hierarchical tree structure, and display the node risk value, relevant health status indicators, abnormal basis, and recommended verification level for each fault hypothesis node.

[0067] Testers perform locking, canceling, or combined operations on the faulty hypothetical node.

[0068] Among them, the lock operation indicates that the tester confirms that the corresponding fault hypothesis node needs to enter the subsequent fault simulation verification; the cancel operation indicates that the tester confirms that the corresponding fault hypothesis node will not enter the current round of fault simulation verification; the combination operation indicates that the tester will verify two or more related fault hypothesis nodes as a combined fault hypothesis.

[0069] After receiving the tester's lock operation on the fault hypothesis node, the mass production test platform generates a fault simulation verification task based on the locked fault hypothesis node.

[0070] The fault simulation verification task includes simulating fault types, read / write access modes, command queue depth, access address range, power failure trigger time, temperature and pressure range, interface communication disturbance conditions, data verification methods, health status acquisition cycle, and counterfactual verification conditions.

[0071] Specifically, when the locked fault hypothesis node is a media degradation hypothesis node, a fault simulation verification task is generated that includes random read / write access, access within a specified logical address range, error correction and retry monitoring, and bad block growth monitoring.

[0072] When the locked fault hypothesis node is a read interference anomaly hypothesis node, a fault simulation verification task is generated that includes high-frequency read access, read error count monitoring, error correction retry monitoring, and unrecoverable read error monitoring.

[0073] When the locked fault hypothesis node is the write amplification anomaly hypothesis node, a fault simulation verification task is generated that includes small block random writing, sequential write switching, erase / write count distribution monitoring, and spare block usage ratio monitoring.

[0074] When the locked fault hypothesis node is a power failure recovery abnormal hypothesis node, a fault simulation verification task is generated, which includes power failure triggering during the writing process, recovery startup detection, power failure recovery time monitoring, and data consistency verification.

[0075] When the locked fault hypothesis node is a temperature drop rate anomaly hypothesis node, a fault simulation verification task is generated that includes temperature and pressure range control, throughput monitoring, read / write latency monitoring, and temperature change rate monitoring.

[0076] When the locked fault hypothesis node is the interface communication abnormal hypothesis node, a fault simulation verification task is generated, which includes monitoring of interface bandwidth pressure, command queue depth changes, interface retransmission counts, and command timeout counts.

[0077] When the locked fault hypothesis node is a firmware response anomaly hypothesis node, a fault simulation verification task is generated that includes firmware command response detection, anomaly return code collection, firmware anomaly log collection, and command response time monitoring.

[0078] When testers lock two or more fault hypothesis nodes, they determine the execution order of the fault simulation verification task based on the fault association edges.

[0079] For two fault hypothesis nodes with fault-related edges, the fault simulation verification task corresponding to the fault hypothesis node with the higher edge association value is executed first; for multiple fault hypothesis nodes without fault-related edges, a fault simulation verification task queue is generated in descending order of node risk value.

[0080] S3. Perform operational status disturbances on the SSD under test according to the fault simulation verification task, and collect actual operational response data.

[0081] After generating a fault simulation verification task, the mass production testing platform analyzes the fault simulation verification task to determine the simulated fault type, read / write access mode, command queue depth, access address range, power failure trigger time, temperature and pressure range, interface communication disturbance conditions, data verification method, health status collection cycle, and counterfactual verification conditions corresponding to the SSD under test.

[0082] Specifically, based on the simulated fault type, the fault simulation verification task is converted into test control instructions that can be executed by operational state disturbances.

[0083] The test control instructions include at least one of the following: read / write control instructions, access address control instructions, command queue control instructions, temperature and pressure control instructions, power-down control instructions, interface communication pressure control instructions, and firmware command detection instructions.

[0084] The fault simulation verification task is converted into test control instructions that can be executed by operational state disturbances, specifically as follows: Steps B1-B7:

[0085] B1. When the fault simulation verification task corresponds to the media degradation hypothesis node, the random read and write access ratio is set to perform random read and write access on the specified logical address range of the SSD under test. During the access process, the write data block size, read data block size and access duration are controlled to generate observable media read and write pressure on the SSD under test within the specified logical address range.

[0086] B2. When the fault simulation verification task corresponds to the hypothetical node of read interference, high-frequency read access is performed on the specified logical address range of the SSD under test, and the number of reads and the read interval of adjacent logical address ranges are controlled to simulate the read interference verification scenario caused by concentrated read access.

[0087] B3. When the fault simulation verification task corresponds to the write amplified abnormal hypothesis node, the write load disturbance is performed on the SSD under test in the manner of alternating small block random write and sequential write, and the changes in the amount of written data, host write volume and internal erase / write count are recorded.

[0088] B4. When the fault simulation verification task corresponds to the power failure recovery abnormal assumption node, during the write operation of the SSD under test, the power control unit is controlled to perform a power failure operation according to the power failure trigger time in the fault simulation verification task, and the power control unit is controlled to restore power supply after the power failure retention time ends. Then, the re-identification status, power failure recovery time and data consistency verification results of the SSD under test are detected.

[0089] B5. When the fault simulation verification task corresponds to the assumed node of abnormal temperature drop, the temperature control device is controlled to apply temperature pressure to the SSD under test according to the temperature pressure range, and continuous read and write access is performed within the temperature pressure range. The read and write throughput, input and output latency and temperature change rate of the SSD under test at different temperature stages are recorded.

[0090] B6. When the fault simulation verification task corresponds to the node with abnormal interface communication, the interface communication of the SSD under test is disturbed by increasing the command queue depth, increasing the number of concurrent commands, or setting interface bandwidth pressure, and the number of interface retransmissions, command timeouts, and command completion status are recorded.

[0091] B7. When the fault simulation verification task corresponds to the assumed node with an abnormal firmware response, according to the firmware command detection instructions in the fault simulation verification task, send management commands, read / write commands or status query commands to the SSD under test, and collect firmware abnormal return codes, command response times and firmware abnormal logs.

[0092] During the execution of B1-B7 operational status disturbances, the actual operational response data of the SSD under test is collected according to the health status collection cycle.

[0093] The actual operational response data includes read / write throughput, input / output latency, latency jitter, command timeout count, interface retransmission count, error correction retries count, unrecoverable read errors count, bad block growth, spare block consumption change, write / erase count dispersion, temperature change rate, power-off recovery time, firmware exception return code, and data consistency verification results.

[0094] Specifically, read / write throughput and input / output latency are obtained through statistics from read / write test commands executed by the mass production test platform; latency jitter is calculated based on the fluctuation of multiple input / output latency values ​​within the same acquisition period; command timeout count and interface retransmission count are obtained through interface protocol status records; error correction retries, unrecoverable read errors, bad block growth, and spare block consumption changes are obtained through the controller logs, error logs, or health status logs of the SSD under test; temperature change rate is calculated through continuously collected temperature data; power-off recovery time is determined by the time it takes for the SSD under test to be re-identified by the mass production test platform after power failure; firmware exception return codes are obtained through firmware command response results; and data consistency verification results are obtained by comparing the verification values ​​of written test data with those of read test data.

[0095] Because the real-time collected test data has different formats, parameter comparison is not possible. To ensure that the actual collected test data can be compared with the health baseline response trajectory, a collection timestamp, a fault simulation verification task identifier, a locked fault hypothesis node identifier, and a test station identifier are added to each actual operation response data. An actual operation response sequence is then generated according to the collection timestamp. For actual operation response data with different collection periods, alignment processing is performed according to a unified time window to ensure that different health indicators form a corresponding relationship within the same time window.

[0096] Specifically, the health status collection cycle is used as the basic time window, and the actual operation response data collected within the same basic time window are grouped into the same response data set. When there are multiple similar indicator collection values ​​within the same basic time window, the average value, maximum value, or last collection value within the basic time window is taken as the window representative value of the corresponding indicator. The specific value selection method is preset by the mass production testing platform according to the indicator type.

[0097] For example, the average value is used for read / write throughput, the maximum value is used for input / output latency, the last collected value is used for temperature data, and the cumulative value is used for command timeouts.

[0098] S4. Generate a health baseline response trajectory based on the basic data of the SSD under test and the fault simulation verification task.

[0099] Simultaneously, based on the capacity specifications, firmware version, flash memory chip type, interface protocol type, initial health status data, and fault simulation verification task of the SSD under test, a health baseline response trajectory that the SSD under test should exhibit in a healthy state is generated.

[0100] The health baseline response trajectory includes the baseline throughput trajectory, baseline delay trajectory, baseline temperature trajectory, baseline error correction retry trajectory, baseline spare block consumption trajectory, baseline interface retransmission trajectory, and baseline power failure recovery trajectory.

[0101] In this embodiment, the health baseline response trajectory is not generated using a single fixed threshold, but rather based on the basic attributes of the SSD under test, its initial health status, and the current fault simulation verification task.

[0102] Specifically, the first step is to select a set of qualified samples that match the SSD to be tested from the qualified sample database of the mass production testing platform.

[0103] Among them, the qualified sample SSDs in the qualified sample set have the same or similar capacity specifications, firmware version, flash memory chip type and interface protocol type as the current SSD under test, and the qualified sample SSDs have been judged to be qualified and released in historical mass production tests.

[0104] Furthermore, based on the current fault simulation verification task, historical response data corresponding to the simulated fault type, read / write access mode, command queue depth, access address range, temperature and pressure range, and health status acquisition cycle are extracted from the qualified sample set to form a candidate baseline response data set.

[0105] In order to ensure that the health baseline response trajectory can reflect the initial state differences of the SSD under test, the candidate baseline response data set is corrected based on the initial health state data of the SSD under test.

[0106] Status correction can include capacity correction, temperature correction, write / erase cycles correction, and firmware version correction.

[0107] For example, for read / write throughput, the basic throughput range is determined based on capacity specifications, interface protocol type, and command queue depth, and then corrected based on current temperature data and flash memory chip type; for input / output latency, it is corrected based on read / write access mode, command queue depth, firmware version, and initial read / write latency; for error correction retry trajectory, it is corrected based on initial error correction retry count, erase / write count distribution, and flash memory chip type; for spare block consumption trajectory, it is corrected based on initial spare block usage ratio, bad block count, and write load intensity.

[0108] It should be noted that, in this embodiment, the state correction refers to the process by which those skilled in the art, based on the capacity specifications, interface protocol type, firmware version, flash memory chip type, and initial health status data of the SSD under test, converts the differences in hardware configuration, firmware version, and initial operating status between the current SSD under test and qualified sample SSDs into correction coefficients. These correction coefficients are then used to correct the baseline throughput, baseline latency, baseline temperature, baseline error correction retry count, baseline spare block consumption, baseline interface retransmission count, and baseline power-down recovery time in the qualified sample database. The correction coefficients can be determined using the mean, median, standard deviation, proportional relationship, or segmentation threshold of historical qualified sample test data.

[0109] In this embodiment, a method for generating a health baseline response trajectory is provided, and the formula for generating the health baseline response value is expressed as:

[0110] ;

[0111] in, Indicates the first A health indicator Health baseline response value at any given time. Indicates the first A health indicator The sample baseline value at time 10:00. Indicates the first The capacity interface correction factor corresponding to the capacity specification and interface protocol type of each health indicator. Indicates the first The firmware version and flash memory chip type corresponding to each health indicator are used to determine the firmware chip correction factor. Indicates the first The health status correction coefficient corresponding to the initial health status data of each health indicator.

[0112] The sample baseline value can be calculated from the qualified sample response data within the same time window in the candidate baseline response dataset. To reduce the impact of outliers on the baseline value, the sample baseline value can be the median or the truncated mean.

[0113] The health status correction coefficient is expressed as:

[0114] ;

[0115] in, Indicates the first The state sensitivity coefficient corresponding to each health indicator Indicates the first The initial health deviation value corresponding to each health indicator.

[0116] Among them, the state sensitivity coefficient is preset by the mass production testing platform based on historical qualified sample data and historical abnormal sample data; the initial health deviation value is calculated based on the difference between the initial health status data of the current SSD under test and the initial health status data of qualified samples.

[0117] After the health baseline response trajectory is generated, each health baseline response value is added with the same timestamp as the actual running response data, so that the health baseline response trajectory and the actual running response sequence can be compared on the same time axis.

[0118] In this embodiment, if there is no qualified sample set in the qualified sample database that perfectly matches the SSD under test, qualified sample SSDs with the same capacity specifications, interface protocol type, and flash memory chip type are selected as candidate samples, and the benchmark response value is corrected by the firmware version correction coefficient; if a sufficient number of candidate samples still cannot be obtained in the qualified sample database, the mass production test platform uses the factory test specification benchmark data corresponding to the current SSD model to generate a health benchmark response trajectory, and marks the benchmark source type in the health management traceability record.

[0119] S5. Timestamp align the actual operational response data and the health baseline response trajectory to obtain the response deviation sequence.

[0120] After obtaining the actual operating response data and the health baseline response trajectory, the mass production testing platform aligns the actual operating response data and the health baseline response trajectory according to the timestamps to obtain the response deviation sequence.

[0121] Specifically, the system reads the data collection timestamp, fault simulation verification task identifier, locked fault hypothesis node identifier, and health indicator type from the actual operation response data, and also reads the baseline timestamp, fault simulation verification task identifier, and health indicator type from the health baseline response trajectory.

[0122] Using the start time of the fault simulation verification task as a unified time zero point, the actual operation response data and the health baseline response trajectory are converted to the same test time axis.

[0123] For health indicators where the timestamps in the actual operational response data and the health baseline response trajectory are completely consistent, a direct correspondence between the actual operational response value and the health baseline response value is established. For health indicators where the timestamps in the actual operational response data and the health baseline response trajectory are not completely consistent, the health status collection period is used as the basic time window, and the actual operational response values ​​and health baseline response values ​​within the same basic time window are grouped into the same response comparison unit.

[0124] When multiple actual operational response values ​​exist within the same basic time window, the representative value for the window is determined based on the type of health indicator. For read / write throughput, the average of multiple throughput data collected within the same basic time window is used as the representative value for the actual throughput window; for input / output latency and latency jitter, the maximum value among multiple latency data collected within the same basic time window is used as the representative value for the actual latency window; for temperature data, the last temperature data collected within the same basic time window is used as the representative value for the actual temperature window; for command timeout counts, interface retransmission counts, error correction retries, and unrecoverable read errors, the cumulative value within the same basic time window is used as the representative value for the corresponding health indicator window.

[0125] After completing the timestamp alignment, output the response comparison data.

[0126] The response comparison data includes the test time window, health indicator type, actual running response value, health baseline response value, fault simulation verification task identifier, and locked fault hypothesis node identifier.

[0127] The response deviation value is calculated based on the response comparison data, and the response deviation sequence is generated according to the order of the test time windows.

[0128] The response deviation sequence is used to represent the degree of deviation of the SSD under test from the health baseline response trajectory under the fault simulation verification task.

[0129] In this embodiment, the first The health indicator at the first The response deviation within each test time window is calculated using the following formula:

[0130] ;

[0131] in, Indicates the first The health indicator at the first Response deviation within a test time window Indicates the first The health indicator at the first The actual running response value within each test time window.

[0132] To avoid occasional fluctuations in a single health indicator directly triggering abnormal observations, the comprehensive deviation value of the node is calculated based on the set of health indicators corresponding to the locked fault hypothesis node.

[0133] Among them, the node comprehensive deviation value is used to represent the overall degree of abnormality of the locked fault hypothesis node within the current test time window.

[0134] Formula for calculating the overall deviation of nodes:

[0135] ;

[0136] in, Indicates the first The locked fault hypothesis node is at the 1st The overall deviation of nodes within each test time window Indicates the first The health indicators and the first The strength of the correlation between indicators among the locked fault hypothesis nodes.

[0137] It should be noted that the correlation strength of the indicators was obtained offline by the mass production testing platform based on historical qualified sample data, historical abnormal sample data, and the correspondence between fault hypothesis nodes and health indicators. Specifically, it was calculated by statistically analyzing the first... The health indicator at the first Each fault hypothesis node corresponds to the deviation contribution of abnormal samples relative to qualified samples, and the deviation contribution is normalized to 0 to 1 and used as the index correlation strength.

[0138] S6. When the response deviation sequence meets the abnormal observation conditions, generate a verification task with the same conditions and a de-triggering verification task to determine the observability and repeatability of the locked fault hypothesis node.

[0139] Whether the abnormal observation conditions are met is determined based on the response deviation sequence and the overall node deviation value.

[0140] Among them, abnormal observation conditions include at least one of single-index abnormal conditions, node-wide abnormal conditions, and continuous window abnormal conditions.

[0141] Abnormal observation conditions, the specific judgments are as follows:

[0142] A single-indicator abnormal condition refers to a situation where the response deviation of the same health indicator reaches the single-indicator deviation threshold of the corresponding health indicator within at least one test time window.

[0143] The node comprehensive anomaly condition is when the node comprehensive deviation value of the locked fault hypothesis node reaches the corresponding fault hypothesis node's node deviation threshold.

[0144] Continuous window anomaly condition, that is, the node comprehensive deviation value of the same locked fault hypothesis node reaches the node deviation threshold in multiple consecutive test time windows, such as 3 test time windows.

[0145] It should be noted that the deviation threshold for a single indicator is statistically obtained by the mass production testing platform based on the distribution of health indicator deviations of historical qualified samples of the same model, capacity, firmware version, and flash memory type under the same fault simulation verification task. Specifically, the threshold is determined by taking the first... The upper quantile of the qualified samples for each health indicator response deviation value, such as 95%, is used as the deviation threshold for a single indicator, typically ranging from 0.15 to 0.40. The node deviation threshold is obtained offline by the mass production testing platform based on the distribution of the comprehensive node deviation values ​​corresponding to the same fault hypothesis node in historical qualified and abnormal samples. Specifically, the boundary of the comprehensive node deviation value that can distinguish between qualified and abnormal samples is selected as the threshold. The node deviation of a faulty hypothetical node is a threshold; the value range is usually 0.30~0.70.

[0146] In this embodiment, to improve the stability of anomaly observation results, a combination of node-wide anomaly conditions and continuous window anomaly conditions is preferentially adopted for judgment. That is, when the... The node composite deviation of a locked fault hypothesis node in continuous If the node deviation threshold is reached within each test time window, then continuously Each test time window is marked as an anomaly observation window.

[0147] in, This represents the number of consecutive windows, which is preset by the mass production testing platform based on the health status acquisition cycle and fault hypothesis node type of the fault simulation verification task. For example, for interface communication anomaly hypothesis nodes, the number of consecutive windows can be set to a smaller value to promptly capture command timeouts or interface retransmission anomalies; for media degradation hypothesis nodes, the number of consecutive windows can be set to a larger value to avoid misjudgments caused by short-term error correction retry fluctuations.

[0148] When the response deviation sequence meets the abnormal observation conditions, record the start time, end time, locked fault hypothesis node identifier, health indicator type that triggered the abnormality, actual running response value, health baseline response value, response deviation value, and node comprehensive deviation value of the abnormal observation window.

[0149] Based on the locked fault hypothesis node corresponding to the anomaly observation window, generate a verification task with the same conditions and trigger a verification task.

[0150] Among them, the same-condition verification task is used to determine whether the abnormal response can be repeated under the same fault simulation conditions; the trigger-free verification task is used to determine whether the abnormal response disappears or weakens as the trigger condition corresponding to the locked fault hypothesis node is canceled or reduced.

[0151] Specifically, the same-condition verification task retains the simulated fault type, read / write access mode, command queue depth, access address range, temperature and pressure range, interface communication disturbance conditions, health status acquisition cycle, and data verification method from the initial fault simulation verification task, and re-executes the same fault simulation verification task. For the power-down recovery anomaly hypothetical node, the same-condition verification task retains the power-down trigger time, power-off retention time, and data verification method from the initial fault simulation verification task; for the temperature-deceleration anomaly hypothetical node, the same-condition verification task retains the temperature and pressure range and read / write load intensity from the initial fault simulation verification task; for the interface communication anomaly hypothetical node, the same-condition verification task retains the command queue depth and interface communication pressure conditions from the initial fault simulation verification task.

[0152] The de-triggered verification task retains the basic read / write access patterns, access address ranges, health status acquisition cycles, and data verification methods from the initial fault simulation verification task, while canceling or reducing the trigger conditions directly corresponding to the locked fault hypothesis nodes. For media degradation hypothesis nodes, the de-triggered verification task reduces random write intensity or shortens the duration of high-pressure writes; for read interference anomaly hypothesis nodes, the de-triggered verification task reduces the number of high-frequency read accesses or increases the read interval; for write amplification anomaly hypothesis nodes, the de-triggered verification task cancels frequent switching between small-block random writes and sequential writes; for power-down recovery anomaly hypothesis nodes, the de-triggered verification task cancels power-down triggers during the write process; for temperature deceleration anomaly hypothesis nodes, the de-triggered verification task restores the temperature and pressure range to the normal temperature test range; for interface communication anomaly hypothesis nodes, the de-triggered verification task reduces the command queue depth or cancels interface bandwidth pressure; for firmware response anomaly hypothesis nodes, the de-triggered verification task cancels abnormal command combinations, retaining only standard status query commands and basic read / write commands.

[0153] The same-condition review task and the trigger-free review task are executed sequentially, and the same-condition review response data and trigger-free review response data are collected according to the same health status acquisition cycle as the first fault simulation verification task. The same-condition review response data and trigger-free review response data are aligned with the health baseline response trajectory according to the timestamp, and the same-condition review deviation sequence and trigger-free review deviation sequence are generated respectively.

[0154] The first response deviation sequence, the same condition check deviation sequence, and the detriggered check deviation sequence are compared to determine the observability and repeatability of the locked fault hypothesis node.

[0155] In this embodiment, the formula for calculating the repeatability value is expressed as follows:

[0156] ;

[0157] in, Indicates the first The repeatability value of a locked fault hypothesis node. Indicating the first fault simulation verification task Anomaly observation markers for a locked fault hypothesis node. Indicating the first conditional review task Anomaly observation markers for a locked fault hypothesis node.

[0158] When an abnormal observation window appears in the corresponding task, the abnormal observation flag is set to 1; when no abnormal observation window appears in the corresponding task, the abnormal observation flag is set to 0.

[0159] The formula for calculating observability values ​​is expressed as:

[0160] ;

[0161] in, Indicates the first The observability value of a locked fault hypothesis node. Indicating the first fault simulation verification task The combined deviation of the locked fault hypothesis node from the mean among the nodes within the anomaly observation window. This indicates that the first step in triggering the review task will be performed. The combined deviation of a locked fault hypothesis node from the mean of nodes within the corresponding time window.

[0162] The verification results of the locked fault hypothesis nodes are determined based on repeatability and observability values.

[0163] The observability threshold is set. Specifically, it is obtained by the mass production testing platform through offline calibration based on the percentage decrease in the overall node deviation before and after the de-triggering review task for historical qualified samples, occasional abnormal samples, and confirmed fault samples. Specifically, the observability value boundary that can distinguish between observable fault samples that "reach the observability threshold" and non-related abnormal samples that "do not change significantly after the triggering condition is canceled" is selected as the observability threshold. The value range is usually 0.30~0.60.

[0164] When the repeatability value is 1 and the observability value reaches the observability threshold, the locked fault hypothesis node is determined to be observable and repeatable.

[0165] When the repeatability value is 0, the locked fault hypothesis node is determined to be an occasional anomaly.

[0166] When the repeatability value is 1, but the observability value does not reach the observability threshold, it is determined that the abnormal response is not sufficiently associated with the triggering conditions of the locked fault hypothesis node, and the SSD under test is marked as an object to be further re-examined.

[0167] A health risk level is generated based on the verification results of the locked fault hypothesis nodes.

[0168] The health risk levels include health pass, occasional concern, repeatable risk, suspected failure, and confirmed malfunction.

[0169] When no abnormal observation window is detected, the health risk level is "healthy and passed"; when an abnormal observation window is detected but the repeatability value is 0, the health risk level is "occasional concern"; when the repeatability value is 1 and the observability value reaches the observability threshold, the health risk level is "repeatable risk"; when multiple locked fault hypothesis nodes, such as 7 fault hypothesis nodes, are all determined to be observable and repeatable, the health risk level is "suspected failure"; when an abnormal observation window is accompanied by data consistency verification failure, unrecoverable read error, or power-off recovery failure, the health risk level is "fault confirmed".

[0170] Displays the anomaly observation window, response deviation sequence, conditional verification deviation sequence, detrimental verification deviation sequence, repeatability value, observability value, and health risk level, and receives interactive confirmation from testers regarding the health risk level.

[0171] Testers can confirm the health risk level, request a re-execution of the review task, or mark the SSD under test as a candidate for manual review.

[0172] S7. Based on the observability and repeatability results, data consistency verification results, and interactive confirmation results, generate an SSD mass production release decision.

[0173] After completing the same-condition verification task and the trigger-free verification task, the mass production testing platform reads the observability results, repeatability results, data consistency verification results, and interactive confirmation results of the locked fault hypothesis nodes.

[0174] For each locked fault hypothesis node, a node adjudication dataset is established. The node adjudication dataset includes the fault hypothesis node identifier, fault hypothesis node type, observability value, repeatability value, data consistency anomaly flag, number of anomaly observation windows, anomaly observation window duration, response deviation sequence, results of the same-condition review task, results of the de-triggered review task, and interactive confirmation flag.

[0175] The data consistency anomaly flag is determined based on the data consistency verification results. When the verification value of the written test data matches the verification value of the read test data, the data consistency anomaly flag is set to 0; when the verification value of the written test data does not match the verification value of the read test data, the data consistency anomaly flag is set to 1. The interaction confirmation flag is determined based on the confirmation operation received from the tester. When the tester confirms the health risk level generated by the system, the interaction confirmation flag is set to 1; when the tester requests manual re-checking or refuses confirmation, the interaction confirmation flag is set to 0.

[0176] The decision risk value of the fault hypothesis node is calculated based on the observability results, repeatability results, and data consistency verification results.

[0177] Among them, the adjudication risk value is used to indicate the degree of impact of the locked faulty hypothetical node on the current mass production release result of the SSD under test.

[0178] The risk value for adjudication is expressed as:

[0179] ;

[0180] in, Indicates the first The risk value of the decision for a locked faulty node. Indicates the first A data consistency anomaly flag corresponding to a locked faulty node.

[0181] The node's adjudication status is generated based on the adjudication risk value, data consistency anomaly flag, and interaction confirmation flag.

[0182] The node adjudication status includes four states: node approved, node on watch, node under review, and node isolated.

[0183] When the If no abnormal observation window appears for a locked fault hypothesis node, or if the adjudication risk value is lower than the attention threshold, the corresponding fault hypothesis node will be marked as node pass.

[0184] When the When a locked fault hypothesis node has an abnormal observation window, but the repeatability value is 0 and the data consistency anomaly is marked as 0, the corresponding fault hypothesis node will be marked as a node of interest.

[0185] When the When a locked fault hypothesis node has a repeatability value of 1 and an observability value that reaches the observability threshold, the corresponding fault hypothesis node is marked as a node for re-examination.

[0186] When the If a locked fault hypothesis node is marked as having a data consistency anomaly, or if the corresponding fault hypothesis node is associated with an unrecoverable read error, power failure recovery failure, or a persistent firmware error return code, the corresponding fault hypothesis node will be marked as a node isolated.

[0187] It should be noted that the attention threshold is determined by the mass production testing platform based on the distribution of adjudication risk values ​​of historical qualified SSDs of the same model, firmware version, and flash memory type under the same fault simulation verification task. The upper quantile of the adjudication risk value of historical qualified samples, such as 95%, is taken as the attention threshold, and the value range is usually 0.30~0.60. The observability threshold is determined by the mass production testing platform based on the decrease ratio of the node comprehensive deviation value of historical abnormal SSDs in the de-triggered review task. The minimum decrease ratio that can distinguish between real triggered abnormalities and occasional fluctuation abnormalities is taken as the observability threshold, and the value range is usually 0.40~0.70.

[0188] After generating the node decision status for each locked faulty hypothetical node, an SSD mass production release decision is generated based on the decision status of all nodes.

[0189] SSD mass production release decisions include qualified release, downgraded release, key sampling inspection, rework testing, fault isolation, and batch warning.

[0190] Specifically, when all locked fault assumption nodes are passed and the data consistency verification results are all normal, a qualified release decision is generated.

[0191] When at least one locked faulty hypothetical node is of concern, but there is no node re-inspection or node isolation, a downgraded release decision or a key sampling decision is generated. Specifically, if the number of abnormal observation windows corresponding to the node's concern status is lower than the concern window number threshold, a downgraded release decision is generated; if the number of abnormal observation windows corresponding to the node's concern status reaches the concern window number threshold, a key sampling decision is generated.

[0192] A rework test decision is generated when at least one locked faulty assumption node is a node re-inspection and there is no node isolation.

[0193] A fault isolation decision is generated when at least one locked fault assumption node is isolated from the node.

[0194] Read the node adjudication status of multiple SSDs under test within the same mass production batch. If SSDs under test that have reached the batch statistical quantity threshold within the same mass production batch are marked as node re-inspection or node isolation under the same fault assumption node, a batch warning mark is generated, and the SSD mass production release adjudication is adjusted to a batch warning adjudication.

[0195] It should be noted that the threshold for the number of attention windows is determined by the mass production testing platform based on the health status acquisition cycle, the duration of the fault simulation verification task, and the abnormal persistence characteristics of the corresponding fault hypothesis node. The number of windows corresponding to the number of consecutive abnormal observation windows reaching the preset duration requirement is taken as the threshold for the number of attention windows, and the value range is usually 2 to 5 consecutive test time windows. The threshold for the number of batch statistics is determined by the mass production testing platform based on the total number of tests and quality sampling rules of the same mass production batch. The minimum number of abnormal SSDs that can reflect the batch concentration of abnormalities is taken as the threshold for the number of batch statistics, which is 3 to 10 SSDs to be tested.

[0196] Based on the adjudication status of the SSD nodes under test using the same mass production annotation, the batch anomaly ratio is calculated and expressed as follows:

[0197] ;

[0198] in, Indicates the first The percentage of batch anomalies within the same mass production batch, based on the assumption of a fault node. Indicates the first in the same production batch The number of SSDs under test marked for node re-inspection under each fault hypothesis node. Indicates the first in the same production batch The number of SSDs under test marked as node isolation under each fault hypothesis node. This indicates the total number of SSDs under test that have completed fault simulation verification within the same mass production batch.

[0199] The basis for the decision should be shown to the testers before generating the SSD mass production release decision.

[0200] The criteria for adjudication include locked fault hypothesis nodes, abnormal observation windows, response deviation sequences, results of the same-condition review task, results of the de-triggered review task, observability values, repeatability values, data consistency verification results, and batch anomaly ratios.

[0201] Testers perform confirmation operations, manual re-inspection operations, or note input operations.

[0202] The confirmation operation is used to confirm the SSD mass production release decision generated by the mass production test platform; the manual re-inspection operation is used to mark the current SSD under test as a manual re-inspection object; and the remarks input operation is used to record the tester's description of the cause of the anomaly, the test environment, or the status of the test station.

[0203] When the interactive confirmation result is a confirmation operation, the proposed SSD mass production release decision will be determined as the final SSD mass production release decision.

[0204] When the interactive confirmation result is a manual re-inspection operation, the final SSD mass production release decision will be determined as a key sampling inspection or rework inspection, and a manual re-inspection mark will be written into the health management traceability record.

[0205] When the interactive confirmation result is a note input operation, the note content will be bound to the final SSD mass production release decision and stored.

[0206] S8. Finally, the fault hypothesis map, fault simulation verification task, response deviation sequence, review task results, and mass production release decision are written into the health management traceability record.

[0207] After the final SSD mass production release decision is generated, a health management traceability record is established that uniquely corresponds to the identification information of the SSD under test.

[0208] The health management traceability record includes at least the device identification information, capacity specification, firmware version, flash memory chip type, interface protocol type, mass production batch information, test station number, fault hypothesis map, locked fault hypothesis nodes, fault simulation verification task, response deviation sequence, anomaly observation window, same-condition review task results, de-triggered review task results, observability results, repeatability results, data consistency verification results, interactive confirmation results, node adjudication status, SSD mass production release adjudication, and record generation time.

[0209] Record segments are generated for the fault hypothesis map, fault simulation verification task, response deviation sequence, verification task results and SSD mass production release decision, and the record segments are established into a record chain according to the test process sequence.

[0210] Specifically, the fault hypothesis map is written into the first recording segment, the fault simulation verification task is written into the second recording segment, the response deviation sequence and anomaly observation window are written into the third recording segment, the results of the same-condition verification task and the results of the de-triggered verification task are written into the fourth recording segment, and the final SSD mass production release decision and interactive confirmation results are written into the fifth recording segment.

[0211] To prevent health management traceability records from being mistakenly altered or omitted later, a segment verification value can be generated for each record segment, and the segment verification value of the current record segment can be associated with and stored with the segment verification value of the previous record segment.

[0212] The segment checksum can be obtained by hashing the field content of the current record segment, the record generation time, the identification information of the SSD device under test, and the segment checksum of the previous record segment.

[0213] The health management traceability records are stored in the local database of the mass production test platform, the manufacturing execution system database, or the quality traceability database. The record index is mapped to the identification information of the SSD under test, the mass production batch information, and the firmware version. The final SSD mass production release decision and the health management traceability record index are displayed. Testers can query the health management traceability records by device identification information, mass production batch information, firmware version, or fault assumption node type.

[0214] In this embodiment, Figure 5 The changes in the overall deviation value of nodes are shown under the initial fault simulation verification task, the same condition review task, and the de-triggered review task.

[0215] Depend on Figure 5 As can be seen, in the initial stage of testing, the overall node deviation values ​​for all three task groups were at a low level, indicating that the SSD under test had little difference from the healthy baseline response trajectory before a significant abnormal response was formed. As the fault simulation verification task continued to execute, the overall node deviation value of the first fault simulation verification task gradually increased and exceeded the node deviation threshold within subsequent test time windows, indicating that the locked fault hypothesis node had formed an observable anomaly. The curve trend of the same-condition verification task was basically consistent with that of the first fault simulation verification task, and it also exceeded the node deviation threshold, indicating that the abnormal response was not a random fluctuation, but rather repeatable under the same fault simulation conditions. In contrast, after canceling or reducing the trigger conditions, the node deviation value of the de-triggered verification task remained in a low range and did not reach the node deviation threshold, indicating a clear correlation between the abnormal response and the locked fault hypothesis node.

[0216] The results demonstrate that this solution can distinguish between real-world fault risks and occasional test fluctuations through a closed-loop verification method of "initial verification - same-condition review - de-trigger review", thereby improving the reliability of SSD mass production fault simulation verification results.

[0217] In this embodiment, Figure 6 The comparison between this solution and the traditional fixed threshold detection method in identifying the batch anomaly ratio within the same mass production batch is shown.

[0218] Depend on Figure 6As the number of SSDs undergoing fault simulation verification increases, this solution can identify anomalous samples marked for node re-inspection or node isolation earlier, and bring the batch anomaly ratio closer to or above the batch warning ratio line more quickly. In contrast, traditional fixed-threshold detection methods, relying primarily on a single indicator or fixed threshold, are relatively slow in identifying early anomalies, re-verification anomalies, and batch-wide anomalies, resulting in a consistently low batch anomaly ratio. This difference indicates that this solution does not rely solely on a single test result for release decisions, but rather incorporates observability results, repeatability results, data consistency verification results, and interactive confirmation results into the node decision status, and further statistically analyzes the re-inspection and isolation status under the same fault assumption node within the same mass production batch. When the batch anomaly ratio reaches the warning condition, the system can promptly generate a batch warning decision, thereby preventing SSDs with common risks from flowing into subsequent stages.

[0219] The results demonstrate that this solution has stronger batch risk detection and quality traceability capabilities in mass production scenarios, which helps improve the accuracy and stability of SSD release decisions.

[0220] This embodiment also provides a computer device applicable to the fault simulation verification method for SSD mass production, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the fault simulation verification method for SSD mass production as proposed in the above embodiment.

[0221] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0222] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the fault simulation verification method for SSD mass production as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0223] In summary, this invention achieves proactive and targeted simulation verification of potential SSD failure modes by generating a failure hypothesis map and locking failure hypothesis nodes to generate failure simulation verification tasks; it achieves quantitative measurement of the degree of deviation from the health status by collecting actual operating response data and generating a health baseline response trajectory, and obtaining a response deviation sequence after timestamp alignment; it achieves systematic judgment of the causal relationship between abnormal response and failure triggering conditions by generating same-condition verification and de-trigger verification tasks and determining observability and repeatability; and it achieves closed-loop management and traceability of the entire process from failure hypothesis to release decision by comprehensively considering observability, repeatability, data consistency, and interactive confirmation results to generate a mass production release decision and writing it into the health management traceability record.

[0224] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A fault simulation verification method for SSD mass production, characterized in that, include: Acquire basic data and initial health status data of the SSD under test, and generate a fault hypothesis graph consisting of fault hypothesis nodes and fault-related edges; Receive the lock operation of the test personnel on the fault hypothesis node and generate a fault simulation verification task; The operating status of the SSD under test is disturbed according to the fault simulation verification task, and the actual operating response data is collected. Based on the basic data of the SSD under test and the fault simulation verification task, a health baseline response trajectory is generated. The actual operational response data and the health baseline response trajectory are timestamped to obtain the response deviation sequence; When the response deviation sequence meets the abnormal observation conditions, generate a verification task with the same conditions and a de-triggering verification task to determine the observability and repeatability of the locked fault hypothesis node. Based on the observability and repeatability results, data consistency verification results, and interactive confirmation results, an SSD mass production release decision is generated. Finally, the fault hypothesis map, fault simulation verification task, response deviation sequence, review task results, and mass production release decision are written into the health management traceability record.

2. The fault simulation verification method for SSD mass production as described in claim 1, characterized in that, The generation of the fault hypothesis graph, consisting of fault hypothesis nodes and fault-related edges, includes: Connect the SSD to be tested to the mass production testing station; The mass production testing platform identifies the SSD under test through the interface protocol and reads the basic data and initial health status data of the SSD under test. Based on the basic data and initial health status data, the following hypothetical nodes are generated: media degradation hypothesis node, read interference anomaly hypothesis node, write amplification anomaly hypothesis node, power failure recovery anomaly hypothesis node, temperature drop anomaly hypothesis node, interface communication anomaly hypothesis node, and firmware response anomaly hypothesis node. Based on the triggering relationship, accompanying relationship or causal relationship between different fault hypothesis nodes, fault association edges are generated, and the corresponding fault association edges are retained when the edge association value reaches the association threshold, thus forming a fault hypothesis graph.

3. The fault simulation verification method for SSD mass production as described in claim 1 or 2, characterized in that, The fault simulation verification task includes: Display the failure hypothesis map and show the node risk value for each failure hypothesis node; Based on the node risk value, the system receives locking, canceling, or combined operations performed by testers on the fault hypothesis node, and identifies the locked fault hypothesis node as the target node for entering the fault simulation verification. Based on the locked fault hypothesis nodes, generate a fault simulation verification task; The fault simulation verification task includes simulating fault type, read / write access mode, command queue depth, access address range, power failure trigger time, temperature and pressure range, interface communication disturbance conditions, data verification method, health status acquisition cycle, and counterfactual verification conditions. When testers identify more than two fault hypothesis nodes, the execution order of fault simulation verification tasks is determined based on the fault association edges, or a fault simulation verification task queue is generated in descending order of node risk values.

4. The fault simulation verification method for SSD mass production as described in claim 1, characterized in that, The steps for performing operational state disturbances on the SSD under test according to the fault simulation verification task and collecting actual operational response data are as follows: The fault simulation verification task is analyzed to determine the simulated fault type of the SSD under test; Based on the type of simulated fault, the fault simulation verification task is converted into test control instructions; The test control instructions include at least one of the following: read / write control instructions, access address control instructions, command queue control instructions, temperature and pressure control instructions, power-down control instructions, interface communication pressure control instructions, and firmware command detection instructions. The test control instructions are used to perform operational state disturbances on the SSD under test, and actual operational response data is collected during the operational state disturbance process according to the health status acquisition cycle. For each actual operational response data point, add a collection timestamp, a fault simulation verification task identifier, a locked fault hypothesis node identifier, and a test station identifier, and generate an actual operational response sequence according to the collection timestamp.

5. The fault simulation verification method for SSD mass production as described in claim 1 or 4, characterized in that, The generated health baseline response trajectory includes: Based on the basic data, initial health status data, and fault simulation verification tasks of the SSD under test, a set of qualified samples matching the current SSD under test is selected from the qualified sample data of the mass production test platform. Based on the fault simulation verification task, historical response data corresponding to the simulated fault type, basic data and health status collection cycle are extracted from the qualified sample set to form a candidate baseline response data set. Based on the initial health status data of the SSD under test, the status of the candidate benchmark response data set is corrected; The status correction includes at least one of capacity correction, temperature correction, write / erase cycle correction, and firmware version correction; A health baseline response trajectory is generated based on the candidate baseline response data set after state correction, and each health baseline response value in the health baseline response trajectory is added with the same timestamp as the actual running response data.

6. The fault simulation verification method for SSD mass production as described in claim 5, characterized in that, Each health baseline response value is added with the same timestamp as the actual operational response data, including: Read the collection timestamp, fault simulation verification task identifier, locked fault hypothesis node identifier, and health indicator type from the actual operation response data; Read the baseline timestamp, fault simulation verification task identifier, and health indicator type from the health baseline response trajectory; Using the start time of the fault simulation verification task as a unified time zero point, the actual operation response data and the health baseline response trajectory are converted to the same test time axis; For health indicators with completely consistent timestamps, establish a correspondence between the actual operational response value and the health baseline response value; For health indicators with inconsistent timestamps, the health status collection period is used as the basic time window, and the actual operating response value and the health benchmark response value within the same basic time window are grouped into the same response comparison unit. Response control data is generated based on the response control unit, and the response deviation value is calculated based on the response control data. The response deviation sequence is generated according to the order of the test time window.

7. The fault simulation verification method for SSD mass production as described in claim 1, characterized in that, The determination of the observability and repeatability of the locked fault hypothesis node includes: Determine whether the abnormal observation conditions are met based on the response deviation sequence and the comprehensive deviation value of the nodes; The abnormal observation conditions include at least one of single-index abnormal conditions, node-comprehensive abnormal conditions, and continuous window abnormal conditions. When the response deviation sequence meets the abnormal observation conditions, the abnormal observation window is recorded, and a verification task under the same conditions and a trigger verification task are generated based on the locked fault hypothesis node corresponding to the abnormal observation window. Perform the same-condition review task and the de-trigger review task, and collect the same-condition review response data and the de-trigger review response data according to the same health status collection cycle as the first fault simulation verification task; Align the same-condition review response data and the de-triggered review response data with the health baseline response trajectory according to the timestamp to generate the same-condition review deviation sequence and the de-triggered review deviation sequence; By comparing the first response deviation sequence, the same condition check deviation sequence, and the detriggered check deviation sequence, the observability and repeatability of the locked fault hypothesis node are determined.

8. The fault simulation verification method for SSD mass production as described in claim 1, characterized in that, The generated SSD mass production release decision includes: Read the observability results, repeatability results, data consistency verification results, and interactive confirmation results of the locked fault hypothesis nodes, and establish a node adjudication data set for each locked fault hypothesis node. Based on the observability results, repeatability results, and data consistency verification results, calculate the adjudication risk value of the locked fault hypothesis node; Based on the adjudication risk value, data consistency anomaly flag, and interaction confirmation flag, generate the node adjudication status of the locked fault hypothesis node; The node adjudication status includes node approved, node under observation, node re-inspection, and node isolated; Based on the node decision status of all locked fault hypothesis nodes, generate an SSD mass production release decision; The SSD mass production release decision includes qualified release, downgraded release, key sampling inspection, rework inspection, fault isolation, and batch warning; Before generating the SSD mass production release decision, the basis for the decision is shown to the testers, and the final SSD mass production release decision is determined based on the testers' confirmation.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the fault simulation verification method for SSD mass production as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the fault simulation verification method for SSD mass production as described in any one of claims 1 to 8.

Images