1. 课程导入与HIL测试全景

多旋翼飞控的软件质量，最终要在真实飞行中体现，但真实飞行成本高、风险大、复现难。一次姿态控制参数改动，如果直接上机试飞，可能因为一个符号错误导致炸机；一次返航逻辑修改，如果只在仿真环境中跑过理想模型，也可能在真实风扰下暴露问题。硬件在环（Hardware-in-the-Loop，HIL）测试，正是为了解决“真实控制器 + 虚拟被控对象”这一对矛盾而存在的工程手段。

简单说，HIL测试就是把真实的飞控硬件（飞控板、传感器、执行机构接口）接入一个实时仿真系统，由实时机运行多旋翼的动力学模型、传感器模型和环境模型，通过电气接口与飞控交互。飞控以为自己正在控制一架真实的多旋翼，实际上它面对的是实时计算出来的虚拟飞机。这样既保留了真实飞控的时序、接口和计算特性，又能安全、可重复地注入各种飞行场景和故障。

在典型工程场景中，HIL测试覆盖的范围很广。例如，在飞控固件迭代时，用HIL回归验证姿态控制律是否仍然稳定；在新增返航或避障逻辑时，用HIL构造GPS丢失、磁罗盘受扰、电池电压骤降等故障场景；在交付客户前，用HIL批量跑完数百条用例，生成测试报告作为放行依据。这些场景的共同点是：需要真实飞控参与，但又不适合或不允许真实飞行。

要理解HIL自动化测试，需要先看清它的整体技术栈。最底层是实时仿真平台，通常由实时操作系统和实时机组成，负责以固定步长（例如1 kHz或500 Hz）求解多旋翼动力学模型。往上一层是I/O与信号接口层，包括PWM、CAN、串口、I2C、模拟量等，用于连接真实飞控和实时机。再往上是模型层，包含多旋翼刚体动力学、电机与螺旋桨模型、传感器模型（IMU、气压计、GPS、磁罗盘）以及环境模型（风、温度、地磁）。最上层是自动化测试框架，负责用例管理、激励注入、结果采集和判定。

从图中可以看到，HIL测试不是单向的“发指令、看结果”，而是一个闭环。测试框架下发一个场景，比如“起飞后5秒注入北风6 m/s”，模型层解算出多旋翼在风中的姿态和位置变化，I/O层把这些状态转换成IMU、气压计、GPS等传感器信号送给真实飞控。飞控根据这些信号计算控制量，通过PWM或CAN输出给模型层中的电机模型，电机模型再影响动力学模型。整个闭环以实时步长运行，测试框架则在旁路记录飞控输出、模型状态和判定结果。

学习路线图可以按“先通链路、再写用例、后做自动化”来组织。第一阶段，先让HIL系统跑起来：确认实时机能以1 kHz稳定运行，确认飞控能正常解锁、起飞、悬停，确认传感器信号在示波器或总线分析仪上正确。第二阶段，学会构造测试用例：从最简单的定高悬停开始，逐步加入风扰、GPS丢失、电池电压下降等条件，并定义清晰的通过判据，比如“高度偏差不超过±0.5 m，姿态角速度不超过±20 °/s”。第三阶段，把用例自动化：用脚本批量执行、自动采集数据、自动判定并生成报告，接入持续集成流程。

这里给出一个最小可用的测试用例示例，帮助建立直观认识。假设我们要验证“定高模式下，注入持续北风6 m/s，飞控能否保持高度在±0.5 m以内”。用例可以写成如下结构：

用例编号：HIL-ALT-001
测试目标：定高模式抗风高度保持
初始条件：飞控已解锁，定高模式，目标高度 10 m
激励序列：
  t=0s    起飞至 10 m 并稳定 3 s
  t=3s    注入北风 6 m/s，持续 10 s
  t=13s   风停，继续观察 5 s
判定依据：
  全程高度偏差 |h - 10| ≤ 0.5 m
  姿态角速度 |ω| ≤ 20 °/s
  无解锁丢失、无模式意外切换
采样记录：飞控输出 PWM、模型高度、姿态角、风速

这个用例看起来简单，但它已经包含了HIL自动化测试的完整要素：初始条件、激励序列、判定依据和记录项。实际工程中，这样的用例会有几百条，覆盖正常飞行、边界条件和故障场景。自动化框架的价值就在于，让这些用例可以无人值守地批量执行，并在每次固件更新后快速回归。

还需要注意，HIL测试并不能完全替代真实飞行。它擅长验证逻辑、时序、接口和可复现的故障场景，但无法完全模拟真实的气动非线性、振动、电磁干扰和传感器安装误差。因此，HIL测试的定位是“把大量问题在地面暴露出来”，让真实飞行只用于验证那些必须上天的部分。理解这一点，才能合理设计测试覆盖率和放行标准。

本章后续内容将围绕这条主线展开：先建立HIL系统的整体认知，再逐步深入到实时仿真、接口配置、用例设计、自动化框架和结果分析。你不需要一开始就掌握所有细节，但需要先看清这张全景图——知道每个部分在闭环中的位置，知道一个测试用例从下发到判定经历了什么，知道哪些环节最容易出问题。有了这个框架，后面的具体技术点才能各归其位。