SSD power-loss testing: an OEM qualification protocol

“Power-loss protection” is not a complete requirement. It can refer to protection of the controller mapping tables, data already acknowledged to the host, data covered by a completed Flush, or an implementation-specific subset of those states. A test that does not identify the claimed boundary may produce many power cuts and little useful evidence.

The purpose of OEM qualification is therefore not to demonstrate that an SSD can reboot after its plug is removed. It is to determine, for an exact device and host configuration, which state remains valid after an uncontrolled loss of power and whether that state matches the supplier's written claim.

This protocol applies to SATA and NVMe SSD programs. Command details differ by interface, and the final procedure must follow the applicable specification and device documentation.

Define the protection claim before designing the test

Begin with observable outcomes rather than component labels.

The Open Compute Project specification is useful because it separates abrupt shutdown behavior from PLP-health monitoring and requires more than an open/short capacitor check for devices claiming that profile [1]. Those requirements are not automatically applicable to every industrial or client SSD. They are a reference for writing an explicit purchase specification, not evidence that an untested drive complies.

Ask the supplier to state:

• whether a volatile write cache is present and how it is reported;
• which data is promised durable after command completion, Flush or FUA;
• whether both user data and flash-translation-layer metadata are protected;
• the supported supply-removal profile and minimum voltage fall time;
• recovery-time limits and behavior following a protection-circuit fault;
• the models, capacities, controller revision and firmware covered by the statement.

Without those boundaries, “PLP” cannot become an acceptance criterion.

Freeze the test object and the host path

The unit of qualification is the configuration, not the product-family name. Record at minimum:

NVMe defines controller shutdown state and command semantics, but it does not make every platform remove power in the same way [2]. A bench relay connected far upstream may discharge through system capacitance for much longer than a field failure. Measure voltage at the device connector and retain the waveform for representative cuts.

Use a dedicated fixture that can interrupt device power independently of the host where the product architecture permits it. A software reboot, controller reset or orderly shutdown exercises a different state and must not be reported as an abrupt-power-loss test.

Establish a data oracle

After restart, the laboratory needs to distinguish valid old data, valid new data and corruption. A directory listing or filesystem check is too coarse.

A practical generator writes records containing:

• target LBA or file offset;
• monotonically increasing sequence number;
• run and cycle identifier;
• payload hash or checksum;
• a known payload pattern independent of the metadata.

Maintain the expected record stream on a separate, protected system. Classify each command by its position relative to completion and the defined durability boundary:

1. Durable set: writes that the protocol and supplier claim require to survive.
2. Indeterminate set: issued writes not yet inside that boundary at interruption.
3. Untouched set: addresses that the workload did not modify during the cycle.

Every durable record must match. An indeterminate record may resolve to the valid old or valid new version if the contract permits it, but damage to an unrelated address is not an acceptable cache effect. This classification prevents the test from calling all missing recent data a failure while still detecting silent corruption outside the interrupted transaction.

Where a filesystem or database is part of the product, run two layers of testing. First test raw block behavior to isolate the SSD. Then test the application stack to evaluate whether its Flush, barrier and recovery design uses the device contract correctly.

Construct a matrix that can expose state-dependent failures

One cut point under one sequential workload is a demonstration, not qualification.

The SSD should be preconditioned to the state relevant to the application. Testing only an empty fresh drive may avoid garbage collection, mapping pressure and background work—the states most likely to interact with an interruption.

Randomize cut timing within defined windows instead of triggering at one fixed delay. Preserve the random seed and the issued/completed command trace so the sequence can be reconstructed.

Execute one controlled cycle

A repeatable cycle can be organized as follows:

1. Capture electronic identity, health data, error logs and the initial namespace state.
2. Verify the known baseline dataset.
3. Start the defined workload and external command journal.
4. Trigger power removal at the selected randomized point.
5. Record device-rail voltage and current through the complete decay.
6. Hold power off for the specified interval, then restore it without changing the host state unexpectedly.
7. Measure time to enumeration and time to stable I/O readiness.
8. Read and classify the durable, indeterminate and untouched address sets.
9. Capture health, error and event information again before any repair or retry.

NVMe-CLI exposes controller identity, SMART/Health information, error records and supported telemetry [3][4]. Store raw output, tool version, command line and timestamp. A dashboard screenshot is not an adequate evidence record because it cannot be reinterpreted after the failure hypothesis changes.

Do not allow automatic filesystem repair, firmware update or repeated reboot loops to modify the evidence before collection. If the device does not enumerate, follow the predefined recovery path and preserve the first observed state.

Write failure criteria before testing

Stopping criteria should be objective and approved before the first interruption.

A pass/fail statement should identify the failed layer. “Drive survived” hides distinctions among data correctness, namespace recovery and delayed readiness.

After any failure, suspend the sequence, preserve logs and move the unit into the RMA evidence process. Repeating the same cycle immediately may alter persistent state and reduce diagnostic value.

Treat repetition as evidence, not certainty

Distribute samples across production lots and material hardware or firmware revisions. Repeated cuts on one drive explore timing and internal state but do not estimate unit-to-unit variation. Multiple drives exposed to one timing point have the opposite limitation.

If zero failures occur in n independent trials, the conventional one-sided 95% “rule of three” places the event probability at approximately less than 3/n. Power-cut trials on the same SSD are rarely independent, so that value is, at best, an optimistic orientation. Report devices, cycles, strata and exposure time separately rather than collapsing them into one large cycle count.

Qualification establishes evidence for the tested configuration. Firmware, controller, NAND, capacity, PLP circuit or host-cache changes should enter the PCN and requalification process.

Convert the result into a purchasing control

The final evidence package should contain:

• the supplier's written PLP and cache-behavior statement;
• exact qualified part number, BOM boundary and firmware;
• power waveform and fixture description;
• workload generator, durability oracle and software versions;
• sample and lot manifest;
• complete matrix, cycle log and raw diagnostic records;
• predefined acceptance and stopping criteria;
• failure-analysis and recovery procedure;
• requalification triggers and change-notification terms.

The general flash qualification plan provides the surrounding sample-to-production framework. The earlier PLP explainer describes the mechanism; this protocol defines how to test a specific claim.

For sourcing, the useful RFQ is not “Do you have PLP?” It is: Which writes and metadata are protected on this exact SKU, under what power profile, with what test evidence and change-control boundary? Send that requirement through the OEM flash-storage sourcing page so the proposed sample can be matched to a verifiable acceptance plan.