1. 固定翼飞控HIL自动化测试全景

固定翼飞控的HIL（Hardware-in-the-Loop，硬件在环）测试，本质是把真实的飞控计算机放进一个由实时仿真机、传感器模拟通道、执行机构接口和地面站构成的闭环回路中，让飞控"以为"自己正装在一架真实飞机上飞行。要理解这门课程，先要看清三件事：测什么、边界在哪里、自动化能带来什么。

一、测试对象：从飞控计算机到整条信号链

HIL测试的直接对象是飞控计算机（Flight Control Computer，FCC），但真正被验证的是它周围的整条信号链。以一台典型的中小型固定翼无人机飞控为例，其HIL回路包含以下关键环节：

• 飞控计算机本体：运行姿态控制律、导航律、舵机混控与失效保护逻辑，通常以固定周期（如400 Hz或100 Hz）执行控制任务。
• 传感器输入通道：包括IMU（三轴陀螺、三轴加速度计）、磁力计、气压高度计、空速管、GPS接收机。HIL中这些信号由仿真机通过模拟量、串口、CAN或以太网注入。
• 执行机构输出通道：副翼、升降舵、方向舵、油门/电机指令，通常以PWM、CAN或RS-422输出，HIL中由仿真机采集并回灌到气动模型。
• 机载总线与遥控链路：CAN、UART、SBUS/PPM遥控输入，以及遥测下行数据。

需要特别强调的是：HIL测试不验证传感器本身的物理精度，也不验证舵机的机械行程，这些属于部件级测试。HIL验证的是飞控在"传感器数据正确、执行机构响应正确"的前提下，控制律、状态机、故障处置和模式切换是否正确。

二、系统边界：谁在环内，谁在环外

明确边界是HIL工程的第一课。环内是真实硬件（飞控计算机、线束、部分接口板卡），环外是数学模型（六自由度气动模型、大气模型、传感器误差模型、执行机构动力学模型）。仿真机负责在两者之间做实时信号转换。

边界划错会直接导致测试无效。例如，如果把舵机也接入环内，那么测试就变成了"飞控+舵机"的半实物测试，气动模型接收的是真实舵面偏角，此时若舵机存在死区或延迟，控制律的评估就会被机械特性污染。反之，如果只把飞控的算法代码跑在PC上，那就是纯软件仿真（SIL），失去了对真实CPU时序、总线延迟和接口电平的验证能力。

三、自动化价值：从"能测"到"测得完、测得准"

手工HIL测试的痛点非常具体。一次完整的固定翼试飞科目，比如"自动起飞—爬升—航线跟踪—返航—自动着陆"，在HIL台上手工操作需要约15～25分钟，其中大量时间花在等待飞机爬升、稳定和转弯上。如果要做100组不同风速、不同初始偏差的组合测试，手工方式几乎不可行。

自动化带来的核心价值有三点：

• 可重复性：同一组初始条件、同一段风场数据、同一套遥控指令序列，每次执行结果完全一致，排除了人为操作抖动。
• 批量覆盖：通过参数化脚本，可以在无人值守的夜间批量跑完数百个测试用例，覆盖风速0～15 m/s、初始姿态偏差±10°、GPS丢失时刻等组合。
• 可判读性：自动记录每个控制周期的输入输出、模式字、故障标志，测试结束后自动生成通过/失败判定和曲线报告，而不是靠人眼盯遥测。

但自动化不是"把手工操作录下来回放"那么简单。真正的自动化测试系统需要具备：测试用例的参数化描述、仿真机的实时控制接口、飞控状态的自动判读、异常时的安全中止逻辑，以及测试结果的数据管理。这四件事构成了本课程后续章节的主线。

四、课程任务地图

本课程围绕"搭台—建模—写用例—跑测试—判结果"的工程闭环展开，共30章，可划分为五个阶段：

需要提醒的是，HIL自动化测试的成熟度不是一蹴而就的。一个常见的合理路径是：先实现单用例的自动执行与自动判读，再扩展到多用例批量运行，最后才接入持续集成。跳过前两步直接追求"全自动"，往往会在模型不准、判据不清的情况下产出大量无效结果。