测试系统开发：把需求翻译成台架

开发一套 HiL 系统，最难的从来不是把设备买齐，而是把一句“支持某功能测试”翻译成可执行、可验证、可维护的工程结构。

需求文档里写的是功能，台架上要落地的是电压、电流、时序和信号。中间这一步，才是测试系统开发真正的专业所在。

一、起点不是设备清单，而是信号清单

拿到项目后，我会先把功能规范拆成一张信号清单：模拟量有多少路，数字量有多少路，PWM 与频率量有多少，总线报文有哪些，电源通道怎么分配。

每一路信号都要写清楚四件事：量程、精度、采样率、故障注入方式。设备选型是在这张表之后才发生的事。反过来先定设备，再去找信号塞进去，几乎一定会留下通道不够或者精度不足的坑。

资源预算要留余量。我的习惯是模拟量和数字量各留 20% 到 30%，电源通道留一路备用。项目中期总会冒出新的观测点，没有余量就只能推翻重做。

二、三条链必须对齐

一套台架能不能用，取决于电气链、信号链和逻辑链是否对齐。

电气链关心的是电平、驱动能力、隔离和共地。传感器信号是电压型还是电流型，执行器需要多大电流，需不需要续流回路，这些决定硬件方案。

信号链关心的是采样率、滤波和延迟。模型里的一阶滤波很好看，但它可能让一个 10 毫秒的脉冲消失在采样窗口里。测试关心的时序，必须比被测件的时间常数更快。

逻辑链关心的是模型与被测件的时序关系。谁先发报文，谁先建立状态，谁在超时后恢复。很多“偶发失败”不是算法错了，而是时序在两个系统之间错开了。

三、模型：保真度服务于测试目的

仿真模型不需要像真车一样复杂，它需要在该准确的地方准确。

如果测试项关心的是温度对充电策略的影响，模型就必须保留热模型的主要时间常数；如果关心的是通信超时后的降级，那么总线的调度和超时行为比机械结构重要得多。

模型版本必须与被测软件版本绑定。只写“使用最新模型”是不够的，半年后没有人能复现当时的结果。我会在台架基线里同时记录模型版本、参数集和编译时间。

四、故障注入与安全

故障注入是 HiL 相对实车最大的优势，也是最容易被做成摆设的部分。

开路、短路、对电源、对地、信号偏移、卡滞，每一种故障都要在信号清单里有明确的实现方式。故障矩阵最好在开发阶段就画出来，而不是测试当天临时接线。

安全设计要独立于被测逻辑。急停、互锁、限流、过温保护，这些不能依赖模型来保证。高压或者大电流场景下，失效安全是第一优先级，测试效率排在它后面。

五、集成与验收

集成按单点、子系统、整车功能三层推进。单点验证信号通不通，子系统验证闭环对不对，整车功能验证场景是否成立。

验收标准要提前写死：信号精度、响应延迟、重复性、连续运行稳定性、故障注入覆盖率。还有一个经常被忽略的指标：可维护性。

接线图、针脚表、资源分配表、版本基线，这四份文档缺一不可。台架不是给开发者一个人用的，它要在半年后交给另一个人继续跑。

六、几个常见的坑

地环路会带来莫名其妙的漂移，共模干扰会让采样值在边界上跳动；PWM 输出的驱动能力常常被低估；继电器有机械寿命，频繁切换的通道应该换成固态方案；线束没有标识，排查一次故障就要多花一倍时间。

这些问题单看都很小，但它们决定了台架是“能演示”还是“能生产”。

好的测试系统不是看起来复杂，而是别人接手时，能照着文档把它重新跑起来。