3. 量产验收测试需求分析与追溯
量产验收阶段的HIL测试，与开发早期“验证功能是否做出来”的HIL测试有本质区别：它要回答的是“这个ECU在整车环境下、在法规与安全约束下，是否可以被批准放行”。因此，验收需求不能由测试工程师凭经验临时拟定，而必须从四类上游规范中系统提取：功能安全概念（FSC/TSC）、法规与认证要求、整车网络通信矩阵、ECU诊断规范。本节讨论如何把这四类“规范语言”翻译成可执行的HIL验收需求，并建立需求—用例—资产的可追溯链。
四类上游规范各自贡献什么验收需求
功能安全类规范（ISO 26262 相关）主要贡献安全机制的可观测性与故障响应需求。例如某EPS控制器的安全目标为“避免非预期助力扭矩”，其技术安全需求可能规定：当扭矩传感器双通道偏差超过阈值且持续超过100 ms时，应在50 ms内进入安全状态（助力降为0并点亮故障灯）。这条需求在HIL上就转化为：注入双通道偏差信号、计时偏差持续时间、测量从超阈到助力归零的响应时间，并检查故障灯输出。注意这里的关键是“可注入、可观测、可计时”，凡是无法在HIL台架上构造或测量的安全需求，都要在需求分析阶段标记为“需台架/实车补充”，而不是硬塞进HIL用例。
法规类要求（如UN R79、R13H、国标相关条款）通常以场景和限值形式出现，例如“在指定减速度下制动灯应在规定时间内点亮”。这类需求提取时要特别关注法规中的边界条件与容差，因为它们直接决定用例的通过判据。整车网络类规范（CAN/CAN FD/LIN通信矩阵、网络管理、E2E保护）贡献的是通信层验收需求：报文周期偏差、超时判定、E2E计数器与CRC校验、网络管理睡眠唤醒时序等。ECU诊断规范（UDS/OBD、DTC定义、诊断会话与例程）贡献的是诊断层验收需求：DTC置位与恢复条件、快照/扩展数据记录、$27安全访问、$2E写入后的掉电保持等。
从规范条款到HIL验收需求的翻译方法
翻译的核心动作是“把规范中的名词映射到台架上的信号与变量”。以一条整车网络需求为例：“VCU发出的扭矩请求报文周期为10 ms，超时判定时间为30 ms，接收方应在超时后进入默认扭矩”。在HIL上，这条需求映射为：用CANoe/CANape等工具监测该报文周期并统计抖动；通过网关或残余总线仿真停止发送该报文；测量ECU进入默认扭矩的时间与默认值。这里需要明确参照约定：本文所有“响应时间”均定义为从激励条件成立到观测信号达到判据阈值的时长，正向为时间增加方向，全文与图示保持一致。
对于诊断需求，翻译时要区分“功能寻址”与“物理寻址”两条路径，因为很多DTC的置位条件在两种寻址下的表现不同。例如某DTC要求“连续3个驾驶循环故障未再现则熄灭”，HIL用例就需要构造可重复的驾驶循环序列，并在每个循环后读取DTC状态字节（bit0 testFailed、bit3 confirmedDTC等），而不是只读一次故障码。
需求—用例—资产追溯链的建立
追溯链的价值在于：当某条法规条款更新、或某个安全机制变更时，能快速定位受影响的用例、模型、标定文件和测试脚本，评估回归范围。追溯链的基本结构是：上游规范条款 → HIL验收需求（唯一ID）→ 测试用例（唯一ID）→ 测试资产（模型、脚本、标定、配置、数据集）。
建立追溯链时，需求ID建议采用“来源域-序号”格式，例如 FS-012（功能安全第12条）、RG-005（法规）、NW-021（网络）、DG-008（诊断）。用例ID与需求ID建立多对多映射：一条需求可能对应多个用例（正常、边界、故障注入），一个用例也可能覆盖多条需求。资产则通过用例脚本中的引用关系反向关联。下面给出一个可直接使用的追溯矩阵示例（示例数据为教学假设，非实测结果）：
| 需求ID | 来源 | 需求摘要 | 用例ID | 关键资产 | 判据 |
|---|---|---|---|---|---|
| FS-012 | FSC/TSC | 双通道偏差>阈值100 ms内助力归零 | TC-101/102 | EPS_HIL模型、故障注入脚本 | 响应≤50 ms，助力=0 |
| RG-005 | UN R13H | 指定减速度下制动灯点亮时间 | TC-205 | 制动灯采集通道、场景脚本 | 点亮时间在容差内 |
| NW-021 | 通信矩阵 | 扭矩请求报文周期10 ms，超时30 ms | TC-310/311 | 残余总线仿真、网关配置 | 周期偏差≤±10%，超时后默认值正确 |
| DG-008 | 诊断规范 | 连续3驾驶循环未再现则DTC熄灭 | TC-420 | 诊断脚本、循环序列配置 | 状态字节按预期迁移 |
追溯链建立后，还要做一次“覆盖率与缺口检查”：每条上游规范条款是否至少映射到一条需求；每条需求是否至少有一个用例；每个用例是否引用了真实存在的资产。常见缺口是“有需求无用例”（如某些E2E保护需求被遗漏）和“有用例无需求”（测试人员自行添加的探索性用例，应标注为补充用例而非验收用例）。
追溯链的维护与变更影响分析
追溯链不是一次性文档，而是随项目演进的活数据。当某条法规条款修订（例如限值收紧），影响分析路径是：法规条款 → 关联需求ID → 关联用例ID → 关联资产。若某条需求被修改，需要重新评估其所有用例的判据是否仍然有效；若某个资产（如HIL模型）被更新，需要反向检查哪些用例引用了它，从而确定回归测试范围。图中右侧的虚线箭头即表示这种反向追溯关系。
在实际项目中，建议把追溯矩阵维护在需求管理工具（如DOORS、Polarion或Jama）中，并通过脚本从测试执行工具（如dSPACE AutomationDesk、CANoe）自动回写用例执行结果与资产版本号。这样在量产验收评审时，可以直接输出“需求覆盖率”“用例通过率”“资产版本一致性”三类证据，而不是靠人工整理表格。
最后需要强调，HIL验收需求提取的边界要清晰：凡是HIL台架无法真实构造的工况（如真实路面附着系数变化、极端温度下的传感器特性漂移），应在需求阶段明确标注“由实车或环境舱补充验证”，并在追溯链中保留该需求的验证方式字段。这样既保证验收证据链完整，也避免在HIL上做无效的“伪验证”。