1. 课程导入与全景认知

硬件在环（Hardware-in-the-Loop，HIL）验收与交付，是航空航天型号研制中把“仿真环境里能跑”转化为“可被客户、适航与总体单位共同接受”的关键环节。它既不是单纯的测试执行，也不是一次性的文档移交，而是一条贯穿需求、建模、实时仿真、接口适配、试验执行、问题闭环与证据归档的工程链路。本课程后续所有章节，都将围绕这条链路展开。

一、定义：HIL验收与交付到底在做什么

HIL验收，指在真实控制器（如飞控计算机、发动机控制器、机电管理计算机）接入实时仿真环境后，依据经确认的验收准则，对系统功能、性能、接口、故障响应与安全逻辑进行验证，并形成可追溯结论的过程。HIL交付，则是把通过验收的HIL系统及其配套资产——模型、接口定义、测试用例、试验数据、问题记录、使用手册与配置基线——完整移交给接收方，使其具备独立运行、维护和扩展能力。

两者关系可以概括为：验收回答“是否满足要求”，交付回答“能否持续使用”。只做验收不做交付，接收方拿到的是“一次性结论”；只做交付不做验收，移交的是“未经验证的能力”。

二、边界：哪些属于HIL验收与交付，哪些不属于

明确边界能避免项目后期出现责任争议。通常，HIL验收与交付覆盖以下范围：

• 实时仿真平台与被测控制器之间的电气接口、总线接口与信号映射；
• 被控对象模型、环境模型、传感器与执行机构模型的实时运行正确性；
• 测试用例、激励脚本、自动化测试序列及其预期结果；
• 故障注入、边界条件、异常工况与安全保护逻辑的验证；
• 试验数据、曲线、日志、问题单与验收报告的归档。

而以下内容一般不属于HIL验收与交付的核心边界：控制器内部软件代码的单元测试、纯数字仿真阶段的模型校核、整机物理试验（如铁鸟台、试车台）的最终适航符合性结论。它们与HIL相关，但责任主体和证据层级不同。边界一旦模糊，最容易出现“模型精度问题被当成控制器问题”或“接口时序问题被归为模型问题”的扯皮。

三、利益相关方：谁提出要求，谁接收结果

HIL项目的利益相关方不是单一客户，而是一个多角色网络。典型角色包括：

• 型号总体/系统总体：提出顶层验证需求，关注HIL结论能否支撑型号节点；
• 控制器研制方：提供被测件，关注接口定义、故障注入方式与问题定位效率；
• HIL集成方：搭建实时平台、模型与接口，关注验收准则是否可实现；
• 测试/验证团队：执行用例、记录数据、判定通过与否；
• 质量与适航代表：关注证据链完整性、可追溯性与配置管理；
• 接收/运维团队：关注交付后能否独立操作、维护和扩展。

这些角色的关注点并不一致。总体要结论，控制器方要问题定位，集成方要可执行准则，质量方要证据，接收方要可维护性。验收与交付计划必须同时回应这五类诉求，否则容易出现“测试通过了但接收方不会用”或“文档齐全但关键问题未闭环”的局面。

四、典型项目阶段与交付物清单

一个完整的HIL验收与交付项目，通常经历五个阶段：需求与准则确认、环境搭建与联调、测试执行与问题闭环、验收评审、交付与培训。每个阶段的输入、输出和判断依据不同，交付物也随之递进。

需要强调的是，交付物不是“最后一次性打包”，而是随阶段逐步冻结。验收准则在阶段①确认后应纳入配置管理；接口映射表在阶段②联调后冻结；测试用例在阶段③执行前完成评审；证据索引在阶段④评审前完成归档；交付基线包在阶段⑤移交时完成签署。任何一项滞后，都会导致后期返工。

五、一个可参考的验收准则示例

以某型飞控计算机HIL验收为例，验收准则可以写成可判定的条目，而不是模糊描述。例如：

这类准则的价值在于：测试人员知道怎么判，质量人员知道查什么，接收方知道系统被验证到什么程度。示例中的参数（1ms、50μs、200ms）属于教学假设，实际项目应按型号要求与ICD确定。

六、本课程的学习路径

后续章节将沿着上述五个阶段展开：先讲需求与准则如何写、边界如何划；再讲实时平台、模型与接口如何搭；然后进入测试执行、故障注入与问题闭环；接着讲验收评审与证据组织；最后讲交付、培训与运维移交。每一章都会给出可操作的清单、参数示例或判断依据，帮助你把“知道要做什么”推进到“知道怎么做、怎么判”。

本章需要记住三句话：验收是准则驱动的判定，交付是能力转移的移交，边界是责任划分的前提。把这三件事在项目早期说清楚，后面的技术工作才有稳定的落脚点。