A method for verifying mean time between failures of a solid state drive

Abstract

The application relates to the technical field of data storage, and discloses a verification method for mean time between failures of a solid state disk, which comprises the following steps: initializing a test environment of the solid state disk; constructing a dynamic comprehensive stress model; calculating an acceleration factor based on adaptive parameters of reliability; in a test process, increasing the acceleration factor, cyclically switching different read-write load combinations according to a set time slice, and accelerating the test of the solid state disk; judging whether the test reaches a preset time length or triggers a failure condition; if yes, analyzing solid state disk failure diagnosis and data analysis; and if no, returning to continue accelerating the test of the solid state disk. Through the construction of the dynamic comprehensive stress model, the method combines temperature stress, voltage stress and read-write load stress and other multidimensional stresses, breaks through the limitation of traditional test methods which only apply single static high-temperature stress, realizes comprehensive stress testing of the solid state disk, and improves the comprehensiveness and accuracy of the test.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method for verifying the mean time between failures (MTBF) of a solid-state drive (SSD). Background Technology

[0002] With the rapid development of information technology, solid-state drives (SSDs), as a new type of storage medium, have gradually replaced traditional hard disk drives (HDDs) as the mainstream application product in the storage field due to their faster read / write speeds, lower power consumption, and stronger shock resistance. They are widely used in personal computers, enterprise data centers, and big data processing. However, in the production and use of SSDs, evaluating their reliability and performance is a crucial step in ensuring product quality. Currently, SSD testing typically involves a full disk scan to check the drive's read / write capabilities and the health status of the storage units. This method mainly relies on sequential and random read / write tests to simulate various real-world application scenarios. However, traditional testing methods have some shortcomings, such as limited test stimuli, incomplete failure mode coverage, and the ability to apply only static high-temperature stress, representing a single environmental stress.

[0003] Furthermore, during the use of solid-state drives (SSDs), write operations can cause flash memory wear, thus affecting device performance and energy efficiency. The write / erase performance evaluation of SSDs is particularly important in high-temperature environments, as high temperatures can trigger failures during the write / erase process. However, existing testing methods often neglect the impact of environmental factors such as temperature on drive performance and fail to comprehensively simulate the performance of drives in different physical regions. These issues lead to biased test results, affecting the accuracy of performance test results. Summary of the Invention

[0004] This invention provides a method for verifying the mean time between failures (MTBF) of a solid-state drive (SSD), which can solve some shortcomings of traditional testing methods, such as single test stimulus, incomplete coverage of failure modes, and the inability to apply only static high-temperature stress, which is a technical problem of single environmental stress.

[0005] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: to provide a method for verifying the mean time between failures (MTBF) of a solid-state drive, the method comprising:

[0006] Initialize the test environment for the solid-state drive;

[0007] A dynamic integrated stress model is constructed, and an acceleration factor is calculated based on adaptive parameters of reliability. During the test, the acceleration factor is increased and different read / write load combinations are cyclically switched according to the set time slices to accelerate the test of solid-state drives.

[0008] Determine whether the test has reached the preset duration or triggered a fault condition;

[0009] If yes, proceed with SSD fault diagnosis and data analysis; otherwise, return to continue accelerating the SSD test.

[0010] The beneficial effects of this invention are as follows: By constructing a dynamic comprehensive stress model, combining multi-dimensional stresses such as temperature stress, voltage stress, and read / write load stress, it overcomes the limitations of traditional testing methods that only apply a single static high-temperature stress, achieving comprehensive stress testing of solid-state drives (SSDs) and improving the comprehensiveness and accuracy of the tests; Employing a multi-source data synchronous acquisition system, it achieves in-depth monitoring and dynamic analysis of the internal state of SSDs by real-time acquisition and analysis of multi-dimensional information such as BIT logs, SMART data, and performance data, improving the real-time performance and diagnostic capabilities of the tests; Based on Weibull analysis and degradation trajectory analysis of degradation data, it abandons the traditional "0 / 1" MTBF calculation model, achieving accurate simulation and lifespan prediction of SSD performance degradation processes, providing more reliable data support for product improvement and maintenance; Through automated scripts and platforms, it automates the execution of the testing process and data analysis, improving testing efficiency and consistency, reducing the possibility of human intervention, and ensuring the accuracy and reliability of test results; Through a comprehensive fault definition and diagnostic mechanism, it can not only determine whether a product is qualified, but also reveal how and why it failed, providing comprehensive diagnosis and guidance for product quality improvement. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the verification method for the mean time between failures (MTBF) of a solid-state drive according to the first embodiment of the present invention.

[0012] Figure 2 yes Figure 1 A flowchart illustrating step 1.

[0013] Figure 3 yes Figure 1 A flowchart illustrating step 2.

[0014] Figure 4 yes Figure 1 A flowchart illustrating step 3.

[0015] Figure 5 yes Figure 1 A flowchart illustrating step 4. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0017] The terms "comprising" and "having," and any variations thereof, used in this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0018] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0019] Figure 1 This is a flowchart illustrating the verification method for the mean time between failures (MTBF) of a solid-state drive according to the first embodiment of the present invention. Figure 1 As shown, the system includes hardware and software components:

[0020] Step 1: Initialize the test environment for the solid-state drive;

[0021] Step 2: Construct a dynamic integrated stress model, calculate the acceleration factor based on the adaptive parameters of reliability, increase the acceleration factor during the test, and cycle through different read and write load combinations according to the set time slices to accelerate the test of the solid-state drive.

[0022] Step 3: Determine whether the test has reached the preset duration or triggered the fault condition;

[0023] Step 4: If yes, analyze the SSD fault diagnosis and data analysis; if no, return to continue accelerating the SSD test.

[0024] Step 1: SSD Test Environment Initialization. Hardware Setup: The test host must have a CPU of at least Intel i7-12700K and at least 32GB of DDR4 memory, and the hard drive interface must support SATA 3.0 or NVMe PCIe 4.0. For data comparison, the host must have at least two target interfaces, one for the SSD under test and one for the benchmark SSD. For the SSD under test, its model, capacity, interface type (SATA or NVMe), and factory firmware version must be recorded in advance. Before testing, a full disk erase must be performed using manufacturer-specific tools such as Samsung Magician to remove initial data interference with the test results. Auxiliary equipment includes a multi-channel power supply with an output voltage of 3.3V / 5V and an accuracy of ±0.01V, and a temperature controller with a temperature control range of 0-85℃. During connection, a current monitoring module should be connected in series between the power supply and the SSD to collect power consumption data in real time. Simultaneously, a temperature sensor should be attached to the surface of the SSD's controller chip to ensure accurate monitoring of the core temperature.

[0025] Software environment configuration: For testing tools, versions 3.35 and above of FIO, CrystalDiskMark Professional, and SSD Life Pro are required to meet performance testing needs across different dimensions. Monitoring software needs to include HWInfo64 and Wireshark. HWInfo64 is used for real-time monitoring of SSD temperature, power consumption, and SMART parameters, while Wireshark captures NVMe or SATA protocol frames for subsequent protocol-level fault analysis. For data storage, a local MySQL 8.0 database needs to be set up and configured to automatically store test data every 10 seconds. Stored data includes key metrics such as IOPS, latency, and error rate, providing a foundation for subsequent data analysis.

[0026] Environmental stress parameter initialization: The initial temperature stress is set to 55℃ (simulating normal operating conditions), while the ambient humidity is controlled between 40% and 60% to avoid condensation caused by excessive humidity affecting the normal operation of the equipment. Power supply stress needs to be configured differently according to the SSD interface type: SATA SSDs require a power supply voltage of 3.3V±5%, while NVMe SSDs must simultaneously meet the power supply requirements of 12V±5% and 3.3V±5%. In the pre-loading process, 10 rounds of full-capacity sequential write operations are performed, with the corresponding FIO parameters set to a block size of 128M, a read / write mode of pure write, and a queue depth of 32. This operation allows the SSD to enter a stable operating state, eliminating the impact of initial state fluctuations on the test.

[0027] Step 2: Dynamic Integrated Stress Model Construction and Accelerated Testing. Multi-dimensional stress factors are defined as follows: Thermal stress uses the SSD master control temperature as the core parameter, ranging from 55℃ to 85℃. The accelerated correlation model adopts the Arrhenius model, where the activation energy Ea is set to 0.8eV and the Boltzmann constant k is 8.617e-5eV / K. Cyclic stress is indicated by the number of erase / write cycles (PE), with a rate controlled between 100-1000 cycles / hour. It is correlated with the Coffin-Manson model, where the exponent n is 4.5 and the fatigue limit ε_f' is 0.5. Load stress is measured by read / write load intensity (IOPS percentage), ranging from 30% to 100%. A custom load factor rule is used; when the load reaches 100%, the acceleration factor needs to be multiplied by 1.8 to improve testing efficiency.

[0028] Adaptive acceleration factor calculation logic: The formula for calculating the base acceleration factor (AF_base) is as follows: ,in This represents 25℃ room temperature. This is the actual test temperature. It is a standard PE rate. This is the accelerated PE rate. The dynamic adjustment rule needs to be combined with the test results of the previous time slice (usually set to 30 minutes): if there are no errors in the time slice (SMART error count is 0), the base acceleration factor for the next round is multiplied by 1.1, and the maximum is not more than 10; if 1-2 correctable errors occur, the base acceleration factor remains unchanged; if uncorrectable errors occur or the error rate exceeds 1e-6, the base acceleration factor is multiplied by 0.8, and the minimum is not less than 1.2, to ensure that the test is both efficient and accurately reflects the fault situation.

[0029] The time-slice load balancing scheme uses a 4-time-slice cycle, with each cycle lasting 2 hours. After each cycle, the load intensity for the next cycle is adjusted based on the base acceleration factor (AF_base). The first time slice is 30 minutes long, with random read / write load, FIO parameters corresponding to a block size of 4K, queue depth of 16, and a target IOPS of 80% of the peak. Monitoring focuses on random read latency and IOPS stability. The second time slice is also 30 minutes long, with random write load, FIO parameters of a 4K block size, queue depth of 32, and a target IOPS of 80% of the peak. Monitoring focuses on write amplification and garbage collection time. The third time slice is 30 minutes long, with mixed read / write load (read:write = 7:3), FIO parameters set to a block size of 128M and a queue depth of 8. The main focus is on sequential read / write throughput and power consumption fluctuations. The fourth time slice is 30 minutes long, with 100% TRIM operation load, FIO parameter block size of 128M, monitoring TRIM instruction response time and block erase efficiency.

[0030] Step 3: Test Termination Condition Judgment (Quantitative Standards) Preset Duration Termination: The preset duration for conventional life testing is 1000 hours, equivalent to 2-3 years of actual use after acceleration; for fault verification testing targeting specific failure modes, the preset duration is 200 hours. Test duration statistics are automatically generated through a local database. The cumulative test duration is the sum of the durations of each time slice. When the preset threshold is reached, the database will automatically trigger a termination reminder, notifying the tester to stop the current test.

[0031] Fault termination (stopping upon triggering any one of the following): Hardware faults are triggered by abnormal SMART parameters: seek error rate (parameter 0E) greater than 10, or the current number of sectors to be mapped (parameter C5) greater than 5. Detection is achieved through real-time monitoring using HWInfo64, with data refreshed every 5 seconds. Performance faults are judged when read / write latency increases by more than 200% from the initial value, or throughput decreases by more than 50% from the initial value. This is achieved through automatic comparison using FIO test reports. A performance difference is generated after each round of testing to determine whether a fault condition has been triggered. Data faults are triggered by one or more failed data integrity checks (MD5 comparison). The check process involves performing an MD5 check immediately after the test file is written, and then performing a second check after reading. Both checks must pass; failure in either step constitutes a data fault.

[0032] Step 4: Fault Diagnosis and Data Analysis (Output Report Framework) includes fault localization (multi-dimensional investigation): Hardware-level investigation requires disassembling the SSD and using a multimeter to test the power pin voltage to confirm whether it meets the standard 3.3V or 5V power supply requirements. Simultaneously, use an oscilloscope to observe the main control chip clock signal, checking for signal frequency stability and interference to determine if there is a physical hardware fault. Firmware-level investigation requires exporting the complete SMART log (including historical error records) and analyzing the correlation between the fault occurrence time and firmware operations (such as garbage collection and wear leveling). If firmware version issues are suspected, the SSD firmware can be rolled back to the factory version and the test re-executed to verify if the fault is due to firmware incompatibility. Protocol-level investigation requires parsing NVMe or SATA protocol frames captured by Wireshark, focusing on checking for protocol errors such as CRC check failures, and locating anomalies in the protocol interaction process.

[0033] Data Analysis (Core Outputs): Lifespan prediction is calculated as actual lifespan multiplied by the average acceleration factor (based on statistical results of the baseline acceleration factor during testing). The output is a lifespan curve, with the horizontal axis representing acceleration time and the vertical axis representing remaining lifespan, visually displaying the SSD's lifespan degradation trend. Failure Mode Statistics categorizes and statistically analyzes the percentage of hardware, firmware, and protocol failures (typically 35% hardware, 40% firmware, and 25% protocol). The output is a pie chart combined with Fault Tree Analysis (FTA), clearly presenting the distribution and causal relationships of various failure types. Performance Degradation Trend Analysis calculates the degradation rate of read / write latency and throughput in each 100-hour period, outputting a line graph with performance degradation inflection points marked, clearly identifying key time points for performance deterioration. Stress Impact Analysis compares the failure rates under different temperature and load conditions, generating stress-failure relationship curves through data fitting. The output is a 3D surface plot (X-axis for temperature, Y-axis for load, Z-axis for failure probability), quantifying the impact of stress parameters on failures.

[0034] Optimization Recommendations (Targeted Improvements): For hardware optimization, if troubleshooting reveals that overheating of the controller is the primary cause of the failure, it is recommended to add a heatsink to the SSD. An aluminum heatsink with a thickness of at least 1mm is recommended to improve heat dissipation efficiency and reduce temperature stress. For firmware optimization, addressing performance fluctuations caused by garbage collection, it is recommended to adjust the garbage collection (GC) trigger threshold in the firmware from the default 10% to 15% to reduce the impact of frequent GC on performance. For testing optimization, if transient failures occur during load switching, it is recommended to add a 5-second transition time during time slice switching to mitigate the impact of sudden load changes on the SSD and improve test stability.

[0035] Figure 2 yes Figure 1 The flowchart for step 1 is as follows: Figure 2 As shown, step 1 includes: Step 101, calculating the high temperature setpoint corresponding to the product category based on the Arrennis model according to the product category and target mean time between failures (MTBF) specification requirements of the solid-state drive; Step 102, setting the target temperature to the high temperature setpoint when the solid-state drive is in the constant temperature chamber; Step 103, building an automated test platform integrating a programmable power supply, a constant temperature chamber, and a host computer, and uniformly controlling the temperature of the constant temperature chamber and the rated output voltage of the programmable power supply through GPIB, LAN, or RS232 interfaces, and remotely starting and stopping the host computer.

[0036] Step 101: In calculating the high-temperature setpoints corresponding to product categories based on the Arrennis model, it is first necessary to clarify the product category of the solid-state drive (e.g., consumer-grade, industrial-grade, enterprise-grade) and the target mean time between failures (MTBF) specification. The MTBF requirements for different product categories vary significantly. For example, consumer-grade SSDs typically require an MTBF ≥ 500,000 hours, industrial-grade ≥ 1 million hours, and enterprise-grade ≥ 2 million hours. The calculation is based on the Arrennis model, using the activation energy... The parameter settings are 0.8 eV and Boltzmann constant k = 8.617e-5 eV / K. First, determine the parameters under normal operating conditions (e.g., 25℃). The baseline lifetime is 298.15K. (Typically, 1.2 times the MTBF of the product category is used, with a safety margin), and then the target life is determined based on the accelerated testing. (For example, in conventional life testing, the duration of accelerated testing needs to be controlled within 1000 hours, i.e.) =1000 hours), through the Arrhenius formula = ×exp [ / (k ) - / (k )] Reverse calculation of high temperature setpoint For example, if a certain industrial-grade SSD... =1.2 million hours (MTBF = 1 million hours), target =1000 hours, substituting into the formula, we can get ≈358.15K (i.e., 85℃), this temperature is the high-temperature setting for this type of product; if it is a consumer-grade SSD ( =600,000 hours), then the calculation yields The temperature is approximately 348.15K (i.e. 75℃), and needs to be dynamically adjusted according to the product category to match its reliability requirements.

[0037] According to the Arrhenius model, the acceleration factor AF = exp[( / k) (1 / T_use - 1 / T_stress)]. Wherein, Here, is the activation energy of the failure mechanism (e.g., 0.7 eV for NAND flash memory), k is the Boltzmann constant, T_use is the operating temperature (e.g., 40°C), and T_stress is the accelerated stress temperature. Based on the target MTBF and the room temperature testing duration, the required AF can be calculated, and then T_stress can be solved.

[0038] Step 102: In the target temperature setting and calibration of the constant temperature chamber, before placing the solid-state drive into the constant temperature chamber, the temperature of the constant temperature chamber needs to be calibrated: Place a temperature sensor of the same model as the surface of the SSD controller chip (accuracy ±0.1℃) into the test area inside the chamber to simulate the actual placement position of the SSD. Start the constant temperature chamber and initially set the target temperature to the high temperature set value calculated in step 101. After the temperature display inside the chamber stabilizes, compare the deviation between the actual temperature measured by the sensor and the set value. If the deviation exceeds ±1℃, the temperature control parameters (such as correcting the heating power and fan speed) need to be adjusted through the calibration function of the constant temperature chamber until the actual temperature matches the set value. After calibration, the SSD to be tested is fixed on the test bracket inside the constant temperature chamber, ensuring that the surface of its main control chip is in contact with the calibrated temperature sensor. After closing the constant temperature chamber door, the temperature control program is started—the heating rate is set to 5℃ / minute (to avoid sudden temperature rise that could damage the SSD components). Once the temperature reaches the target value, it is kept constant for 30 minutes to allow the overall temperature of the SSD to reach thermal equilibrium with the chamber environment. During this period, the temperature fluctuation is monitored through the real-time temperature feedback function of the constant temperature chamber to ensure that the fluctuation range is controlled within ±0.5℃, providing a stable thermal stress environment for subsequent accelerated testing.

[0039] Step 103: In the automated test platform setup and interface control, when building an automated platform integrating a programmable power supply, a constant temperature chamber, and a test host, the appropriate communication method must be selected based on the characteristics of the device interfaces: For the constant temperature chamber, a GPIB interface (high stability in laboratory settings, supports multi-device cascading) or a LAN interface (selected for remote control, compatible with TCP / IP protocol) is preferred. For the programmable power supply (output voltage 3.3V / 5V / 12V), an RS232 interface (short-distance point-to-point communication, simple and easy-to-debug protocol) or a LAN interface can be selected. The test host connects to the platform via a LAN interface for remote control. During connection, shielded cables must be used to reduce electromagnetic interference (especially for GPIB and RS232 interfaces), and an interface adapter (such as a GPIB-USB adapter) should be used to achieve compatible communication between devices with different interfaces and the host. At the platform control level, automated control scripts are written using Python's PyVISA library or LabVIEW software to achieve three main functions: First, temperature linkage control of the constant temperature chamber—the script can read the temperature data fed back by the constant temperature chamber in real time, and automatically issue temperature control commands to adjust if it deviates from the target value; second, precise regulation of the programmable power supply output voltage—the voltage parameters are preset according to the SSD interface type (SATA / NVMe), and the output current is monitored synchronously during the test. If overcurrent occurs, the power supply is automatically cut off and an alarm is triggered; third, remote start / stop and data synchronization of the host computer—the test program start / stop commands are sent to the host computer through the LAN interface, and the constant temperature chamber temperature, power output data and host test data (IOPS, latency) are synchronized to the local MySQL database in real time, realizing full automation of the "temperature control-power supply-testing-data storage" process and reducing human operation errors.

[0040] Specifically, the test host configuration (CPU ≥ Intel i7-12700K, memory ≥ 32GB DDR4, supports SATA3.0 / NVMe PCIe 4.0) needs to be connected to the LAN network of the automated platform built in step 103. The two reserved target interfaces are connected to the SSD under test and the benchmark SSD respectively, and both SSDs must be placed in the calibrated test area inside the constant temperature chamber to ensure a consistent thermal environment. After the model, capacity, and firmware version of the SSD under test are recorded, a full disk erase is performed by remotely calling the manufacturer's dedicated tool (such as Samsung Magician) through the host. During the erase process, the stability of the output voltage of the programmable power supply is monitored synchronously by the platform to avoid data residue caused by power supply fluctuations during the erase operation. The current monitoring module in the auxiliary equipment is integrated into the programmable power supply system, which can collect and store power consumption data in real time through automated scripts. Temperature sensor data is directly uploaded to the database by the constant temperature chamber control system without the need for additional manual recording.

[0041] Test tools (FIO 3.35+, CrystalDiskMark Professional Edition, SSD Life Pro) need to preset test parameter templates on the host. Template parameters (such as block size, queue depth) can be dynamically called according to the test stage through an automated control script; the data collection frequencies of the monitoring software HWInfo64 and Wireshark need to be synchronized with the platform control script (such as collecting once every 5 seconds) to ensure that the temperature, power consumption, protocol frame data, and test load switching time points are aligned. The MySQL 8.0 database needs to add a "platform device status table" to specifically store device operation data such as the temperature of the thermostat and the voltage / current of the programmable power supply, and associate it with the original "test performance data table" (IOPS, latency, etc.) through timestamps to achieve the linkage analysis of device status and test results.

[0042] The initial value of the temperature stress directly adopts the high-temperature set value calculated in step 101 (such as 85°C for industrial grade and 75°C for consumer grade), and the humidity control remains at 40% - 60%, which is automatically maintained by the humidity regulation module supporting the thermostat. The power stress configuration needs to be sent to the programmable power supply through an automated script: the SATA SSD corresponds to an output of 3.3V ± 5%, and the NVMe SSD corresponds to dual outputs of 12V ± 5% and 3.3V ± 5%. The script will compare the actual power output with the set value in real time and automatically correct it when the deviation exceeds ±0.01V. The 10-round full-capacity sequential write operation for preloading (FIO parameters: block size 128M, pure write mode, queue depth 32) is executed by remotely starting the FIO program on the host by the automated platform. After each round of operation, the script automatically checks whether the SSD has entered a stable state (the judgment criterion is that the write throughput fluctuation for two consecutive rounds ≤ 5%). After meeting the standard, it enters the subsequent acceleration test link.

[0043] The core parameter (controller temperature) of the thermal stress directly uses the high-temperature set value calculated in step 101 and does not need to be adjusted within the range of 55°C - 85°C. Only the temperature needs to be maintained stable through the thermostat control system; the parameter ranges and associated models (Coffin-Manson model, custom load factor) of the cyclic stress (PE rate 100 - 1000 times / hour) and load stress (IOPS ratio 30% - 100%) remain unchanged, but the parameter adjustment needs to be achieved through an automated script - for example, when the load factor needs to be multiplied by 1.8, the script automatically modifies the IOPS target value of FIO and sends it to the host.

[0044] The calculation of the basic acceleration factor (AF_base) is executed in real time by the script of the automated platform. The script will read the current test temperature ( , that is, the high-temperature set value), the normal PE rate ( ), accelerate PE rate ( The script automatically calculates AF_base using a formula combining Arrhenius and Coffin-Manson. The dynamic adjustment rules are also determined by the script: every 30 minutes (one time slice), the script reads the SMART error count and error rate data. If the "no error" condition is met, it automatically multiplies AF_base by 1.1 (not exceeding 10). If an uncorrectable error occurs, it multiplies by 0.8 (not less than 1.2). The adjusted AF_base is immediately synchronized to the "Platform Device Status Table" as the basis for the next round of load intensity adjustment.

[0045] The load switching across the four time slices requires no manual intervention and is automatically triggered by an automated script at a cycle of 30 minutes per slice. At the start of the first time slice, the script sends "random read" FIO parameters (block size 4K, queue depth 16, IOPS target 80% peak) to the host and simultaneously sends "maintain current parameters" commands to the temperature control chamber and the programmable power supply. One minute before the end of each time slice, the script preloads the load parameters for the next time slice. The switchover occurs immediately after the time slice expires. During the switchover process, the script synchronously monitors the SSD's response status (such as whether there is a momentary disconnection). If an anomaly occurs, the switchover is paused and an alarm is triggered.

[0046] The script monitors test termination conditions in real time. When the preset duration (1000 hours / 200 hours) is reached, the script automatically stops the host test program. When a fault condition (abnormal SMART parameters, performance degradation, data verification failure) is triggered, the script immediately cuts off the programmable power supply (to prevent further damage to the SSD) and generates a "draft fault report." The draft includes the time of the fault occurrence, the temperature of the constant temperature chamber at that time, and the power supply voltage data, providing a complete background of the equipment status for subsequent fault diagnosis. In the fault location and data analysis phase, the "Platform Equipment Status Table" and "Test Performance Data Table" can be directly retrieved from the database. By linking the equipment operating status and test results through timestamps, the cause of the fault can be located more accurately (such as whether the hardware fault is related to voltage fluctuations).

[0047] In the hardware optimization suggestions, if the main controller temperature is too high (only for special cases, such as abnormal temperature rise even under high temperature setpoint), in addition to recommending the addition of aluminum heat sinks, it is recommended to add a local cooling fan in the constant temperature chamber. The fan can be connected to the automation platform through the GPIB interface, and the script can automatically start and stop it according to the main controller temperature. In the test optimization suggestions, "add a 5-second transition time for load switching" can be set directly through the script. That is, when the load parameters are switched, the script will delay the issuance of the execution command by 5 seconds to mitigate the impact of sudden load changes.

[0048] Figure 3 yes Figure 1 The flowchart for step 2 is as follows: Figure 3 As shown, step 2 includes: Step 201, constructing a dynamic integrated stress model, obtaining read / write load combinations under different application scenarios based on the dynamic integrated stress model, wherein the dynamic integrated stress model includes temperature stress, voltage stress, and read / write load stress; Step 202, calculating the acceleration factor based on the adaptive parameters of reliability in the reliability analysis model, and correcting the acceleration factor by combining the coupling effect of temperature and voltage stress; Step 203, allocating the corrected acceleration factor to the read / write load combinations of each time slice, generating random read / write requests of corresponding intensity through I / O stress tools, and collecting the latency, throughput, and temperature data of the solid-state drive at the end of each time slice; Step 204, using machine learning algorithms to normalize and perform consistency analysis on the multi-platform test data, and identifying abnormal patterns where performance deviates from the threshold.

[0049] Step 201: In the construction of the dynamic integrated stress model and the design of scenario-based read / write loads, the dynamic integrated stress model uses the three-dimensional stress of "temperature-voltage-read / write load" as its core framework: temperature stress directly calls the product-specific high-temperature setpoint determined in Step 101, which is maintained stable by the constant temperature chamber control system. The model reads the main control temperature data fed back by the constant temperature chamber in real time (once every 2 seconds) to ensure that the temperature stress deviation from the setpoint is ≤±0.5℃; voltage stress is dynamically adjusted based on the SSD interface type, with SATA SSDs using 3.3V as the benchmark and NVMe SSDs using 12V+3.3V dual-path as the benchmark. The model collects the output voltage of the programmable power supply in real time through an automated script (accuracy ±0.01V). When the voltage fluctuation exceeds ±5%, a power calibration command is triggered to prevent the voltage stress from deviating from the preset range; read / write load stress is designed with differentiated combinations for different application scenarios— Consumer-level scenarios include "light office workload" (70% random reads, 30% sequential writes, average IOPS ≤ 5000) and "heavy gaming workload" (90% random reads and writes, 4K block size, average IOPS ≥ 15000). Enterprise-level scenarios include "database transaction workload" (mixed read / write 1:1, queue depth 32, average IOPS ≥ 30000) and "backup and archiving workload" (80% sequential writes, 128M block size, throughput ≥ 500MB / s). The model pre-sets these scenario-based workload combinations as a "load template library" for subsequent time slice switching.

[0050] Step 202: In the acceleration factor correction based on the reliability model and temperature-pressure coupling effect, the initial acceleration factor AF_init is calculated first using the "Arrhenius model (temperature) + Coffin-Manson model (cycle)" as the basic reliability analysis model: the temperature dimension follows the same approach. The parameters are 0.8eV and k = 8.617e-5eV / K, combined with the high temperature setpoint. Compared to normal temperature (25℃) Calculate the temperature acceleration factor AF_temp; the cycle dimension is based on the PE rate ( / The cycle acceleration factor AF_cycle is calculated using an exponent n=4.5, where AF_init=AF_temp×AF_cycle. Next, a voltage stress correction term AF_volt is introduced: when the voltage is within ±3% of the rated value, AF_volt=1.0 (no additional acceleration); when the voltage deviates from the rated value by 3%-5%, AF_volt=1.2 (voltage fluctuations accelerate device aging); when the voltage deviation exceeds 5%, AF_volt=0.8 (excessive voltage easily triggers protection, reducing effective acceleration). Finally, the coupling effect of temperature and voltage is considered: when the temperature ≥80℃ and the voltage deviation ≥3%, the coupling correction factor AF_couple=1.1 (voltage fluctuations at high temperatures enhance the failure-promoting effect); when the temperature ≤70℃ or the voltage deviation ≤2%, AF_couple=1.0. The final corrected acceleration factor AF_final=AF_init×AF_volt×AF_couple. For example, if an industrial-grade SSD has AF_init=8.0, a voltage deviation of 4% (AF_volt=1.2), and a temperature of 85℃ (AF_couple=1.1), then AF_final=8.0×1.2×1.1=10.56. The correction process is executed in real time by an automated script, which updates AF_final every 15 minutes based on the current temperature and pressure data and synchronizes it to the "Dynamic Stress Parameter Table".

[0051] Step 203: Time slice allocation and data collection for the corrected acceleration factor. AF_final is proportionally allocated to 4 test time slices (each 30 minutes). The allocation principle is that "the load intensity is positively correlated with AF_final": when AF_final ≤ 5, the IOPS target for each time slice is the base value of the scenario-based load template (e.g., for light office load, IOPS = 5000); when 5 < AF_final ≤ 10, the IOPS target is increased to 1.5 times the base value; when AF_final > 10, the IOPS target is increased to 1.8 times the base value (not exceeding 90% of the SSD peak IOPS to avoid hardware overload). The I / O stress tool FIO is selected, and the FIO instructions are dynamically generated by an automated script according to the allocation results. For example, in the first time slice (random read) when AF_final = 10.56, the block size is set to 4K, the queue depth is adjusted to 20, and the IOPS target is set to 1.8 times the base value (27000) of the "heavy game load". 5 seconds before the end of each time slice, the script triggers the data collection instruction: the average latency of the SSD (recorded separately for read / write), the instantaneous throughput are collected through HWInfo64, and the main control temperature is collected through the incubator sensor. The data collection frequency is 1 time / second, and the 5-second average value is taken as the core index of this time slice, and is written into the "test performance data table" of the MySQL database in real time, and is associated with the AF_final and temperature-pressure data in the "dynamic stress parameter table" through the time stamp to ensure the one-to-one correspondence of the "stress - performance" data.

[0052] Step 204: In the multi-platform data processing and anomaly identification based on machine learning, the multi-platform test data (such as data from three automated test platforms with the same configuration simultaneously testing the same model of SSD) is first preprocessed: the Min-Max normalization method is used to uniformly map indicators such as latency (unit: ms), throughput (unit: MB / s), and temperature (unit: ℃) to the [0,1] interval to eliminate dimensional differences; missing data is filled using linear interpolation, and outliers (such as a sudden increase in instantaneous latency to 1000ms) are removed using the 3σ principle. Next, consistency analysis is performed: a "platform consistency evaluation model" is constructed using the random forest algorithm, with the platform number as the feature and the normalized performance indicators as the label, to calculate the performance deviation rate between different platforms. If the deviation rate is ≤8%, the data is considered consistent and can be merged for analysis; if the deviation rate is >8%, the platform hardware differences (such as host interface bandwidth) are traced and recalibrated. Then, anomaly pattern recognition is performed: an "anomaly detection model" is constructed using an LSTM neural network. Taking the "temperature and pressure data + performance data" from the past 10 time slices as input, it predicts the performance index range for the next time slice. If the actual collected latency exceeds the upper limit of the prediction by 20%, or the throughput is lower than the lower limit of the prediction by 20%, or the temperature fluctuation exceeds ±3℃, it is identified as a "performance deviation anomaly." Simultaneously, a support vector machine (SVM) model is trained to identify "precursor anomalies" (such as a sudden increase in latency fluctuation frequency) based on historical fault data (such as performance characteristics before SMART errors). The anomaly identification results are fed back to the automation platform in real time, triggering audible and visual alarms and generating an "anomaly analysis report," which includes the time of the anomaly, the corresponding temperature and pressure stress, and the degree of performance deviation, providing direction for subsequent fault diagnosis.

[0053] In the hardware environment setup, the SSDs to be tested need to be placed according to application scenarios (consumer-grade / enterprise-grade partitioned testing) to ensure that SSDs in the same scenario share the same "load template library"; in the software environment configuration, the FIO tool needs to import the scenario-based load template in advance, and a new "machine learning result table" needs to be added to the MySQL database to store normalized data, consistency analysis results, and anomaly identification tags; in the environmental stress parameter initialization, the initial value of voltage stress needs to be aligned with the model reference voltage in step 201, and the temperature and pressure data of each of the 10 rounds of preloaded sequential write operations need to be recorded synchronously as the "initial normal samples" of the machine learning model.

[0054] The multi-dimensional stress factor definition directly adopts the three-dimensional framework of "temperature-voltage-read / write load" in step 201 without additional adjustments; the adaptive acceleration factor calculation logic is upgraded to a four-step correction process of "AF_init→AF_volt→AF_couple→AF_final", replacing the original basic adjustment rules; in the time-slice load cyclic switching scheme, the load parameters of the four time slices are no longer fixed, but are dynamically generated by the script according to AF_final allocated in step 203. During switching, the scenario-based parameters of the "load template library" are called synchronously to ensure that the load combination matches the application scenario.

[0055] The test termination condition has been updated to include "Machine Learning Anomaly Trigger": If "Pre-fault Anomaly" is identified for two consecutive time slices in step 204, the script will terminate the test early, even if the preset duration or hardware fault threshold has not been reached, to prevent irreversible damage to the SSD. In the fault diagnosis phase, the "Machine Learning Result Table" can be called to compare the changes in temperature and pressure stress before and after the anomaly (e.g., a sudden voltage deviation of 4% before the anomaly) to quickly locate the cause of the fault (e.g., a main control logic error caused by voltage fluctuations). In the data analysis phase, "Anomaly Pattern Statistics" needs to be added to calculate the anomaly occurrence rate under different scenarios and temperature and pressure conditions, providing data support for the optimization suggestions in step 4.3 (e.g., in enterprise-level scenarios, the anomaly rate is high when AF_final>10, so it is recommended to limit the maximum AF_final to 10).

[0056] In terms of hardware optimization, if machine learning identifies a significant increase in the anomaly rate (e.g., exceeding 20%) under "high temperature + high voltage" scenarios, it is recommended to add a "voltage buffer module" to the programmable power supply to control voltage fluctuations within ±2%. In terms of test optimization, if consistency analysis shows that the latency deviation of different platforms is mainly due to differences in FIO parameters, it is recommended to unify the FIO version of each platform (e.g., fix it to version 3.35) and lock the kernel parameters. In terms of model optimization, new fault data and anomaly samples should be injected into the machine learning model regularly to improve the anomaly recognition accuracy through incremental training (the goal is to increase it from the initial 85% to over 95%).

[0057] After step 204, the method includes: when an abnormal mode is identified, automatically triggering a dynamic adjustment mechanism for stress parameters to increase the voltage or temperature stress level to accelerate the exposure of potential defects; combining historical failure data with the current test status, updating the degradation parameters in the reliability prediction model, and ensuring that the test process is always on the optimal acceleration path through closed-loop feedback control.

[0058] Once an abnormal pattern is identified in step 204, the automated platform immediately triggers a dynamic stress parameter adjustment script. The adjustment strategy is designed based on the different types of abnormalities: If it is identified as a "performance deviation abnormality" (such as latency exceeding the predicted upper limit by 20%), a "mild enhancement" strategy is adopted—the temperature stress is increased by 3°C from the original high-temperature setting (such as industrial grade from 85°C to 88°C), and the voltage stress is increased by 1% deviation within the rated value ±5% (such as SATA SSD adjusted from 3.3V±4% to 3.3V±5%), to avoid the SSD being directly damaged by a sudden increase in stress; if it is identified as a "fault precursor abnormality" (such as a sudden increase in latency fluctuation frequency), a "moderate enhancement" strategy is adopted—the temperature is increased by 5°C (not exceeding the 90°C upper limit), and the voltage deviation is increased by 2% (not exceeding the 6% upper limit), to accelerate the exposure of potential defects. During the adjustment process, the script continuously coordinates with the programmable power supply and the constant temperature chamber: it sends new voltage output commands to the programmable power supply and simultaneously monitors output stability (deviation must be ≤ ±0.01V); it sends heating commands to the constant temperature chamber, controlling the heating rate to ≤ 2℃ / minute (to prevent thermal shock to components). Simultaneously, it collects feedback data in real time through the main control temperature sensor. If the temperature / voltage does not stabilize at the target value within 10 minutes after adjustment, the script automatically reverts to the parameters before adjustment and triggers an "adjustment anomaly" alarm. The adjusted stress parameters are written to the "Dynamic Stress Parameter Table" in real time, labeled "Adjusted after anomaly," leaving a record for subsequent data analysis.

[0059] After stress adjustment is executed, the automated platform initiates the reliability prediction model update process: First, it retrieves two types of core data from the MySQL database: one is historical failure data, including historical failure records of the same model of SSD (such as temperature and pressure stress when SMART errors occur, performance degradation curves), and reliability model parameters of historical tests (such as aging coefficients, failure thresholds); the other is current test status data, including performance indicators before and after the anomaly (latency, throughput attenuation rate), and real-time data under adjusted stress (such as PE rate and temperature fluctuation within 1 hour). The model update focuses on "degradation parameter correction": Taking the "aging coefficient k" in the original reliability model (such as the Arrhenius-Coffin-Manson fusion model) as an example, if the performance degradation rate in the current test (such as a daily increase in latency of 0.5ms) is higher than the historical data (a daily increase of 0.3ms), it indicates accelerated aging under the current stress, and the value of k is corrected from the historical 0.002 to 0.003. For the "failure threshold parameter," if the latency value corresponding to the current anomaly (such as 50ms) is lower than the historical failure threshold (60ms), the failure warning threshold in the model is lowered to 55ms to improve the sensitivity of subsequent anomaly identification. The parameter update process is implemented by a Python script calling the linear regression module in the Scikit-learn library. The effectiveness of the update is verified by the goodness-of-fit analysis (R² must be ≥0.85) between the current data and historical data. If the goodness-of-fit is insufficient, the script automatically introduces more historical samples (such as test data from the same scenario in the past 3 months) for recalculation to ensure parameter accuracy. The updated model parameters are stored in the "Model Parameters" sub-table of the "Machine Learning Results Table", with the update time and data source noted.

[0060] The updated reliability prediction model acts on the entire testing process through a closed-loop feedback mechanism: On the one hand, the corrected degradation parameters are synchronized to the acceleration factor calculation script in step 202—for example, after the corrected aging coefficient k is increased, the script will appropriately reduce the initial acceleration factor (e.g., from 8.0 to 7.5) when calculating AF_init to avoid over-acceleration due to the model underestimating the aging rate; on the other hand, the updated failure threshold parameters are passed to the time slice data acquisition script in step 203 to adjust the monitoring threshold of performance indicators (e.g., the upper limit of latency monitoring is reduced from 50ms to 45ms) to achieve more accurate real-time early warning. The core control logic of the closed-loop feedback is "deviation correction": After each round of testing (4 time slices, 2 hours), the script compares the performance degradation trend predicted by the model (e.g., predicting a 0.4ms increase in latency in the next round) with the actual collected degradation data (e.g., an actual increase of 0.42ms). If the deviation is ≤10%, the current test path is determined to be optimal, and the existing stress and model parameters are maintained. If the deviation is >10%, stress parameter adjustment (e.g., appropriately reducing the temperature by 1-2℃ when the deviation is too large) and model parameter update are retried until the deviation returns to ≤10%. At the same time, the script predicts the remaining lifespan of the SSD based on the updated model. If the predicted remaining lifespan deviates from the initial prediction by more than 15%, the preset test duration in step 3 is adjusted synchronously (e.g., if the initial preset is 1000 hours, and the remaining lifespan is shortened after correction, the preset duration can be adjusted to 900 hours) to ensure that the test balances "efficient acceleration" and "avoiding excessive wear and tear," and is always on the optimal path.

[0061] The test termination condition has been expanded to include a new "closed-loop feedback deviation trigger": If, in two consecutive rounds of testing, the deviation between the remaining lifetime predicted by the reliability model and the remaining lifetime derived from the actual performance degradation is greater than 15%, and the stress parameters have been adjusted to their upper limits (temperature ≥ 90℃, voltage deviation ≥ 6%), the script determines that the current test conditions can no longer accurately reflect the actual reliability and automatically terminates the test. If the abnormal pattern identified in step 204 disappears after stress adjustment, and the model prediction deviation is ≤ 10%, the test continues until the preset duration is reached or other fault conditions are triggered. Before termination, the script automatically generates a "closed-loop feedback report," summarizing the number of abnormal adjustments, model parameter update records, and changes in acceleration factors at each stage, providing a basis for optimizing subsequent test plans.

[0062] In the fault diagnosis phase, it is crucial to focus on linking the post-abnormal adjustment records in the "Dynamic Stress Parameter Table": If the SSD eventually triggers a fault, compare the fault characteristics before and after adjustment (e.g., slight latency fluctuations before adjustment, and uncorrectable errors after adjustment), and analyze the exposure process of potential defects (e.g., the main control logic error worsens after voltage increase, indicating that the defect is related to voltage sensitivity); In the data analysis phase, a new "stress adjustment - performance response" correlation analysis should be added to plot the performance change curves under different adjustment strategies (e.g., throughput decreases by 5% at +3℃ and by 8% at +5℃), quantifying the impact of stress adjustment on defect exposure, and providing a reference for stress adjustment strategies in subsequent similar SSD tests.

[0063] In terms of hardware optimization, if closed-loop feedback shows that the model deviation of a certain SSD model increases significantly when the voltage deviation is ≥5%, it is recommended to add a "voltage stabilization module" to the programmable power supply to control voltage fluctuations within ±3% and reduce model prediction uncertainty. In terms of test optimization, if adjustments are triggered by model deviation in multiple consecutive rounds of testing, it is recommended to increase the sample size of historical data (e.g., update the historical failure database once per quarter) and increase the model update frequency (from once per round of updates to once every 2 hours). In terms of process optimization, it is recommended to add a "closed-loop feedback monitoring panel" to the automation platform to display model prediction deviation, stress adjustment status, and remaining life prediction value in real time, so that testers can intuitively grasp the rationality of the test path and intervene in abnormal situations in a timely manner.

[0064] After step 204, the method further includes: step 205, comparing the abnormal mode with the known fault mode library to locate the potential failure mechanism; step 206, confirming whether the match is successful, and if the match is successful, calling the corresponding repair strategy to perform self-healing operation; step 207, if the match is not successful, marking the abnormal mode as an unknown type and storing it in the fault mode library for subsequent analysis, updating the fault mode library and marking it as a new type of abnormality, and at the same time, combining the temperature, voltage and load change trajectory, verifying the degree of influence of stress coupling on the acceleration factor, and dynamically optimizing the stress distribution strategy of subsequent time slices based on the actual collected data to improve aging efficiency and fault recurrence probability.

[0065] After identifying the abnormal mode in step 204, the initial stress optimization is completed through the "dynamic stress adjustment mechanism after anomaly". Then, the newly added "abnormal mode matching and fault self-healing and unknown anomaly handling" module (steps 205-207) is entered to form a complete processing chain of "abnormal identification - stress adjustment - mode matching - self-healing / optimization". Subsequently, the termination judgment and fault analysis of the original steps 3-4 are connected.

[0066] Step 205: In the comparison of abnormal modes with the known fault mode library and the localization of potential failure mechanisms, the automated platform first calls the preset "SSD Known Fault Mode Library". This library needs to be built and stored in the MySQL database in advance and contains the core characteristics of typical fault modes: such as the characteristics of "master logic error" corresponding to "latency surge of 30% + SMART parameter 0E (seek error rate) > 5 + voltage fluctuation > 3%", the characteristics of "NAND flash bad blocks" corresponding to "throughput decrease of 20% + SMART parameter C5 (current number of sectors to be mapped) > 3 + temperature ≥ 85℃", and the characteristics of "firmware garbage collection abnormality" corresponding to "write latency fluctuation frequency increased by 50% + no hardware parameter abnormality + stuttering during load switching". The comparison process employs a "multi-dimensional feature matching algorithm": using the abnormal mode features output in step 204 (such as delay change rate, temperature trajectory, SMART parameter values, and load type) as input, the cosine similarity with each fault mode feature in the library is calculated. A similarity ≥ 80% is considered a preliminary match, and the matching result is confirmed through "key feature verification" (e.g., for main control logic errors, the correlation between voltage fluctuation time and delay surge time needs to be verified, with a deviation ≤ 2 seconds). If the match is successful, the potential failure mechanism is directly located—for example, when matching with "NAND flash memory bad blocks," the failure mechanism is determined to be "accelerated charge leakage in NAND cells at high temperatures, leading to bad block generation." If the preliminary matching similarity is between 60% and 80%, detailed data for one time slice (30 minutes) (such as NAND flash memory programming / erase time) needs to be collected, the similarity recalculated, and the match determined again. If the similarity is < 60%, it is temporarily determined as a mismatch.

[0067] Step 206: In the self-healing operation invocation and verification after successful matching, if step 205 confirms successful matching, the automation platform invokes the corresponding self-healing operation according to the preset "fault-repair strategy mapping relationship" in the fault mode library: For "NAND flash bad blocks", a firmware-level self-healing instruction is issued to trigger the SSD's built-in bad block management mechanism (such as marking bad blocks as invalid and mapping them to spare blocks), while the voltage is finely adjusted through the programmable power supply (such as adjusting the SATA SSD from 3.3V±5% to 3.3V±3%) to reduce the risk of bad block expansion; For "firmware garbage collection anomaly", a "firmware GC parameter reset" instruction is sent remotely to the host to adjust the garbage collection trigger threshold from the default 10% to 15%, and the current high-load test is paused and switched to light load (IOPS target reduced to 50% of the base value) for 10 minutes to provide time for the GC mechanism to recover; For "master control logic error", the programmable power supply is first cut off by 30 Restart the SSD after a few seconds to clear temporary logical errors, and then recalibrate the temperature control chamber (within ±0.5℃) to avoid temperature fluctuations interfering with the main control operation. After the self-healing operation is executed, "effectiveness verification" is required: continuously collect performance data for 2 time slices (1 hour). If the latency, throughput, and other indicators recover to more than 90% of the pre-abnormal level, and the SMART parameters are normal, the self-healing is considered successful, and the original test process is automatically restored (using the adjusted stress parameters); if the indicators do not recover or a secondary abnormality occurs, the self-healing is considered to have failed, the test termination condition in step 3 is immediately triggered, and a "self-healing failure report" is generated, marking the fault mode, self-healing operation, and failure characteristics.

[0068] Step 207: In the process of marking and storing unmatched anomalies and stress coupling reverse verification and strategy optimization, if step 205 determines that there is no match, the anomaly mode is first marked as "unknown anomaly type" and stored in the "anomaly sub-library to be analyzed" of the fault mode library. The stored information must include: anomaly occurrence timestamp, complete stress trajectory (temperature / voltage / load change curve over time), full performance degradation data (delay / throughput every 1 second), SMART parameter snapshot, and labeled "new type of anomaly" for easy manual analysis later. The "stress coupling reverse verification" process is then initiated: stress data for one hour before and after the anomaly occurs are extracted, and the actual changes in the acceleration factor under different stress coupling combinations (such as "temperature 85℃ + voltage 3.3V ± 4%" and "temperature 88℃ + voltage 3.3V ± 5%) are compared. For example, the actual acceleration factor (derived based on the performance degradation rate) before the anomaly ("temperature 85℃ + voltage 3.3V ± 4%) is calculated to be 10.2, while the theoretical calculated value is 10.56, with a deviation of 2.5%. When the anomaly occurs ("temperature 88℃ + voltage 3.3V ± 5%)), the actual acceleration factor is 11.8, while the theoretical calculated value is 12.1, with a deviation of 2.5%. The influence of stress coupling on the acceleration factor is verified through Pearson correlation coefficient analysis (target r ≥ 0.9). If the correlation coefficient < 0.8, it indicates that the original coupling correction coefficient (AF_couple in step 202) has a deviation, and AF_couple needs to be corrected from 1.1 to 1.08 based on the actual data. Finally, based on the reverse verification results, the stress allocation strategy for subsequent time slices is optimized: for example, for unknown anomalies, the proportion of time slices for the "stress combination when the anomaly occurs" (such as temperature 88℃ + voltage 3.3V±5%) is increased from 25% to 40% in subsequent tests, while the proportion of other stress combinations is reduced; if the load when the anomaly occurs is "database transaction load", the test duration of this load is extended from 30 minutes to 45 minutes in subsequent time slices, thereby improving the aging efficiency of unknown anomalies and the probability of fault reproduction. The optimized stress allocation strategy is synchronized in real time to the time slice allocation script in step 203 to ensure that the new strategy is executed immediately in the next round of testing.

[0069] Step 206: After successful self-healing, the "self-healing operation - performance recovery data" needs to be synchronized to the reliability prediction model update process (original step two), and the "self-healing impact parameters" in the model need to be corrected. For example, if the performance degradation rate of a certain fault decreases from 0.5ms / day to 0.3ms / day after self-healing, the aging coefficient k in the model needs to be reverted from 0.003 to 0.0025. Step 207: The optimized stress distribution strategy needs to be fed back to the "closed-loop feedback deviation correction" logic in the original step three, and the new stress combination needs to be included in the deviation calculation range. For example, compare the model prediction value and the actual value under the "optimized stress combination". If the deviation is ≤10%, the new strategy is maintained; if the deviation is >10%, the stress parameters (such as temperature ±1℃) are further adjusted to ensure that the optimal acceleration path is not affected by unknown anomalies.

[0070] Added "Termination triggered by self-healing failure": If self-healing fails twice consecutively in step 206 and the fault mode is clear (such as a main control logic error), it is determined that the SSD cannot be recovered through self-healing, and the test is automatically terminated; Added "Termination triggered by reproduction of unknown anomalies": If, after optimizing the strategy in step 207, the unknown anomaly reproduces 3 or more times within 2 rounds of testing, it is determined that sufficient fault data has been obtained, and the test can be terminated and submitted for manual analysis; If the unknown anomaly is not reproduced and the model prediction deviation is ≤10%, the test continues.

[0071] The fault diagnosis stage needs to add "self-healing effect analysis": compare the stress-performance correlation data before and after self-healing to determine the degree to which the self-healing operation alleviates the fault (e.g., after bad block self-healing, the throughput recovery rate reaches 95%, indicating that self-healing is effective); the data analysis stage needs to add "unknown anomaly stress characteristic statistics": draw stress-performance scatter plots of unknown anomalies, mark high-risk stress ranges (e.g., temperature 85-90℃, voltage deviation 3%-5%), and provide early warning basis for stress settings in subsequent similar SSD tests; if the unknown anomaly is later identified by manual analysis as "new type of NAND wear anomaly", it needs to be added to the known fault mode library, update the characteristics and self-healing strategy, and form an iterative mechanism for the fault mode library.

[0072] Regarding hardware optimization, if the "controller logic error" occurs multiple times in step 206 and self-healing fails, it is recommended to add a thermal pad (0.5mm thick) to the surface of the SSD controller chip to reduce the impact of temperature fluctuations on the controller. For fault mode library optimization, it is recommended to manually review the "analytical anomaly sub-library" monthly, converting identified new anomalies into known patterns, updating features and self-healing strategies, and improving the matching accuracy of step 205 (targeting an increase from the initial 85% to 95%). For software optimization, it is recommended to add a "self-healing operation log module" to the automation platform to record the instructions, parameter changes, and results of each self-healing process, providing historical data support for subsequent model optimization.

[0073] Following step 201, the method further includes: step 208, injecting the read / write load combination in a time-slice polling manner, dividing the test cycle into multiple time slices, applying different read / write ratios and command queue depths in each time slice, and synchronously recording performance fluctuations and error logs; step 209, under the combined effect of high temperature and voltage fluctuations, continuously monitoring the changing trends of key indicators such as latency, throughput, and bad block count to ensure that the test covers the most stringent usage conditions in real application scenarios.

[0074] After completing the unknown anomaly marking and stress distribution strategy optimization in step 207, the new "Load Polling Injection and Key Indicator Monitoring under Harsh Conditions" module (steps 208-209) is introduced. By injecting differentiated loads on a time slice basis and monitoring core indicators under the combined effects of high temperature and voltage fluctuations, the optimized stress strategy is implemented as a specific test execution action. At the same time, it provides real-time data support for subsequent closed-loop feedback, forming a complete test chain of "strategy optimization - load execution - indicator monitoring - feedback correction".

[0075] Step 208: In the time-slice polling injection and data synchronization recording of read and write load combinations, the automated platform, based on the stress allocation strategy optimized in step 207, divides the test cycle into multiple 30-minute time slices (a single test cycle usually contains 4-6 time slices, with a total duration of 2-3 hours). Differentiated read and write load combinations are injected into each time slice to ensure coverage of load characteristics of different application scenarios. The load balancing design needs to be combined with the SSD product category: For enterprise-grade SSDs, time-slice loads should include "database mixed read / write" (read / write ratio 7:3, command queue depth 24-32), "backup sequential write" (read / write ratio 0:10, command queue depth 8-12), and "virtualization random read" (read / write ratio 10:0, command queue depth 16-20); for consumer-grade SSDs, they should include "light office load" (read / write ratio 8:2, command queue depth 4-8), "heavy gaming load" (read / write ratio 5:5, command queue depth 12-16), and "video editing sequential read / write" (read / write ratio 3:7, command queue depth 8-12). Load injection is achieved through the FIO tool. The automated script dynamically generates FIO instructions based on the load requirements of each time slice. For example, in the "database mixed read and write" time slice, the script sets bs=4K, rw=readwrite, rwmixread=70, and iodepth=28. At the same time, it calls the programmable power supply and the constant temperature chamber interface to ensure that the voltage and temperature stress of the current time slice are consistent with the optimized strategy (such as temperature 88℃ and voltage 3.3V±5%). Data recording employs a "dual-dimensional synchronous acquisition" method: performance fluctuation data is collected every 10 seconds, including read latency (average / maximum), write latency (average / maximum), sequential read throughput, and random write IOPS, and written in real time to the "Test Performance Data Table" in the MySQL database; error logs are snapshotted every 5 minutes, including SMART parameters (such as C5 bad block count, 0E seek error rate), FIO execution error codes (such as IO timeout, data verification failure), and abnormal alarm information from the temperature control chamber / power supply, stored in the "Error Log Table" and associated with the load and stress parameters of the corresponding time slice, facilitating subsequent tracing of the "load-stress-error" correlation.

[0076] Step 209: Continuous monitoring of key indicators and coverage of harsh scenarios under the synergy of high temperature and voltage fluctuation. Simultaneously with the load polling injection in Step 208, the "high temperature-voltage fluctuation synergistic monitoring" mechanism is activated: The constant temperature chamber maintains the high temperature setpoint calculated in Step 101 (e.g., industrial-grade 85℃) and introduces a temperature fluctuation of ±2℃ according to preset rules (fluctuating once per hour to simulate temperature fluctuations in a real environment); the programmable power supply introduces dynamic fluctuations of ±3%-±5% based on the rated voltage according to the voltage stress strategy in Step 202 (e.g., the SATA SSD randomly switches from 3.3V±4% to 3.3V±5%, switching once every 30 minutes to simulate an unstable power grid voltage scenario), ensuring the synergistic effect of the two stresses to reproduce the harsh conditions in real applications. Key performance indicator (KPI) monitoring focuses on three core dimensions: Latency is collected every 5 seconds, with set warning thresholds—a yellow warning is triggered when read latency exceeds 20% of the pre-abnormal average, and a red warning is triggered when write latency exceeds 30%; Throughput is collected every 10 seconds, with warnings triggered when sequential read throughput is below 40% of the pre-abnormal average and random write IOPS is below 50%; Bad block count is monitored in real-time via SMART parameter C5, read every minute, and a red warning is immediately triggered when the number of bad blocks increases by ≥2. To ensure coverage of the stringent conditions of real-world application scenarios, a "maximum load stacking" scenario needs to be specifically designed: Enterprise-grade SSDs need to simulate "24 hours of continuous mixed read / write + one voltage fluctuation per hour" (matching the 7×24-hour operation scenario of a data center), and consumer-grade SSDs need to simulate "8 hours of peak gaming load (90% random read / write) + two temperature surges (from 75℃ to 80℃)" (matching the device temperature rise scenario after a player has been playing games for a long time). During the monitoring process, all indicator data are synchronized to the visualization panel of the automation platform in real time. When a red alert is triggered, the current time slice load is immediately paused, and the fault mode library in step 205 is called for quick matching. If a known fault mode is matched (such as a surge in the number of bad blocks corresponding to "NAND flash memory bad blocks"), the process jumps directly to step 206 to perform self-healing operations. If no match is found or only a yellow alert is triggered, the monitoring continues and the indicator fluctuation trend is recorded to provide performance degradation data under harsh conditions for subsequent closed-loop feedback.

[0077] Step 208 records the "time slice load - performance fluctuation" data, which needs to be included in the deviation calculation of the closed-loop feedback. For example, comparing the model-predicted "database hybrid read / write" time slice throughput (800MB / s) with the actual collected value (750MB / s), if the deviation is 6.25% ≤ 10%, the current load and stress match well. If the deviation is > 10% (e.g., the actual throughput is only 650MB / s), the queue depth of the next load (reduced from 28 to 24) or voltage stress (reverted from 3.3V ± 5% to 3.3V ± 4%) is adjusted. Step 209 monitors the "changes in key indicators under harsh conditions" (e.g., the increasing trend of latency during high temperature fluctuations), which needs to be used to update the degradation parameters of the reliability model. If it is found that the performance degradation rate increases by 0.05ms / day for every ±1℃ temperature fluctuation, the "temperature fluctuation influence coefficient" in the model is corrected from 0.02 to 0.03 to ensure that the model can accurately reflect the aging pattern under harsh scenarios. In addition, the real-world application scenario data covered in step 209 needs to be added to the "Severe Scenario Characteristics" field of the fault mode library (e.g., the characteristic of "NAND flash bad blocks" under the "high temperature 85℃ + voltage fluctuation 5%" scenario should be "throughput drops sharply by 35%) to improve the matching accuracy of step 205.

[0078] Added "Termination triggered by warning under severe conditions": If step 209 triggers a red warning for 3 consecutive time slices (e.g., the number of bad blocks increases by ≥2 and self-healing is ineffective), or a yellow warning persists for more than 2 hours without relief (e.g., latency is consistently higher than 30% above the previous abnormality), it is determined that the SSD can no longer operate stably under severe conditions, and the test will be automatically terminated; Added "Termination upon completion of scenario coverage": If steps 208-209 have fully covered all the severe conditions of the target application scenario (e.g., enterprise-grade SSDs complete 24-hour continuous load testing, consumer-grade SSDs complete 8-hour peak load testing), and the termination condition has not been triggered, the test can be terminated in advance and a "Scenario Coverage Report" can be generated, marking the performance and anomaly records under each scenario.

[0079] The fault diagnosis phase needs to add "load-stress-fault correlation analysis": based on the time slice data in step 208, identify high fault risks under specific load and stress combinations (e.g., in the scenario of "database mixed read / write + voltage fluctuation of 5%", the main control logic error rate reaches 15%); the data analysis phase needs to add "severe condition performance degradation curve": based on the monitoring data in step 209, plot the latency and throughput degradation curves under different temperature / voltage fluctuations (e.g., degradation rate of 0.3ms / day at 85℃, and degradation rate of 0.5ms / day at 88℃), quantifying the impact of severe conditions on SSD lifespan. Simultaneously, the real-world scenario data covered in step 209 needs to be included in the "reliability assessment report" and supplemented with "scenario adaptability conclusions" (e.g., if a consumer-grade SSD performs stably under peak game load, it can be determined to be suitable for gaming scenarios).

[0080] Regarding load optimization, if step 208 reveals that throughput fluctuations exceed 20% under the "video editing sequential read / write" load, it is recommended to adjust the block size of this load (from 128M to 64M) in subsequent tests to reduce SSD garbage collection pressure. Regarding stringent condition adaptation, if step 209 shows that an enterprise-grade SSD is prone to triggering errors when voltage fluctuations are 5%, it is recommended to add a "voltage regulation module" to the product hardware design to control voltage fluctuations within ±3%. Regarding test process optimization, it is recommended to customize "time-slice load templates" for different product categories based on the scenario coverage of steps 208-209 (e.g., the enterprise-grade template includes 4 database-related time slices, and the consumer-grade template includes 3 game-related time slices) to improve testing efficiency and scenario matching.

[0081] After step 202, the method further includes: step 2010, writing a control script, automatically calling the data interface to obtain parameter configuration according to the control script, calling the I / O stress tool to execute read and write tasks, and collecting the response data of the solid-state drive under different stress combinations in real time; step 2011, during the test, switching different read and write load combinations in a loop according to the set time slice to simulate user behavior in different application scenarios.

[0082] After completing the definition of the indicator monitoring logic under stringent conditions in step 209, proceed to the newly added "Control Script Development and Load Cyclic Switching Execution" module (steps 2010-2011). By writing control scripts, the previous stress strategies, load combinations, and data acquisition requirements are transformed into automated execution instructions. Then, by cyclically switching the load through time slices to simulate real user behavior, an automated closed loop of "strategy design - script implementation - behavior simulation" is achieved, providing executable test actions to support subsequent closed-loop feedback.

[0083] Step 2010: Control Script Writing and Multi-Dimensional Automated Execution. The control script is developed using Python and integrates three core functional modules: "Parameter Configuration Acquisition - I / O Task Execution - Response Data Acquisition," ensuring seamless interaction with the automated platform equipment (programmable power supply, constant temperature chamber, test host) and database. First, the parameter configuration acquisition function: the script automatically retrieves the required parameters for the current test from the "Dynamic Stress Parameter Table" and "Load Template Library" in the MySQL database by calling a preset data interface (designed based on the RESTful protocol). This includes the target temperature stress value (e.g., industrial-grade 88℃), voltage fluctuation range (3.3V±5%), load combinations for each time slice (e.g., a read / write ratio of 7:3 and a queue depth of 28 for "database mixed read / write"), and data acquisition frequency (performance data every 10 seconds / time, error log every 5 minutes / time). The interface call frequency is set to 1 minute before each round of testing to ensure that the parameters are synchronized with the latest optimization strategy. Secondly, there is the I / O task execution function: the script calls the GPIB / LAN / RS232 interface through the PyVISA library to send load execution instructions to the FIO tool. For example, for the "game heavy load" time slice, the script automatically generates FIO commands (fio --name=game_load --bs=4K --rw=randrw --rwmixread=50 --iodepth=16 --runtime=1800 --filename= / dev / nvme0n1), and sends voltage adjustment instructions to the programmable power supply and temperature maintenance instructions to the constant temperature chamber to ensure that stress parameters start synchronously with load execution. If the device interface communication is abnormal during execution (such as GPIB connection interruption), the script automatically switches to the backup interface (such as LAN interface) and retryes. If the retry fails 3 times, an alarm is triggered and the test is suspended. Finally, there's the response data acquisition function: the script collects SSD response data in real time by calling the HWInfo64 API interface, including performance dimensions (read / write latency, throughput, IOPS), stress dimensions (current controller temperature, actual voltage output value), and error dimensions (SMART parameter snapshot, FIO error code). The collected data is written in real time to the "Test Performance Data Table" and "Error Log Table" of the MySQL database according to a preset format (timestamp-device ID-parameter type-value), and a local backup file (CSV format) is generated at the same time to prevent data loss due to database write failure.

[0084] Step 2011: In the time slice load cycling and user behavior simulation, the script switches between different read and write load combinations based on the load template obtained in step 2010 according to the "polling cycle" logic. Each cycle contains 4-6 time slices (each 30 minutes), and the number of cycles is automatically calculated according to the preset test duration (e.g., 1000 hours). The load switching follows the principle of "scenario-based user behavior simulation": For enterprise-grade SSDs, the cyclic sequence is designed as "database mixed read / write → backup sequential write → virtualization random read → idle maintenance (simulating low data center load at night, IOPS drops to 10% of the base value)". Within the "database mixed read / write" time slice, a "transaction burst" simulation is added (an IOPS peak occurs every 10 minutes, reaching 1.2 times the base value) to match the access characteristics of a real database. For consumer-grade SSDs, the cyclic sequence is designed as "office light load → game heavy load → video editing sequential read / write → standby (simulating user pause, IOPS close to 0)". Within the "game heavy load" time slice, a "load fluctuation" simulation is added (IOPS randomly changes between 80%-120% of the base value, adjusted every 5 minutes) to match the load fluctuations during player operation. Within the "video editing sequential read / write" time slice, a "large file intermittent write" simulation is added (pausing for 10 seconds every 3 minutes before resuming writing) to restore the intermittent load characteristics during video export. During the switchover process, the script sets a 5-second transition time: 5 seconds before the end of the previous time slice, the script preloads the FIO parameters and stress instructions for the next time slice; after the time slice expires, the current FIO task is stopped first, and then a new task is started to avoid SSD overload due to load accumulation; during the transition, the script monitors the SSD status in real time (such as whether there are any incomplete IO tasks), and only starts the new time slice test after the status stabilizes (≤5 incomplete IOs). In addition, the script supports "customizable user behavior": by modifying the "load loop order", "fluctuation parameters", and "interval duration" fields in the configuration file, it can adapt to the special needs of different application scenarios (such as multi-tenant load switching in a simulated server virtualization scenario). The switchover log is written to the "test execution log table" in real time, recording the time, load type, and stress of each switchover.

[0085] The "real-time response data" collected in step 2010 needs to be used as the core input for closed-loop feedback deviation calculation: After each cycle (2-3 hours) of the script, the actual performance data of each time slice (such as the actual throughput of "database hybrid read and write" 750MB / s) and the reliability model prediction value (800MB / s) are automatically extracted, and the deviation rate (6.25%) is calculated. If the deviation is ≤10%, the current load and stress parameters are maintained; if the deviation is >10% (such as the actual throughput is only 650MB / s), the script automatically adjusts the load parameters (such as reducing the queue depth from 28 to 24) or stress parameters (voltage fluctuation is reduced from ±5% to ±4%) in the next round, and updates the "dynamic stress parameter table" in the database. The "load cycle switching log" in step 2011 needs to be used to optimize the "scenario adaptation parameters" of the reliability model: if the performance degradation rate (0.5ms / day) of the "heavy game load" time slice is found to be significantly higher than that of other time slices, the "game load impact coefficient" in the model needs to be corrected from 0.03 to 0.04 to ensure that the model can accurately reflect the aging patterns under different user behaviors. In addition, the script execution status needs to be included in closed-loop monitoring: if an interface call fails or data acquisition is interrupted in step 2010, or if a load switching timeout occurs in step 2011, the closed-loop system will automatically trigger the "script repair mechanism" (such as restarting the script or re-initializing the interface). If the repair fails, the stress parameters will be adjusted (such as reducing the temperature by 2°C) and the test will be retried to avoid test interruption.

[0086] Added "Script Execution Abnormal Termination": If step 2010 experiences three consecutive data interface call failures, or step 2011 experiences two consecutive time slices of load switching timeout (exceeding 10 seconds), the automated execution chain is deemed abnormal, the test is automatically terminated, and a "Script Fault Report" is generated, marking the faulty interface, error code, and repair suggestions; Added "User Behavior Simulation Completion Termination": If step 2011 has completed all user behavior simulations according to the preset number of loops (e.g., a consumer-grade SSD completes 100 rounds of "office-game-video" loops), and no other termination conditions are triggered, the test can be terminated early, generating a "User Behavior Test Report" to analyze the SSD performance stability under different behavioral scenarios.

[0087] The fault diagnosis phase needs to add a "script execution - fault correlation analysis": based on the response data of step 2010 and the switching logs of step 2011, locate the fault cause under specific load switching scenarios (e.g., when switching from "heavy game load to video editing load", the sudden increase in latency corresponds to a voltage fluctuation of exactly 5%, indicating that the fault is related to the voltage stress during load switching); the data analysis phase needs to add a "user behavior - performance degradation correlation curve": based on the cyclic switching data of step 2011, plot the performance degradation trend under different user behavior scenarios (e.g., the degradation rate is 0.5ms / day in the game scenario and 0.2ms / day in the office scenario), quantifying the impact of user behavior on SSD lifespan. At the same time, the script execution efficiency data of step 2010 (e.g., interface call response time, data write speed) needs to be included in the "test efficiency evaluation" to provide a basis for subsequent script optimization (e.g., adding parameter caching functionality).

[0088] Regarding script optimization, if step 2010 reveals a data interface call latency exceeding 500ms, it is recommended to add a "local parameter caching" function to the script to cache the test parameters for each round locally on the host, reducing the number of database accesses. Regarding load switching optimization, if step 2011 reveals a performance fluctuation exceeding 25% during the switch from "database mixed read / write → backup sequential write," it is recommended to add "load gradient adjustment" (first reducing IOPS to 50% of the base value, then increasing it to the new target load value) during the transition period to mitigate the switching impact. Regarding user behavior simulation optimization, it is recommended to build a "user behavior feature library" for different product categories based on the test data from step 2011 (e.g., enterprise-level includes 5 typical data center behaviors, consumer-level includes 4 personal user behaviors). Subsequent tests can directly call the feature library templates to improve scenario adaptation efficiency.

[0089] Figure 4 yes Figure 1 The flowchart for step 3 is as follows: Figure 4 As shown, step 3 includes: step 301, using a disk information checking tool to check whether new bad blocks or errors have appeared on the solid-state drive at preset time intervals; step 302, estimating the current mean time between failures (MTBF) based on the check results and the acceleration factor; step 303, determining whether the estimated mean time between failures meets the preset MTBF requirement.

[0090] Step 2011: After completing the time-slice load cycle and user behavior simulation, proceed to the newly added "Periodic Bad Block Check and MTBF Estimation Judgment" module (steps 301-303). By periodically checking bad blocks and error states, and combining the acceleration factor from previous tests, estimate the actual MTBF to determine if the preset specifications are met. This provides the core basis for "reliability compliance" in closed-loop feedback and a key decision indicator for test termination, filling the gap in the "performance monitoring - reliability assessment" process. Step 3: Determine if the test has reached the preset duration, or the cumulative number of failures has reached the preset threshold, or the key SMART parameter (such as Available_Spare) is below the safety threshold. If not, return to step 2 to continue testing; if yes, proceed to step 4.

[0091] Step 301: In the bad block and error check at preset time intervals, the automation platform integrates disk information checking tools through control scripts, and selects smartmontools (cross-platform support for SATA / NVMe interfaces) as the core checking tool. The preset check interval is linked to the test cycle - usually one check is performed after every 2 load cycles (corresponding to 4-6 hours, covering 8-12 time slices) to ensure that the bad block growth trend can be captured in time without frequently interrupting the test process. The check is automatically triggered by a script: During the interval between two load cycles (when no I / O tasks are being executed), the script calls smartmontools on the test host via SSH remote command to execute the command `smartctl -a / dev / nvme0n1` (NVMe SSD) or `smartctl -a / dev / sda` (SATA SSD). It focuses on extracting two key types of information: First, bad block related parameters, including SMART attributes C5 (current number of sectors to be mapped, representing potential bad blocks), C6 (number of sectors that cannot be corrected offline, representing confirmed bad blocks), and 177 (erase failure count, associated with NAND flash health). The script records the difference between the values ​​of this check and the previous check to determine the number of newly added bad blocks / sectors to be mapped. Second, hardware error information, including SMART attributes 0E (seek error rate), 10 (spin retry count, applicable to SATA), and 184 (endpoint error count, applicable to NVMe), to determine if any new hardware errors exist. The inspection results are written in real-time to the "Bad Block Error Check Table" in the MySQL database in the format of "Timestamp - Device ID - Attribute ID - Current Value - New Value - Error Type". Simultaneously, they are stored in association with the corresponding period's acceleration factor (retrieved from the "Dynamic Stress Parameter Table") and load type (retrieved from the "Test Execution Log Table"), providing a complete "stress-load-bad block" data chain for subsequent MTBF estimation. If the inspection finds ≥3 newly added bad blocks or ≥5 sectors to be mapped, the script immediately triggers the fault mode library matching in step 205, prioritizing the determination of whether it belongs to the "NAND flash memory rapid degradation" category before executing the subsequent estimation process.

[0092] Step 302: In the MTBF estimation combining the inspection results and acceleration factor, the MTBF estimation is based on the "bad block growth pattern". Combining the inspection results of Step 301 and the previously corrected acceleration factor (AF_final, the average value of each round of testing retrieved from the "Dynamic Stress Parameter Table"), it is calculated in three steps: First, calculate the "equivalent actual usage time" corresponding to the acceleration test duration - if the current cumulative acceleration test duration is t_acc (e.g., 200 hours), and the average AF_final is 10.5, then the equivalent actual usage time t_actual = t_acc × AF_final = 200 × 10.5 = 2100 hours (approximately 0.24 years); Second, establish a "bad block growth and remaining lifespan" correlation model - based on historical failure data of the same model of SSD (retrieved from the "Historical Failure Database"), if the number of bad blocks of this model of SSD reaches 50 in actual use, triggering the end of lifespan (MTBF endpoint), the current cumulative number of bad blocks is 8, and the past t_actual If 6 new bad blocks are added within the time limit, the bad block growth rate v_bad = number of new bad blocks / t_actual = 6 / 2100 ≈ 0.00286 blocks / hour; the third step is to estimate the remaining actual lifetime and the current MTBF — remaining actual lifetime t_remaining = (number of bad blocks at the end of life - current number of bad blocks) / v_bad = (50-8) / 0.00286 ≈ 14685 hours (approximately 1.68 years), the current MTBF estimate = cumulative equivalent actual lifetime t_actual + remaining actual lifetime t_remaining = 2100 + 14685 ≈ 16785 hours (approximately 1.91 years). If it needs to be converted to the industry-common "hour-level MTBF", then 16785 hours are directly retained; if it needs to be matched with the "year" expression (calculated at 8760 hours per year), then it is approximately 1.91 years. During the estimation process, if a hardware error is detected in step 301 (such as an increase in seek error rate), an "error impact coefficient" k_error (k_error = 1.0 when there is no error, k_error = 0.85 when there is a minor error, and k_error = 0.6 when there is a serious error) needs to be introduced to correct the MTBF estimate. For example, if there is a minor error, the corrected MTBF would be 16785 × 0.85 ≈ 14267 hours. The estimation results are written to the "Reliability Assessment Table" in real time, indicating the estimation time, data source used (inspection results / acceleration factor / historical data), and correction coefficient, providing a traceable basis for subsequent judgments.

[0093] Step 303: In the judgment of the MTBF estimated value and the preset requirements, the preset MTBF requirements for different product categories are first clarified: consumer-grade SSDs usually require MTBF ≥ 50,000 hours (approximately 5.71 years), industrial-grade SSDs require MTBF ≥ 100,000 hours (approximately 11.42 years), and enterprise-grade SSDs require MTBF ≥ 200,000 hours (approximately 22.83 years). These requirements need to be entered into the "Test Specification Table" before testing as a judgment benchmark. The judgment logic has three scenarios: First, if the current MTBF estimate is ≥ 110% of the preset requirement (e.g., consumer-grade estimate ≥ 55,000 hours), it is judged as "exceeding the target," indicating that the SSD's reliability performance under the current accelerated test is excellent, and the existing stress and load strategy can be maintained to continue testing. At the same time, the estimated data is added to the historical failure database as a "high reliability sample." Second, if 90% of the preset requirement is < MTBF estimate < 110% of the preset requirement (e.g., consumer-grade 35,000-55,000 hours), it is judged as "critically meeting the target," requiring closed-loop feedback adjustment—reducing the acceleration factor AF_final through scripts (e.g., from 10.5 to 9.0), reducing stress intensity (e.g., temperature from 88℃ to 85℃, voltage fluctuation from ±5% to ±4%), avoiding excessive acceleration that causes a rapid drop in MTBF. After adjustment, the test continues and the bad block check interval is shortened (from 4-6 hours to 3-4 hours). Third, if the MTBF... If the estimated value is ≤90% of the preset requirement (e.g., consumer-grade ≤45,000 hours), it is judged as "not meeting the standard" and requires further verification. Two consecutive bad block checks are performed (1 hour apart). If both estimated values ​​fail to meet the standard and bad blocks continue to grow, the SSD reliability is judged to not meet the specification requirements, triggering the test termination condition in step 3. If the second estimated value recovers to the acceptable range, it is judged as "estimated fluctuation," maintaining the current strategy and increasing the estimation frequency (1 estimate per test round). The judgment result is fed back to the automated platform's visualization panel in real time. When "not meeting the standard," a "MTBF Non-Compliance Warning Report" is generated simultaneously, including the estimation process, bad block growth curve, and stress parameters, providing core clues for subsequent fault analysis.

[0094] The MTBF estimation data in step 302 needs to be used as the "core reliability indicator" of the closed-loop feedback: if it is determined to be "critically met", the closed-loop system will automatically reduce AF_final by 10%-15%, adjust the stress parameters (temperature -2℃, voltage fluctuation -1%), and update the "dynamic stress parameter table"; if it is determined to be "exceeding the standard", AF_final can be appropriately increased (not exceeding 10%) to improve testing efficiency, and the stress-load combination of the "high reliability sample" will be stored as the "optimal reference template" for reuse in similar SSD tests. The bad block check results in step 301 need to be included in the model parameter update: if the bad block growth rate is found to be higher than the model prediction value (e.g., the model predicts 0.002 blocks / hour, but the actual rate is 0.00286 blocks / hour), the "NAND aging factor" in the reliability model needs to be corrected from 0.003 to 0.0035 to ensure that the model can accurately reflect the bad block growth pattern. In addition, the closed-loop monitoring needs to add an "MTBF fluctuation warning": if the deviation of two consecutive estimated values ​​exceeds 20%, the emergency bad block check in step 301 will be automatically triggered to check for sudden hardware degradation.

[0095] Added "MTBF Failure to Meet Standards Termination": If step 303 is judged as "Failure to Meet Standards" twice consecutively and the bad block count continues to increase, or if a single estimated value is ≤80% of the preset requirement (e.g., consumer-grade ≤40,000 hours), the test will automatically terminate and generate an "MTBF Failure to Meet Standards Termination Report," indicating the reason for termination, cumulative test data, and reliability assessment conclusion. Added "MTBF Exceeds Standards and Terminates Early": If step 303 is judged as "Exceeds Standards" three times consecutively, and the cumulative equivalent actual duration has covered 50% of the SSD's design life (e.g., design life of 5 years, equivalent actual duration has reached 2.5 years), the test can be terminated early, the SSD's reliability is deemed qualified, and unnecessary testing costs are reduced.

[0096] The fault diagnosis process needs to add a "bad block-MTBF correlation analysis": based on the bad block inspection results in step 301 and the estimated data in step 302, locate the root cause of reliability degradation—for example, if new bad blocks are concentrated in a specific NAND chip area and the MTBF drops rapidly, it is judged as "local NAND chip quality defect"; if bad blocks grow evenly but the MTBF does not meet the standard, it is judged as "NAND overall aging rate exceeds the standard". The data analysis process needs to add an "MTBF-stress sensitivity curve": based on multiple sets of estimated values ​​in step 302, plot the MTBF change curve under different temperature / voltage stresses (e.g., MTBF = 18000 hours at 85℃, decreasing to 16785 hours at 88℃), quantifying the impact of stress parameters on reliability. Simultaneously, the MTBF estimated data needs to be included in the "final reliability report", clearly marking the "accelerated test equivalent MTBF" and the "actual usage MTBF prediction value", providing core basis for product qualification judgment.

[0097] Regarding hardware optimization, if step 303 determines that the MTBF is not up to standard and the bad block growth is too rapid, it is recommended to increase the proportion of NAND spare blocks in the SSD hardware design (from the default 5% to 8%) to extend the period from bad block degradation to the end of its lifespan. Regarding firmware optimization, it is recommended to optimize the bad block management algorithm, changing "passively mapping bad blocks" to "actively monitoring potential bad blocks (C5 parameter) and mapping them in advance" to reduce the impact of bad blocks on performance and reliability. Regarding test optimization, if step 301 finds that the check interval is too long, resulting in missed bad blocks, it is recommended to set the interval according to the product category (4 hours / time for consumer grade, 3 hours / time for industrial grade, and 2 hours / time for enterprise grade) to improve the timeliness of bad block capture.

[0098] Figure 5 yes Figure 1 The flowchart for step 4 is as follows: Figure 5As shown, step 4 includes: Step 401, using open-source tools to read complete SMART information every 5-10 minutes, the SMART information including at least the key attributes Media_Wear_Indicating, Host_GB_Written, Uncorrectable_Error_Cnt, CRC_Error_Count, Temperature, and Available_Spare; Step 402, performing degradation trajectory analysis on the SMART information curve of each disk over time, and plotting the degradation curve of "available spare blocks" as "host write volume" increases; Step 403, defining and recording the occurrence time of each failure (e.g., SMART attribute Uncorrectable_Error_Cnt exceeds 10 times, or bad blocks that cannot be read or written), fitting a two-parameter Weibull distribution to the collected failure occurrence times using the maximum likelihood estimation method, calculating the shape parameter (representing the failure mode) and scale parameter (representing the characteristic lifetime), and then estimating the MTBF estimate. Step 404: Predict the remaining lifespan of the solid-state drive under specific usage intensity based on the degradation model; Step 405: Generate an automated test report, which includes a test configuration summary, stress profile, key SMART parameter trend chart, performance degradation curve, failure time point and mode analysis, MTBF estimation and confidence interval based on Weibull analysis, remaining lifespan prediction based on the degradation model, and suggestions for analysis of major failure modes and root causes.

[0099] After completing the initial MTBF estimation and compliance assessment in step 303, the process moves to the newly added "SMART High-Frequency Monitoring and In-Depth Reliability Analysis and Report Generation" module (steps 401-405). This module collects key SMART attributes at high frequency, analyzes degradation trajectories, uses Weibull distribution to achieve more accurate MTBF estimation, predicts remaining lifetime, and ultimately generates an automated report integrating data from the entire process. This not only fills the accuracy gap in the initial MTBF estimation but also forms a complete closed loop of "test execution - data acquisition - in-depth analysis - report output," providing the final decision-making basis for product reliability assessment.

[0100] Step 401: High-frequency reading and data storage of key SMART attributes. Continuing with the previously selected open-source tool smartmontools (ensuring tool consistency), a reading interval of 5-10 minutes is set via a control script (configurable according to test accuracy requirements; 5 minutes for rigorous testing, 10 minutes for regular testing) to achieve high-frequency collection of key SMART attributes. The key attributes to read and their core meanings are as follows: Media_Wear_Indicating (media wear indicator, 0-100, lower values ​​indicate more severe wear), Host_GB_Written (cumulative write volume on the host, in GB, reflecting actual usage intensity), Uncorrectable_Error_Cnt (count of uncorrectable errors, directly related to data reliability), CRC_Error_Count (number of CRC check errors, characterizing interface communication stability), Temperature (SSD operating temperature, related to thermal stress effects), and Available_Spare (proportion of available spare blocks, 0-100, reflecting the ability to replace bad blocks). The execution logic is as follows: The script is triggered by a scheduled task (crontab on Linux, Task Scheduler on Windows). Each time, it executes the command `smartctl -A / dev / nvme0n1` (NVMe SSD) or `smartctl -A / dev / sda` (SATA SSD) to extract the real-time values ​​of the aforementioned attributes. These values ​​are then written to a newly added "SMART High-Frequency Data Table" in the MySQL database, formatted as "Timestamp - Device ID - Attribute Name - Attribute Value - Unit - Acquisition Interval". To avoid data redundancy, the script automatically deduplicates data (if two consecutive acquisition values ​​are completely identical, only the first one is retained). Simultaneously, it associates the stress parameters (temperature and voltage retrieved from the "Dynamic Stress Parameter Table") and load information (read / write ratio retrieved from the "Test Execution Log Table") of the corresponding time slice, forming a four-dimensional data chain of "Time - Stress - Load - SMART Attribute", providing a complete data source for subsequent degradation analysis. If an attribute value suddenly jumps during the data collection process (e.g., Uncorrectable_Error_Cnt increases from 0 to 5), the script will immediately trigger an audible and visual alarm, simultaneously suspend the current load test, and wait for manual confirmation or automatically execute the fault mode matching in step 205.

[0101] Step 402: In the SMART attribute degradation trajectory analysis and key curve plotting, based on historical data from the "SMART high-frequency data table," a Python data analysis library (Pandas for data processing, Matplotlib for curve plotting) is used to perform degradation trajectory analysis. The core focus is on the correlation curve between "Available_Spare" and "Host_GB_Written"—with Host_GB_Written as the horizontal axis (unit: TB) and Available_Spare as the vertical axis (unit: %), connecting each collection point in chronological order to form a degradation curve. The slope of the curve is used to determine the spare block consumption rate (e.g., a slope of -0.5% / TB means that the proportion of spare blocks decreases by 0.5% for every 1TB written). If the slope suddenly increases (e.g., from -0.5% / TB to -2% / TB), it is determined to be "accelerated consumption of spare blocks," and the stress data at that time (e.g., whether there was a sudden increase in temperature or voltage fluctuation) needs to be correlated to locate the cause. Simultaneously, degradation trajectory analysis of other key attributes needs to be supplemented: the curve of Media_Wear_Indicating changing with Host_GB_Written (it decreases linearly under normal wear; a precipitous drop indicates NAND flash memory abnormality), the curve of Temperature changing with test duration (the deviation from the stress setting value needs to be marked, such as whether it exceeds 85℃ for a long time), and the curve of Uncorrectable_Error_Cnt changing with Host_GB_Written (ideally, it should remain at 0; a non-zero value requires tracing the source of the error). All curves need to be labeled with "normal threshold line" (e.g., the normal threshold for Available_Spare is 20%, below which an early warning is triggered) and "failure threshold line" (e.g., the failure threshold for Available_Spare is 10%, below which a reliability failure is determined). The curve files should be stored in PNG format in the "Degradation Analysis Chart" folder on the test host, and the curve data (horizontal and vertical axis values) should be written into the "SMART Degradation Analysis Table" for easy retrieval in subsequent reports.

[0102] Step 403: In the accurate estimation of MTBF based on Weibull distribution, the definition of the fault occurrence time is first clarified: when the SMART attribute Uncorrectable_Error_Cnt exceeds 10 times, or bad blocks that cannot be read or written occur (smartmontools detects that the number of offline uncorrectable sectors of C6 attribute is ≥3, and IO errors are returned during read and write tests), the test time at this time (accurate to the minute) is recorded as the "fault occurrence time point"; if the test does not trigger a fault, the preset test duration (e.g., 1000 hours) is used as the "truncated data" (indicating that no failure occurred during the test period). Collect failure time data for at least 3 sets of SSDs of the same model (the larger the sample size, the more accurate the estimation; ≥5 sets are recommended). Use the maximum likelihood estimation method to fit a two-parameter Weibull distribution—the two parameters are the shape parameter β (Beta) and the scale parameter η (Eta). The shape parameter β reflects the failure mode: β<1 represents early failure (failure probability decreases over time, mostly due to initial defects), β=1 represents random failure (failure probability is constant, mostly due to accidental factors), and β>1 represents wear-out failure (failure probability increases over time, mostly due to device aging; this is the most common type during the normal use of SSDs). The scale parameter η represents the characteristic lifetime, i.e., 63.2% of the samples will fail within η time. The fitting process is implemented using Python's Scipy library: the `scipy.stats.weibull_min.fit()` function is called, taking the fault occurrence time data as input and outputting estimated values ​​of β and η. Then, based on the conversion relationship between the Weibull distribution and MTBF (when β≠0, MTBF=η×Γ(1+1 / β), where Γ is the gamma function, e.g., for β=2 and η=20000 hours, Γ(1+1 / 2)=√π / 2≈0.886, MTBF=20000×0.886≈17720 hours), the estimated MTBF value is calculated. Simultaneously, a 95% confidence interval needs to be calculated (using the Bootstrap method, repeatedly sampling 1000 times to obtain confidence intervals for β and η, then converting them to confidence intervals for MTBF) to ensure the statistical reliability of the estimation results. Finally, the estimated values ​​of β, η, MTBF and confidence intervals are written into the "Reliability Assessment Table" and compared with the preliminary estimated values ​​in step 302. If the deviation exceeds 15%, the cause of the data difference needs to be traced (e.g., step 302 is based on the number of bad blocks, step 403 is based on multiple failure indicators, and the result of step 403 shall prevail).

[0103] Step 404: In the remaining lifetime prediction based on the degradation model, the "Available Spare Block Degradation Model" is selected as the core prediction model (because Available_Spare is directly related to the bad block replacement capability and is a key indicator of SSD lifetime). The remaining lifetime under a specific usage intensity is predicted in three steps: First, determine the degradation model type—based on the Available_Spare-Host_GB_Written curve from Step 402, if the curve shows a linear relationship (R²≥0.9), a linear degradation model is adopted: Available_Spare(t) = - k×W(t), where Let $k$ be the initial percentage of available spare blocks (e.g., 100%), $k$ be the degradation rate (e.g., 0.5% / TB), and $W(t)$ be the amount of host writes (TB) within time $t$. If the relationship is exponential (R² ≥ 0.9), an exponential degradation model is used: Available_Spare(t) = ×e^(-k×W (t)). The second step is to set the remaining lifetime termination threshold—usually, the lifetime ends when Available_Spare drops to 10% (the failure threshold), i.e., Available_Spare (remaining lifetime) = 10%. The third step is to calculate the remaining lifetime based on specific usage intensity—assuming the user's actual usage intensity is 200GB of writes per day (i.e., 0.2TB / day), the current Available_Spare is 30%, and the cumulative writes... =50TB, substituting into the linear model: 30% - k×W (remaining) = 10%. If k = 0.5% / TB, then W (remaining) = (30% - 10%) / 0.5% / TB = 40TB; Remaining lifetime (days) = W (remaining) / daily write volume = 40TB / 0.2TB / day = 200 days (approximately 6.7 months). If you need to predict the remaining lifetime under different usage intensities (e.g., 100GB of writes per day), you only need to adjust the daily write volume and recalculate. The prediction results should be labeled with "usage intensity assumptions" and "model confidence level" (e.g., based on a linear model, R² = 0.92, confidence level 90%), and written to the "Remaining Lifetime Prediction Table". At the same time, a "usage intensity - remaining lifetime" correlation curve should be generated for users to refer to the lifetime performance under different usage scenarios.

[0104] Step 405: In the automated test report generation and content integration, an automated report generation script is developed using the ReportLab or Jinja2 library in Python. The script automatically extracts data from various MySQL tables ("Test Specification Table," "Dynamic Stress Parameter Table," "SMART High Frequency Data Table," "Degradation Analysis Chart," "Reliability Assessment Table," "Remaining Life Prediction Table," and "Failure Mode Library") and generates a PDF test report according to a preset template. The core content modules are as follows:

[0105] Test configuration summary: Includes the SSD model, capacity, interface type, firmware version, test host and auxiliary equipment configuration, preset stress parameters (temperature and voltage fluctuation range), total test duration and number of cycles, and load combination type (such as enterprise-level "database-backup-virtualization" cycle).

[0106] Stress profile: Plot the stress change curve throughout the test with time as the horizontal axis and temperature and voltage as the two vertical axes, and mark the stress adjustment nodes at each stage (e.g., the temperature rises from 85℃ to 88℃ in the 200th hour).

[0107] Key SMART parameter trend charts: embed curves such as Available_Spare-Host_GB_Written and Media_Wear_Indicating-Host_GB_Written generated in step 402, and mark the normal and fault threshold lines;

[0108] Performance degradation curve: Extract read / write latency and throughput data from the "Test Performance Data Table" throughout the test, plot the curve of change with the test duration, and mark the performance degradation inflection point (e.g., write latency increases from 10ms to 25ms in the 500th hour).

[0109] Failure time point and mode analysis: List all failure occurrence times, associate them with the stress and load conditions at the time, and combine them with the failure mode matching results in step 205 to calculate the proportion of each type of failure (e.g., NAND flash bad blocks account for 60%, interface CRC errors account for 20%).

[0110] Weibull analysis results: including estimated values ​​and physical meanings of β (shape parameter) and η (scale parameter) (e.g., β=2.3, judged as wear-out failure), estimated MTBF value and 95% confidence interval (e.g., 16785±1200 hours), compared with the preliminary estimate in step 302 and the reasons for the difference;

[0111] Remaining lifetime prediction: Specify usage intensity assumptions (e.g., 200GB of writes per day), provide the remaining lifetime prediction (e.g., 200 days) and model confidence level, and attach the "usage intensity - remaining lifetime" curve;

[0112] Main failure modes and root cause analysis recommendations: Based on the fault location results, such as "NAND flash memory bad blocks" being caused by "accelerated charge leakage at high temperatures", it is recommended to add an aluminum heat sink (thickness ≥1mm) to the hardware and optimize the wear leveling algorithm in the firmware; the root cause of "interface CRC error" is "voltage fluctuation exceeding 5%", and it is recommended to add a voltage regulator module to the programmable power supply.

[0113] After the report is generated, the script will automatically send it to the preset email address (the email address of the test manager and product manager), and provide a download link on the visualization panel of the automation platform. The report file name should be named in the format of "SSD Model-Test Date-Report Version" (e.g., "Samsung 990 Pro-20251114-V1.0.pdf"), which is convenient for version tracking and archiving.

[0114] The degradation trajectory analysis results in step 402 need to be fed back to the closed-loop system: if accelerated consumption of Available_Spare is found (the slope increases), the closed-loop script automatically reduces the acceleration factor AF_final (e.g., from 10.5 to 9.0) and simultaneously lowers the temperature (e.g., from 88℃ to 85℃) to reduce the spare block consumption rate; if Media_Wear_Indicating drops sharply, an emergency bad block check is immediately triggered (step 301) to investigate NAND flash memory failures. The Weibull distribution parameters (β, η) in step 403 need to be updated to the reliability prediction model: if β=2.3 (failure due to wear and tear), the "aging coefficient" in the model needs to be increased by 15% to more accurately reflect the aging law of the device; if η=20000 hours (characteristic lifetime), the preset test duration can be shortened from 1000 hours to 800 hours (covering the failure cycle of 63.2% of the samples), improving test efficiency.

[0115] Added "Terminate when remaining lifespan meets target": If the remaining lifespan predicted in step 404 is greater than or equal to the preset lifespan requirement (e.g., the remaining lifespan requirement for consumer-grade SSDs is ≥3 years), and the MTBF estimate meets the target, the test can be terminated early, and the product's reliability is deemed acceptable; Added "Terminate when SMART failure threshold is reached": If Available_Spare ≤ 10% or Uncorrectable_Error_Cnt ≥ 15 times are collected in step 401, the SSD is determined to have reached a reliability failure state, and the test is terminated immediately to avoid the risk of data loss.

[0116] The fault diagnosis process needs to add "SMART attribute correlation diagnosis": for example, if Uncorrectable_Error_Cnt increases and CRC_Error_Count also increases simultaneously, it is determined as "interface communication failure"; if only Uncorrectable_Error_Cnt increases, it is determined as "NAND flash memory data storage failure". The data analysis process needs to add "Weibull parameter and failure mode correlation analysis": statistically analyze the β value distribution of multiple samples. If 80% of the samples have β>2, it indicates that the main failure mode of this SSD model is wear-through failure, and the NAND flash memory aging resistance needs to be optimized; if some samples have β<1, it indicates an initial defect, and the production quality inspection process needs to be improved.

[0117] Regarding SMART monitoring optimization, if step 401 finds that a sudden attribute jump cannot be captured even at a 5-minute interval (e.g., Uncorrectable_Error_Cnt increases from 0 to 10 in just 3 minutes), it is recommended to shorten the collection interval to 2 minutes and add an "attribute mutation warning" script (triggers an alarm when the attribute value change rate exceeds 50% / minute). Regarding model optimization, if the confidence level of the linear degradation model in step 404 is <85%, it is recommended to introduce a "multi-attribute fusion degradation model" (combining Available_Spare and Media_Wear_Indicating for joint prediction) to improve prediction accuracy. Regarding report optimization, based on user feedback, a "competitive comparison module" can be added to the report (e.g., comparing the MTBF of the tested SSD with that of a competitor at the same level of 15,000 hours) to enhance the report's reference value.

[0118] This embodiment overcomes the limitations of traditional testing methods that only apply a single static high-temperature stress by constructing a dynamic comprehensive stress model that combines multiple dimensions of stress, such as temperature stress, voltage stress, and read / write load stress. This enables comprehensive stress testing of solid-state drives (SSDs), improving the comprehensiveness and accuracy of the tests. A multi-source data synchronous acquisition system is used to collect and analyze multi-dimensional information such as BIT logs, SMART data, and performance data in real time, enabling in-depth monitoring and dynamic analysis of the internal state of the SSD, improving the real-time performance and diagnostic capabilities of the tests. Based on Weibull analysis and degradation trajectory analysis of degradation data, the traditional "0 / 1" MTBF calculation model is abandoned, achieving accurate simulation and lifespan prediction of the SSD performance degradation process, providing more reliable data support for product improvement and maintenance. Automated scripts and platforms enable automated execution of the testing process and data analysis, improving testing efficiency and consistency, reducing the possibility of human intervention, and ensuring the accuracy and reliability of test results. Through a comprehensive fault definition and diagnostic mechanism, it is possible not only to determine whether a product is qualified but also to reveal how and why it failed, providing comprehensive diagnosis and guidance for product quality improvement.

[0119] Based on the first embodiment, a second embodiment is proposed. In the second embodiment, a 512GB enterprise-grade SATA solid-state drive is used as an example, with a nominal mean time between failures (MTBF) requirement of 2 million hours. This method involves conducting accelerated life testing in a laboratory to verify whether the drive meets this reliability target within a reasonable timeframe.

[0120] Step 1: Initialize the solid-state drive test environment

[0121] Calculate the accelerated stress conditions:

[0122] The goal is to validate an equivalent MTBF of 2 million hours within a 30-day (720-hour) testing period. Therefore, the required acceleration factor (AF) is at least: AF = 2,000,000 hours / 720 hours ≈ 2777.8.

[0123] The Arrhenius model is used as the temperature acceleration model, and its formula is as follows:

[0124] AF = exp[ (Ea / k) (1 / T_use - 1 / T_stress)

[0125] in:

[0126] Ea (activation energy) is a parameter that reflects the temperature sensitivity of a product's failure mechanism. For NAND flash memory, an empirical value of 0.7 eV is used in this example.

[0127] k is the Boltzmann constant, approximately 8.617 × 10^-5 eV / K.

[0128] T_use is the normal operating temperature of the product, taken as 40°C (313.15K).

[0129] T_stress is the accelerating stress temperature to be determined.

[0130] Substituting AF=2778 into the formula, the calculated T_stress is approximately 398.15K, or 125°C. Considering the device safety margin, the stress temperature in this example is ultimately set to 85°C. At this point, the calculated AF is approximately 150, and the equivalent duration requirement can be met by extending the test time to approximately 40 days.

[0131] Hardware environment setup:

[0132] The solid-state drive under test was installed in the test host, and the entire unit was placed in a programmable high and low temperature test chamber.

[0133] The test host is powered by a programmable power supply.

[0134] Connect and control the chamber via the GPIB interface, and set the temperature to 85°C.

[0135] Connect and control the programmable power supply via RS232 interface, and set the output voltage to 95% of the nominal value (i.e., 3.135V) to introduce voltage stress.

[0136] The test host is connected to the console via a LAN interface for remote start-up, shutdown, and monitoring.

[0137] Software environment and automation script configuration:

[0138] Write automation control scripts using Python in the console.

[0139] The script configures and executes read / write load tests by calling the command-line interface of the PassMark BurnInTest software. The test parameters are set as follows: 70% random reads, 30% random writes, queue depth 32, and block size 4KB.

[0140] Step 2: Perform a solid-state drive acceleration test

[0141] Apply dynamic combined stress:

[0142] Temperature stress: Maintain the test chamber temperature at 85°C (constant high temperature stress).

[0143] Voltage stress: The programmable power supply fluctuates sinusoidally between 90% and 110% of the nominal value of 3.3V (i.e., 2.97V to 3.63V) at a frequency of 1Hz (dynamic voltage stress).

[0144] Read / write load stress: The load configured in step 103 is continuously applied via BurnInTest. Every 4 hours, a performance benchmark test (lasting 5 minutes) is automatically inserted to measure sequential read and write speeds.

[0145] Real-time data acquisition:

[0146] Every 10 minutes, the automated script executes the `smartctl` command to read the complete SMART attribute data of all SSDs under test and records it in a log file. The following attributes are of particular interest:

[0147] Media Wear Indicating

[0148] Host_GB_Written (Host writes)

[0149] Available_Spare (percentage of available spare blocks)

[0150] Uncorrectable_Error_Cnt (Uncorrectable Error Count)

[0151] CRC_Error_Count (CRC error count)

[0152] Step 3: Test process monitoring and termination judgment

[0153] Regular inspections and assessments:

[0154] The automated script executes a check every hour to determine if the test termination condition is met. The termination condition is any of the following:

[0155] Reaching the preset duration: The cumulative testing time reaches 960 hours (40 days).

[0156] Failure trigger condition: Any of the tested SSDs exhibits one of the following conditions:

[0157] Available_Spare drops below 10%.

[0158] Uncorrectable_Error_Cnt exceeded 100 times.

[0159] The operating system or BurnInTest reported a read / write error, preventing the test from continuing.

[0160] Loop logic:

[0161] After each check, if no termination condition is met, the test procedure returns to step 2 to continue applying stress and collecting data.

[0162] If any termination condition is met, the test process proceeds to step 4.

[0163] Step 4: Fault Diagnosis and Data Analysis

[0164] Data cleanup and failure definition:

[0165] Organize all collected time-series data (SMART data, performance data).

[0166] The event that triggers the "failure condition" in step 3 is explicitly defined as a failure, and the exact time of its occurrence is recorded (based on the actual test time).

[0167] Degradation trajectory analysis: Plot curves showing how key parameters change over time or with the amount of data written. For example, plot the degradation curves of Available_Spare as Host_GB_Written increases for all tested disks.

[0168] By curve fitting, a mathematical model of the spare block consumption rate is established, for example: Available_Spare(t) = Initial_Spare - k Host_GB_Written(t), where k is the consumption rate coefficient.

[0169] Weibull analysis to calculate MTBF:

[0170] Use all failure time data recorded in step 401 (e.g., the three disks failed at the 150,000th, 280,000th, and 420,000th hours at equivalent ambient temperature, respectively) as input.

[0171] The maximum likelihood estimation method is used to fit a two-parameter Weibull distribution. Assume the fit yields:

[0172] Shape parameter β = 2.1 (>1 indicates wear-age failure)

[0173] Scale parameter η = 550,000 hours (characteristic lifetime)

[0174] According to the Weibull distribution model, the mean lifetime (MTBF) is calculated as: MTBF = η Γ(1 + 1 / β), where Γ is the gamma function. The calculated MTBF estimate for this example is approximately 487,000 hours, with a 90% confidence interval.

[0175] Step-by-step remaining life prediction:

[0176] Based on the degradation model established in step 402, for disks that are not failed but have shown signs of degradation, the remaining amount of writes or remaining time required for their Available_Spare to drop to a threshold (e.g., 10%) can be predicted according to their current Host_GB_Written and consumption rate k.

[0177] Generate automated test reports:

[0178] The script automatically generates a comprehensive test report, which includes:

[0179] Test configuration summary: Product model, stress conditions (temperature, voltage), load profile, total test duration.

[0180] Stress profile diagram: showing the changes in temperature and voltage over time.

[0181] Trend charts of key SMART parameters: such as the curve of Available_Spare changing over time.

[0182] Performance degradation curve: Sequential read / write speed changes over test time.

[0183] Failure analysis: Record the failure disk number, failure time, and failure mode (such as spare blocks being exhausted).

[0184] Reliability assessment: The estimated MTBF based on Weibull analysis is 487,000 hours and its confidence interval. Since this value is lower than the target of 2 million hours, it can be determined that this batch of products has not met the design objectives.

[0185] Improvement recommendations: Based on the main failure modes (such as excessively rapid wear rate), it is recommended to optimize the selection of flash memory chips or the wear leveling algorithm of the firmware.

[0186] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0187] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0188] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for verifying the mean time between failures (MTBF) of a solid-state drive (SSD), characterized in that, The method includes: Initialize the test environment for the solid-state drive; A dynamic integrated stress model is constructed, and an acceleration factor is calculated based on adaptive parameters of reliability. During the test, the acceleration factor is increased and different read / write load combinations are cyclically switched according to the set time slices to accelerate the test of solid-state drives. Determine whether the test has reached the preset duration or triggered a fault condition; If yes, proceed with SSD fault diagnosis and data analysis; otherwise, return to continue accelerating the SSD test. The steps of constructing a dynamic integrated stress model, calculating an acceleration factor based on adaptive reliability parameters, increasing the acceleration factor during testing, and cyclically switching different read / write load combinations according to a set time slice to accelerate the testing of the solid-state drive include: A dynamic integrated stress model is constructed, and read / write load combinations under different application scenarios are obtained based on the dynamic integrated stress model. The dynamic integrated stress model includes temperature stress, voltage stress, and read / write load stress. The acceleration factor is calculated by integrating the adaptive parameters of reliability in the reliability analysis model, and the acceleration factor is corrected by combining the coupling effect of temperature and voltage stress. The corrected acceleration factor is allocated to the read and write load combinations of each time slice. Random read and write requests of corresponding intensity are generated through I / O stress tools, and the latency, throughput and temperature data of the solid-state drive are collected at the end of each time slice. Machine learning algorithms are used to normalize and perform consistency analysis on test data from multiple platforms to identify abnormal patterns in which performance deviates from the threshold. The acceleration factor, calculated by integrating adaptive parameters of reliability in the reliability analysis model and correcting it by combining the coupling effect of temperature and voltage stress, includes: Calculate the initial acceleration factor The The acceleration coefficient is the temperature. This is the cyclic acceleration coefficient; Introducing a voltage stress correction term When the voltage is within ±3% of the rated value, When the voltage deviates from the rated value by 3% to 5%, 2; When the voltage deviation exceeds 5%, 0.8; Consider the coupling effect of temperature and voltage: when temperature And voltage deviation At that time, the coupling correction coefficient corresponding to the coupling effect of temperature and voltage When the temperature Or voltage deviation ≤ hour, ; The final corrected acceleration factor was obtained. .

2. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, The steps for initializing the solid-state drive test environment include: Based on the product category and target mean time between failures (MTBF) specification requirements of solid-state drives, the high temperature setpoint corresponding to the product category is calculated using the Arrennis model. When the solid-state drive is in a constant temperature chamber, set the target temperature to the high temperature setting value; An automated testing platform integrating a programmable power supply, a constant temperature chamber, and a host computer is built. The temperature of the constant temperature chamber and the output voltage of the programmable power supply are controlled uniformly through GPIB, LAN, or RS232 interfaces, and the host computer is started and stopped remotely.

3. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, After the step of using machine learning algorithms to normalize and perform consistency analysis on multi-platform test data to identify abnormal patterns of performance deviation from the threshold, the method includes: Once an abnormal pattern is identified, a dynamic stress parameter adjustment mechanism is automatically triggered to increase the voltage or temperature stress level in order to accelerate the exposure of potential defects. By combining historical failure data with the current test status, the degradation parameters in the reliability prediction model are updated, and closed-loop feedback control is used to ensure that the test process is always on the optimal acceleration path.

4. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, After the step of using machine learning algorithms to normalize and perform consistency analysis on multi-platform test data to identify abnormal patterns of performance deviation from the threshold, the method further includes: By comparing abnormal patterns with a known failure mode library, potential failure mechanisms can be identified. Confirm whether the match is successful. If the match is successful, call the corresponding repair strategy to perform the self-healing operation. If no match is found, the abnormal mode is marked as an unknown type and stored in the fault mode library for subsequent analysis. The fault mode library is updated and marked as a new type of abnormality. At the same time, the influence of stress coupling on the acceleration factor is verified by combining the temperature, voltage and load change trajectories. The stress distribution strategy of subsequent time slices is dynamically optimized based on the actual collected data to improve aging efficiency and fault recurrence probability.

5. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, After the steps of constructing a dynamic integrated stress model and obtaining read / write load combinations under different application scenarios based on the dynamic integrated stress model, wherein the dynamic integrated stress model includes temperature stress, voltage stress, and read / write load stress, the method further includes: The read and write loads are combined and injected in a time-slice round-robin fashion. The test cycle is divided into multiple time slices, and different read and write ratios and command queue depths are applied in each time slice. Performance fluctuations and error logs are recorded synchronously. Under the combined effects of high temperature and voltage fluctuations, the system continuously monitors the trends in latency, throughput, and bad block count to ensure that the tests cover the most demanding usage conditions in real-world application scenarios.

6. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, After the step of comprehensively calculating the acceleration factor based on the adaptive parameters of reliability in the reliability analysis model, and correcting the acceleration factor by incorporating the coupling effect of temperature and voltage stress, the method further includes: Write control scripts to automatically call data interfaces to obtain parameter configurations, call I / O stress tools to execute read and write tasks, and collect real-time response data of solid-state drives under different stress combinations. During the test, different read / write load combinations were cyclically switched according to the set time slices to simulate user behavior in different application scenarios.

7. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 6, characterized in that, The steps for determining whether the test has reached the preset duration or triggered a fault condition include: Use a disk information checker at preset time intervals to check if the solid-state drive has any new bad blocks or errors; Estimate the current mean time between failures (MTBF) based on the inspection results and the acceleration factor. Determine whether the estimated mean time between failures (MTBF) meets the preset MTBF requirement.

8. The method for verifying the mean time between failures (MTBF) of a solid-state drive according to claim 1, characterized in that, If yes, analyze the solid-state drive (SSD) fault diagnosis and data analysis; if no, return to the steps of accelerating the SSD test. Use open-source tools to read complete SMART information every 5-10 minutes. The SMART information includes at least the Media_Wear_Indicating, Host_GB_Written, Uncorrectable_Error_Cnt, CRC_Error_Count, Temperature, and Available_Spare key attributes. Degradation trajectory analysis was performed on the SMART information curve of each disk over time, and the degradation curve of "available spare blocks" as "host write volume" increased was plotted. Define and record the occurrence time of each fault. Use the maximum likelihood estimation method to fit a two-parameter Weibull distribution to the collected fault occurrence times, calculate the shape parameter and scale parameter, and then estimate the MTBF value. Predicting the remaining lifespan of solid-state drives under specific usage intensity based on a degradation model; Generate an automated test report, which includes a test configuration summary, stress profile, key SMART parameter trend chart, performance degradation curve, failure time point and mode analysis, MTBF estimation and confidence interval based on Weibull analysis, and failure mode prediction and root cause analysis recommendations based on the degradation model.

Images