3. 项目验收标准体系构建

MicroAutoBox 项目验收最容易出现的问题，不是“没测”，而是“测了但判据不统一”。同一个控制器，软件工程师认为功能跑通即可，功能安全工程师要求故障注入后进入安全状态，HIL 测试工程师关注 1 ms 任务是否丢帧，集成工程师则盯着 CAN 报文和标定量是否一致。若验收准则不事先定义，最终会变成各说各话。因此，验收标准体系的核心任务，是把“需求—准则—判据—证据”四者绑定成可追溯的链条。

一、验收准则的四个维度与判据形式

MicroAutoBox 作为快速控制原型（RCP）平台，其验收准则通常从四个维度展开，每个维度都要落到可判定的判据上，而不是停留在“满足要求”这类描述。

判据必须可量化、可复现、可留证。例如“响应快”不是判据，“从阶跃输入到输出达到 90% 稳态值的时间 ≤ 20 ms，连续 10 次测试均满足”才是判据。判据还应写明测试条件：供电电压、环境温度、总线负载、软件版本，否则同一判据在不同条件下会得出相反结论。

二、从需求到判据的分解方法

建议采用“需求条目 → 验收准则 → 通过判据 → 证据形式”的四级分解。以一条典型需求为例：

需求 REQ-012：当车速信号丢失时，控制器应在 100 ms 内将驱动扭矩请求降为 0。
验收准则 AC-012：故障响应时间与安全输出。
通过判据：
  1) 注入车速信号丢失故障；
  2) 从故障注入时刻到扭矩请求 ≤ 5 N·m 的时间 ≤ 100 ms；
  3) 故障码 P0C01 置位，且故障恢复后需手动清除；
  4) 连续 20 次测试，超时次数为 0。
证据形式：CANoe 报文日志、扭矩请求曲线、故障码读取记录。

这种分解方式让每条需求都有唯一对应的判据和证据，验收时只需核对证据是否齐全、判据是否满足，避免主观判断。对于功能安全相关需求，还应标注 ASIL 等级，并说明判据是否覆盖了安全机制的诊断覆盖率要求。

三、实时性判据的量化与测量

实时性判据不能只看“程序能跑”，而要量化任务周期、抖动和 CPU 负载。MicroAutoBox 常用 1 ms 基础任务，判据可定义为：任务周期抖动 ≤ 50 μs，最大执行时间 ≤ 周期的 60%，CPU 负载 ≤ 80%，且在整个测试工况中无超限。测量时通过 dSPACE 的实时监控或 Trace 工具采集任务时间戳，统计抖动分布。

需要注意的是，实时性判据应在最坏工况下验证，例如总线负载最高、故障注入同时发生、标定量在线修改时。若只在空载下测量，判据不具备说服力。判据中应明确“最坏工况”的定义，例如 CAN 总线负载 70%、同时注入两个故障、标定量在线写入。

四、接口一致性判据的核对方式

接口一致性包括通信接口和 I/O 接口。通信接口判据可定义为：实测 CAN 报文的 ID、DLC、周期、信号物理值范围与 DBC 描述一致，偏差在允许范围内；I/O 接口判据可定义为：模拟输入在 0～5 V 范围内，采集值与参考值的误差 ≤ 1% FS；数字输出高低电平与负载要求匹配。核对时应使用 DBC 自动比对脚本或 CANoe 的数据库校验功能，逐条输出不一致项，而不是人工抽查。

五、判据的通过/不通过判定与偏差处理

验收判定应遵循“全维度通过”原则：需求规格、功能安全、实时性、接口一致性四个维度全部满足判据，项目才判定为通过。任一维度不满足，即判定为不通过，并记录偏差项。偏差项应包含需求编号、判据、实测值、偏差原因、整改责任人和复测计划。例如实时性判据中抖动实测为 72 μs，超出 50 μs 限值，偏差原因可能是某个 1 ms 任务中包含了阻塞式 CAN 发送，整改方式是将发送改为非阻塞或移入低优先级任务，复测时重新采集抖动分布。

六、验收准则的可追溯性维护

验收标准体系不是一次性文档，而应随需求变更同步维护。建议用需求管理工具建立“需求—准则—判据—证据”的追溯矩阵，每条需求至少对应一条准则和一条判据，每条判据至少对应一份证据。当需求变更时，追溯矩阵能快速定位受影响的判据和已完成的测试，避免遗漏复测。对于 MicroAutoBox 项目，追溯矩阵还应关联软件版本号、A2L 文件和 DBC 版本，确保验收证据与受控版本一致。

综上，验收标准体系的构建，本质上是把模糊的“应该没问题”转化为可量化、可复现、可追溯的判据集合。需求规格、功能安全、实时性、接口一致性四个维度各有侧重，但都必须落到明确的测试条件、量化阈值和证据形式上。只有这样，MicroAutoBox 项目验收才能从“凭感觉”走向“凭证据”。