1. 课程导入与HIL平台交付全景
飞控HIL（Hardware-in-the-Loop，硬件在环）平台，是把真实飞控计算机、真实接口链路与实时仿真环境连接起来的半实物测试系统。它让飞控软件在接近真实传感器、执行机构与飞行动力学的条件下运行，从而在飞行试验之前暴露控制律、时序、接口与故障处理问题。而“校准、验收与交付”关注的不是某一次仿真跑通，而是这套平台能否被证明可信、可用、可移交：校准解决“测得准不准”，验收解决“是否满足约定要求”，交付解决“别人能不能独立、正确地使用与维护”。
很多团队把这三件事混成一次“联调通过”。典型后果是：仿真模型参数与真实对象存在偏差却未量化，验收时只看了曲线“长得像”，交付时只留下一台能跑的机器和零散脚本。接手方一旦更换舵机、修改气动数据或升级飞控固件，就不知道哪些结论仍然成立。因此，本课程的第一条主线，是把校准、验收、交付拆成边界清晰、证据可追溯的三类活动，并明确它们各自的输入、输出与责任角色。
三类活动的边界与证据链
校准的对象是“测量与映射关系”。在HIL平台中，至少包括三类：一是传感器通道校准，例如大气数据、IMU、磁罗盘经接口板进入仿真机的量值与物理量之间的比例、偏置和符号关系；二是执行机构通道校准，例如PWM或总线指令到舵面偏度、油门推力的映射；三是时间基准校准，例如仿真步长、接口采样周期、飞控控制周期之间的时序对齐。校准的输出不是“调好了”，而是一组可复现的系数、残差与不确定度记录。
验收的对象是“平台对需求的符合性”。它依据的是需求规格与验收大纲，而不是开发者的主观判断。验收通常覆盖功能、性能、接口、故障注入、安全联锁与可重复性。例如：姿态角注入误差是否在允许带内、故障注入后飞控是否在规定周期内进入预定模式、连续多次上电后零偏是否一致。验收的输出是带判定结论的测试记录与偏差清单。
交付的对象是“可独立运行与持续维护的能力”。它包括硬件配置清单、软件与模型版本、参数文件、标定数据、操作手册、故障处置说明、备件与工具，以及一次由接手方主导、交付方旁站的验收复现。交付完成的标志，不是文件签收，而是接手方能在不依赖原开发者口头指导的情况下，独立完成一次标准测试并得到一致结论。
从需求到移交的完整流程与角色分工
一个可落地的HIL平台交付流程，通常沿“需求—设计—集成—校准—验收—交付—移交后支持”推进。需求阶段要冻结被测对象范围、接口清单、仿真置信度目标与验收判据；设计阶段确定实时机、接口板卡、负载模拟、故障注入与安全联锁方案；集成阶段完成信号连通与基本回环；随后进入校准与验收；最后完成文档、培训与复现移交。
角色上，需求方（或总体单位）负责提出并确认验收判据；平台开发方负责实现与自测；独立测试或质量角色负责见证关键项并核对证据；飞控专业负责确认被测对象的接口与时序约束；接手方在交付阶段从“旁观”转为“主操作”。关键里程碑建议设置为：需求与判据冻结、平台集成完成、校准数据评审通过、验收大纲执行完毕、交付复现通过。每个里程碑都应有明确的准入与退出条件，避免“差不多就进入下一阶段”。
关键里程碑的准入与退出条件
里程碑不是日历节点，而是“证据齐备才放行”的闸门。以校准评审为例，准入条件包括：所有通道已完成标定、原始数据与处理脚本可追溯、异常通道已闭环；退出条件包括：残差与不确定度满足预定阈值、评审意见关闭、校准版本号冻结。验收通过同样需要明确：测试用例覆盖率、未关闭偏差的处理结论、复测记录。交付复现则要求接手方独立完成至少一轮标准测试，且结果与交付方记录在允许误差内一致。
为了让流程可执行，建议在项目早期就建立一份“交付物—责任人—完成判据”对照表。下面给出一个可直接裁剪使用的示例，字段只保留HIL交付真正需要的内容：
| 阶段 | 核心交付物 | 责任人 | 完成判据（示例） |
|---|---|---|---|
| 需求冻结 | 验收大纲、接口清单、置信度目标 | 需求方 + 飞控专业 | 判据可测量、双方签字确认 |
| 集成完成 | 信号连通记录、回环测试报告 | 平台开发方 | 全部通道可注入/采集，无未解释断链 |
| 校准评审 | 系数表、残差曲线、不确定度说明 | 平台开发方 + 独立测试 | 残差在阈值内，脚本可复现 |
| 验收执行 | 测试记录、偏差清单、复测结论 | 独立测试 + 需求方 | 关键项全部通过，偏差有处理结论 |
| 交付移交 | 配置基线、手册、培训记录、复现报告 | 平台开发方 + 接手方 | 接手方独立复现结果一致 |
教学示例：一次姿态通道校准与验收判定
假设某HIL平台需要校准滚转通道。仿真机输出滚转角指令，经接口板转换为飞控可接收的信号，飞控解算后再回传。示例设定：指令范围 ±30°，允许的稳态误差不超过 0.5°，零偏不超过 0.1°。操作上，先注入 -30°、-15°、0°、+15°、+30° 五个点，每个点稳定后记录飞控回传值，重复三轮。若某点误差为 0.8°，则先检查接口板增益与符号，再检查飞控内部标定是否被覆盖，而不是直接修改仿真模型“凑曲线”。校准完成后，把系数、残差和三轮重复性写入记录，作为验收的输入证据。
验收时，不应只看单点误差，还要看重复性与回程差：同一指令点三轮之间的离散程度、正反行程的差异，往往比单次误差更能暴露接口或时序问题。若重复性超限，即使均值合格，也应判定为不通过并回到校准或集成阶段排查。这正是“证据链”思维：结论必须由可复现的数据支撑，而不是由一次好看的曲线支撑。
回到全景：校准、验收与交付不是三次独立检查，而是一条以证据为纽带的链路。需求冻结决定“验什么”，校准决定“测得准不准”，验收决定“是否达标”，交付决定“能力是否真正转移”。只有把角色、里程碑与交付物在项目早期就定义清楚，后续的每一次测试、每一组数据、每一份文档才能各归其位，最终形成一套可被接手方独立运行、持续维护的飞控HIL平台。