3. 验收依据与标准体系
HIL（硬件在环）验收不是“把台架跑通”就算完成，而是要用一套可追溯的准则证明：被测对象在真实控制器硬件、真实接口和受控仿真环境下，满足既定功能、性能与安全目标。航空航天与汽车领域的标准体系各有侧重，验收时不能整本照搬，而要先识别“适用条款”，再做“裁剪”，最后把裁剪结论固化为验收依据。
一、五类标准在HIL验收中的定位
GJB（国军标）是军工型号研制的顶层依据，常涉及GJB 9001C质量管理、GJB 5000A软件研制能力、GJB 2786A军用软件开发、GJB 438B文档规范等。在HIL验收中，GJB更多约束“过程合规与文档证据”：例如测试计划、测试说明、测试报告是否按GJB 438B的格式与评审要求闭环，测试环境是否纳入配置管理，问题是否按FRACAS（故障报告、分析与纠正措施系统）闭环。它通常不直接规定HIL台架的信号精度，但会要求“测试覆盖需求、结果可追溯”。
DO-178C针对机载软件，按A~E五个等级（DAL）规定目标。HIL验收中，它决定“软件测试目标与覆盖要求”：DAL A要求MC/DC覆盖、鲁棒性测试、验证独立性；DAL C通常要求语句覆盖与需求覆盖。HIL台架上的软件在环部分，需按对应DAL裁剪测试深度，例如DAL A必须做需求覆盖+结构覆盖+独立性验证，DAL D可仅做需求覆盖。
DO-254针对机载复杂电子硬件（如FPGA、ASIC）。HIL验收中，它约束“硬件实现与验证证据”：FPGA的DO-254验证可用HIL台架注入激励，观察硬件输出是否符合需求，但需注意HIL不能完全替代形式验证或时序分析。裁剪时，若器件为简单硬件（如分立逻辑），可降低验证严格度；若为复杂硬件且承担DAL A功能，则需保留需求追溯、覆盖分析与独立验证。
ARP4754A是民用飞机与系统研制保证的顶层标准，强调“系统级需求—架构—验证”的分配与追溯。HIL验收中，它决定“系统需求如何分解到HIL测试用例”：每个系统级需求应能映射到至少一个HIL测试用例，且测试结果要回写到验证矩阵。裁剪时，若系统为简单改装或非关键功能，可减少系统级验证的独立性要求，但需求追溯链不能断。
ISO 26262针对道路车辆功能安全，按ASIL A~D分级。HIL验收中，它约束“安全目标与故障注入”：ASIL D要求故障注入覆盖、安全机制验证、高诊断覆盖率；ASIL A可简化。HIL台架需能模拟传感器故障、通信丢帧、执行器卡滞等，验证安全机制是否在规定时间内进入安全状态。裁剪时，若功能为QM（质量管理）等级，可不做ASIL级故障注入，但仍需做基本功能测试。
二、裁剪方法：从“等级”到“证据深度”
裁剪不是删条款，而是按风险等级调整证据深度。建议按以下四步执行：
- 定级：先确定被测功能的安全等级。机载软件查DO-178C的DAL，硬件查DO-254的复杂/简单硬件分类，系统查ARP4754A的功能危害等级，汽车查ISO 26262的ASIL。等级是裁剪的输入，不是裁剪的结果。
- 映射：把标准条款映射到HIL可执行的测试活动。例如DO-178C的“需求覆盖”映射为“每条软件需求至少一个HIL用例”；ISO 26262的“安全机制验证”映射为“故障注入后安全状态在FHTI内到达”。
- 判定可覆盖性：HIL擅长验证接口时序、信号精度、故障响应、边界条件；不擅长替代形式验证、时序分析、代码级覆盖。不可覆盖项必须保留原验证手段，不能因“HIL已做”而删除。
- 记录与审批：裁剪结论要写成“裁剪说明表”，包含条款号、原要求、裁剪后要求、理由、风险、审批人。该表本身就是验收依据的一部分。
三、验收依据的落地形式
最终验收依据通常由三份文件构成：验证矩阵（需求—用例—结果—标准条款四列追溯）、裁剪说明表（记录保留/简化/替代的决策）、HIL测试报告（含原始数据、判据、结论）。验证矩阵是主线，裁剪说明表是“为什么这样测”的解释，测试报告是“测到了什么”的证据。
四、裁剪决策的检查要点
| 检查项 | 判断依据 | 不通过时的处理 |
|---|---|---|
| 等级是否明确 | DAL/ASIL/硬件分类有正式文件 | 补充定级分析，不得先裁剪后定级 |
| 条款是否可追溯 | 验证矩阵含标准条款列 | 补映射，禁止“只测需求不挂标准” |
| 不可覆盖项是否保留 | 形式验证、时序分析等未被HIL替代 | 恢复原验证手段或说明替代等效性 |
| 裁剪是否有审批 | 裁剪说明表有签署 | 退回补充审批，验收依据不成立 |
| 台架能力是否达标 | 信号精度、延迟、故障注入满足用例 | 先做台架校准，再执行验收测试 |
把上述内容串起来，HIL验收依据就不是“一堆标准名称”，而是一条可执行的证据链：功能定级 → 条款映射 → 裁剪决策 → 用例执行 → 结果回写 → 审批闭环。只有这条链完整，验收结论才经得起审查。