找一台电脑,把 SSD 插进去,跑一遍 FIO,看看顺序读写、随机 IOPS 和时延是否达标,再做几次掉电测试,好像就差不多了。
但在工业控制、航空/航天电子以及其他高可靠应用中,事情远没有这么简单。
一块 SSD 在实验室里连续运行几天没有报错,并不意味着它装进实际设备后仍然稳定。真实系统中的供电波动、异常断电、连接器接触不良、PCIe 信号干扰、高低温变化以及主机侧兼容性问题,都可能成为故障的诱因。
2026年7月21日,我们围绕一套定制化 SSD 测试平台进行了两个多小时的技术交流。讨论从 PCIe 协议分析仪开始,逐步延伸到 NVMe 协议符合性测试、功耗测量、电压拉偏、异常掉电、热插拔、信号毛刺注入、高低温环境以及自动化测试平台的搭建。
整个交流最终落到了一个非常实际的问题上:
对于一块面向航空/航天和工业应用的定制 SSD,究竟应该怎样搭建一套既有标准、又能贴近真实业务场景的测试系统?
交流一开始,大家首先讨论的是 PCIe 协议分析仪。
PCIe 协议分析仪的基本作用,是把主机与设备之间传输的 PCIe 数据包完整抓取下来,然后按照物理层、数据链路层、事务层以及上层 NVMe 协议进行解码。
例如,当一块 SSD 突然掉盘时,我们通常会问:
这些问题,仅靠操作系统日志往往很难回答。
操作系统只能告诉我们“盘不见了”或者“命令超时了”,但它不一定能够还原掉盘之前几百毫秒内 PCIe 总线上发生了什么。
协议分析仪通常需要在主机和 SSD 之间插入一个 Interposer,也就是协议采集转接治具,需要interposer将PCIe双向差分信号以及sideband等信号全部引入PCIe协议分析仪,所以,分析仪本身是一个旁路设备。
这里有一个很容易被忽视的问题:
Interposer 本身不能明显改变原来的 PCIe 链路。
如果为了抓包而插入的设备对信号进行了重新驱动、重新定时或者过度均衡,那么原来系统中的信号问题可能反而被“修好”了。
最后就会出现一种很尴尬的情况:
不接分析仪时,SSD 经常掉盘; 接上分析仪后,问题却消失了。
这种情况下,分析仪虽然抓不到错误,但并不代表系统真的没有问题,而有可能是测试工具改变了原来的连接状态。
以 SerialTek 的 SI-Fi Interposer 的专利技术的信号高保真为例,其公开资料描述的方式是将每条 Lane 的模拟信号分配到主机、设备和分析仪采集路径,并尽量保持原有链路训练过程;同时,Sideband 信号也可以提供给分析仪进行触发和解码。其设计目标正是减少测试治具对原链路的干扰。
协议分析仪最适合处理的是“根因定位”:
但协议分析仪并不等于完整的 SSD 测试平台。
它更像一台“事故现场记录仪”:当系统已经出现问题时,帮助工程师看清问题发生前后的总线行为。
随着交流深入,客户逐渐把真实需求讲清楚了。
这次要验证的 SSD,并不是直接采购的通用消费级产品,而是面向特定系统使用的定制化 SSD。部分产品采用非标准机械结构和接口定义,需要先通过专门设计的 Adapter 转换成 M.2、U.2或者PCIe AIC等标准接口,才能接入商业测试设备。
需要验证的内容大致分为四类。
包括:
这些属于一块 NVMe SSD 最基本的“入门考试”。
客户并不满足于简单跑一个顺序读写结果,而是希望按照真实业务负载设计 Workload。
例如:
尽管组织方式非常分散的SNIA 的 Solid State Storage Performance Test Specification( SNIA SSS PTS),并不为业内SSD厂家认可,但它提供了预处理、稳态判断、IOPS、吞吐量、延迟和写饱和的一些测试方法,业内还是有些客户拿来作为不同 SSD 之间进行可重复性能比较的基础框架,但真实项目仍需在此基础上加入自己的业务负载。
客户还遇到过一种典型问题:
一块 SSD 在 PCIe Gen3 x4 模式下工作正常,但当链路降到 Gen2 x1、Gen3 x1,或者进入高温、低温条件后,稳定性明显下降。
这类问题既可能与 SSD 固件有关,也可能与:
有关。
因此,除了上层 NVMe 功能验证,还必须保留 PCIe 层面的诊断手段。
这才是本次交流的重点。
客户希望验证:
换句话说,他们真正想要的并不是一台“点一下开始、最后生成一份报告”的设备,而是一套能够围绕自身业务场景持续扩展的测试平台。
接下来的讨论围绕两种技术路线展开。
一体化设备的最大优点是省事。
设备中通常已经集成:
工程师选择测试项目、插入 SSD、点击开始,系统就可以自动执行。
这种方式特别适合:
当企业同时评估多家 SSD 供应商时,可以让所有产品运行同一套测试用例,最终按照通过、失败、警告和跳过的数量进行横向比较。业内的权威产品是SanBlaze系统,它是NVMe官方组织UNH IOL Labs官方指定的产品,可以唯一可以直接运行UNH IOL Labs的NVMe,NVMe-MI,以及NVMe over Fabric兼容性,是UNH IOL指定的唯一用来测试I2C/I3C的测试工具,也是唯一用来测试OCP认证的产品
模块化方案则是把不同功能拆开:
它的优点是灵活。
例如,在FIO写入到特定数据量时突然切断12V;或者先让SSD进入高负载,再在PCIe Lane 2上导入短时毛刺;也可以在高温环境下反复执行上电、掉电和数据校验。
对于本次客户而言,模块化路线显然更贴近实际需求。
因为他们的重点不是验证所有NVMe可选特性,而是把有限的测试资源集中在真实产品最容易出问题的场景上。这些场景就需要Quarch公司的几大类产品负责测试。
交流中还专门厘清了NVMe协议符合性测试的定位。
NVMe规范由NVM Express组织维护,而其官方符合性与互操作性测试项目长期与美国新罕布什尔大学互操作实验室UNH-IOL合作开展。通过相应测试的产品,可以进入NVMe Integrator’s List。
UNH-IOL的测试主要关注:
这些测试很重要,因为它能回答:
这块SSD的行为是否符合NVMe规范?
但它不能完全回答另一个问题:
这块SSD放进我们的设备,在我们的供电、温度、干扰和业务负载下,能不能长期稳定运行?
协议符合性是“基础体检”,场景可靠性则更接近“实战演练”。
两者不能互相替代。
在明确总体方向之后,交流开始进入具体工具。
首先讨论的是Quarch PPM,也就是Programmable Power Module,可编程电源模块。
正常情况下,SSD由主板或背板直接供电:
主机/背板 ↓ SSD
加入PPM后,测试治具会把主机原来提供给SSD的电源切断,再由PPM向SSD提供可编程电压:
主机/背板 ↓ PCIe数据与Sideband信号 Quarch Power Injection Fixture ↓ SSD
同时:
PPM ↓ 12V、5V或3.3V 测试治具 ↓ SSD
数据链路仍然经过原来的主机,只有供电改由PPM控制。
PPM并不只是把12V改成11V这么简单,而是可以编程输出一段完整的电压波形。
例如:
这样便可以模拟:
Quarch官方资料也将PPM定位为面向SSD、HDD及PCIe/SAS/SATA设备的可编程供电和功耗测量工具,可生成Ramp、Glitch、Brownout及Power Failure等波形。
对于航空/航天和工业设备,这类测试比单纯的额定电压测试更有价值。
因为实际系统中的电源问题,往往不是持续输出一个偏低电压,而是偶发、短暂并且难以复现的瞬态变化。
随后演示的是Quarch Hot-Swap/Breaker类模块,以及TestMonkey控制软件。
很多人理解的热插拔测试,是工程师站在设备旁边,不断把SSD拔出来再插进去。
这种做法有三个问题:
第一,连接器有寿命,不可能连续人工插拔几千次。
第二,每个人插拔的速度和动作不同,测试无法重复。
第三,真正的连接器并不是所有针脚同时接通,而是按照长针、短针以及电源、地、Present等不同顺序接触。
自动化Hot-Swap模块的价值,就是把物理插拔转换成可编程的电气插拔。
软件可以把不同针脚划分到多个Sequence Group中。
例如:
这可以模拟标准的连接器插入过程。
更重要的是,工程师也可以故意打乱顺序:
实际工程中,主机背板和连接器未必都严格符合标准。SSD厂商即使发现主机存在问题,也经常需要通过修改固件提高兼容性。
因此,能够重现“不标准的主机行为”,本身就是一种非常实用的调试能力。
Quarch的Gen5 U.2 Breaker模块可单独控制电源、Present、Sideband及PCIe数据线,并支持可编程插拔顺序、针脚Bounce和高速Glitch。其官方规格列出的开关控制分辨率为1微秒、Pin Bounce分辨率为100纳秒,并可产生50纳秒级的PRBS或用户定义毛刺。
演示继续深入到PCIe信号故障注入。
测试人员可以选择:
进行开路、短时断开或者毛刺注入。
如果SSD处于空闲状态,即使在链路上加入一次很短的毛刺,也可能正好没有数据包经过,最终看不出任何影响。
因此更有意义的测试方式是:
在错误较少时,PCIe链路可能通过重传机制恢复,应用层只表现为带宽轻微下降。
随着故障增加,可能逐渐出现:
这类测试的目的不是证明SSD在所有干扰下都不会出错。
更现实的目标是测出:
不同SSD面对相同错误时,谁恢复得更快,谁更容易掉盘,谁的固件异常处理更成熟。
实验室环境通常非常干净:
但真实设备内部可能完全不同。
在狭小机箱中,电源模块、计算板、交换板、存储板和各种高速接口集中在一起,EMI环境远比普通电脑复杂。
车辆、机载和其他移动平台还会叠加:
SSD在实验室里运行正常,装进设备后出现间歇性掉盘,并不罕见。
实验室不可能完全复制所有真实环境,但可以通过故障注入,把现场可能出现的影响转化成可控制、可重复的测试条件。
例如,用某条Lane周期性通断来模拟接触不良,用REFCLK毛刺模拟时钟干扰,用电压跌落模拟电源瞬态。
这样,原本“几天才偶发一次”的问题,就可能在几十分钟内稳定重现。
交流到这里,几种Quarch工具的分工逐渐清晰。
主要用于:
主要用于:
PAM是Power Analysis Module。
它和PPM最重要的区别是:
PPM主动代替主机给SSD供电,而PAM仍然使用主机或背板原本提供的电源,只在中间进行透明测量。
因此,当用户说:
这块SSD只有装在我的服务器里,运行我的业务程序时功耗才异常。
此时更适合使用PAM。
PAM可以同时记录:
因为电源仍来自真实主机,测到的是SSD在实际系统中的功耗行为,而不是外接实验电源下的结果。
Quarch对PAM的官方定位也是测量主机真实提供给DUT的电压、电流、功耗以及Sideband状态;PAM通过相应Interposer接入系统,问题复现后还可以再使用PPM或Breaker模块进行主动故障构造。
Quarch Power Studio可以记录长时间功耗波形。
测试脚本还可以把FIO输出的IOPS、带宽或其他业务指标作为用户数据加入同一条时间轴。
最终工程师可以在一张图中同时看到:
PAM最高可按照4微秒间隔采集功耗数据,也就是250KS/s;对于长时间测试,通常会选择更低采样率,以控制数据规模。
这种跨信号关联能力,对于分析偶发故障尤其有价值。
交流中还出现了一个常见误区:
看到SSD工厂里摆着大型机柜或高低温箱,里面一次插入几十、几百块SSD,很多人会认为这就是完整的SSD测试。
实际上,这更多属于生产测试、RDT或者老化筛选。
它解决的问题通常是:
而研发阶段的验证更关注:
此外,协议符合性测试关注的是SSD行为是否符合NVMe规范,性能测试则关注IOPS、吞吐量、延迟和稳态。
这几类测试可以互相补充,但不能画等号。
交流后半段,现场演示了一套SANBlaze桌面式NVMe SSD测试系统。
它本质上是一台高度集成的测试主机,内部已经包含:
SANBlaze SBExpress-DT5的官方功能也包括Power Up/Down、PERST、Hot Plug、Surprise/Graceful Removal、功耗测量、LTSSM监控以及Python、XML和REST API。
假设需要评估五家SSD供应商。
可以为所有产品选择同一组测试:
测试结束后,系统自动生成结果:
这样,采购方或产品导入部门就有了一把统一的尺子。
某家供应商第一次有几十项失败,修改固件后再测试;第二次减少到十几项;第三次全部通过。
这比仅凭厂商提供的宣传参数更有说服力。
SANBlaze现有自动测试体系可提供大量内置测试,并能够实时显示失败、跳过和警告;2025年开始,其平台成为UNH IOL Labs官方指定的唯一可以运行UNH-IOL INTERACT NVMe协议符合性软件。
SANBlaze也支持Python二次开发,但当测试逻辑涉及大量自定义业务状态、非标准接口、外部温箱和特殊触发条件时,开发复杂度会明显增加。
对于SSD主控和固件团队来说,这些API并不陌生。
但对于以系统应用为主的团队,如果只是想在“写入第100GB时突然切断某个针脚”,使用独立故障注入模块往往更加直接。
因此,本次交流形成的判断是:
三者并不是互相取代,而是处于不同层级。
客户还关心,这些测试模块能否直接放进高低温箱。
通常不建议把包含控制器、CPU和复杂管理电路的一体化测试主机直接放进温箱。
更常见的方式是:
这样既能保证测试设备正常工作,又能让SSD处于目标温度。
不过,延长线和转接板本身也会改变信号质量。
尤其在PCIe Gen4、Gen5环境中,线缆长度、连接器、转接板和背板损耗都有可能引入新的问题。
因此,高低温测试不能只记录“是否掉盘”,还应该同时记录:
交流接近尾声时,又讨论了一个很实用的问题:
在普通PC或服务器主板上直接测试SSD,主板本身的信号质量可能就不够好。
如果SSD发生掉盘,很难立刻判断究竟是:
一种常用的隔离方法,是在测试系统中加入PCIe Switch卡。
Switch会将一条链路变成两段:
CPU/Root Complex ↓ PCIe Switch ↓ SSD
如果SSD接在Switch后工作稳定,直接接主板却频繁进入Recovery,问题就可能更多集中在原主板链路上。
当然,加入Switch也改变了原来的拓扑,它不能代替最终真实环境测试。
它的价值在于“隔离变量”:
先建立一个信号质量较好的基准环境,确认SSD本身是否稳定;随后再回到真实系统,比较两个环境之间的差异。
当两种环境表现不同,再使用协议分析仪抓取链路训练和错误过程,定位效率会高很多。
经过两个多小时讨论,一套适合本项目的SSD测试平台逐渐清晰。
采用Linux测试主机,运行:
加入Quarch Hot-Swap/Breaker类热插拔/故障注入工具,完成:
使用PPM完成:
使用PAM完成:
使用SANBlaze或者同类平台完成:
正式的NVMe协议符合性和互操作性认证,可根据项目需要通过UNH-IOL体系完成。
当测试出现以下问题时,再接入SerialTek PCIe协议分析仪:
这样可以避免把昂贵的协议分析仪用于每一次普通测试,同时又保留最终定位复杂问题的能力。
结合本次交流,建议把测试流程分成八个阶段。
在常温、额定电压和稳定PCIe链路下,确认:
按照实际应用建立Workload,而不是只看厂商标称参数。
记录:
分别测试:
在不同写入阶段切断电源:
重新上电后检查:
逐Lane执行:
记录SSD的容错边界和恢复能力。
把温度、供电和IO组合起来:
很多问题只有在两个或三个条件同时出现时才会暴露。
要求供应商提供正式测试报告,或者使用统一平台进行复测。
标准测试不用全部自行开发,但必须作为供应商准入的基础门槛。
所有出现过的问题都应转化为自动化回归用例。
第一次定位问题可能需要几天;一旦问题被理解,就应该把触发条件固化到脚本中。
之后每次更新SSD固件,都自动重跑。
这样,测试平台才会随着项目积累逐渐变得有价值,而不是每次遇到问题都从头分析。
这次交流最重要的结论,不是哪一家设备功能最多,也不是哪一台设备能够包办所有测试。
真正重要的是先把测试目标分清楚。
对于航空/航天、工业和其他高可靠应用来说,SSD测试绝不能停留在“能识别、能读写、能跑FIO”的阶段。
真正可靠的测试平台,应该能够主动制造问题、稳定复现问题、记录问题,并最终把一次偶发故障变成一条可以重复运行的自动化测试用例。
不是等SSD在现场掉盘以后再去猜原因,而是在它交付之前,就尽可能把那些最难看的错误提前逼出来。
这才是SSD可靠性验证真正的价值。
本文根据2026年7月21日SSD测试技术交流整理。文中涉及的产品功能和技术规格,已结合Quarch、SANBlaze、SerialTek、NVM Express、UNH-IOL及SNIA公开资料进行核对;具体配置仍应以厂商最新版本、许可证和对应接口模块为准。
更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND, UFS, 新型存储技术NVM(RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等) DDR5/LPDDR5以及UFS测试方面的问题想咨询,可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本,我们已经整理收录在Saniffer公众号的【白皮书】菜单中。
欢迎关注Saniffer公众号,点击底部菜单栏即可免费获取。如有任何技术问题,也可直接在公众号内留言交流。