4. 硬件在环测试（HIL）：HIL平台架构、实时仿真机与IO板卡配置、传感器仿真与故障注入、HIL测试执行
硬件在环测试，圈里人常叫它HIL。说白了，就是把真实的飞控硬件，接到一个能模拟飞行环境的仿真系统里。你想想看，真机试飞前，你敢不敢让飞控直接上天？不敢吧。HIL就是那个让你在地面上就能把飞控折腾到极限的测试手段。
我个人习惯把HIL比作「飞行模拟器」。只不过，飞行员坐的是驾驶舱，我们坐的是调试台。飞控板子以为自己在天上飞，其实它连个螺旋桨都没接。嗯，这里要强调一点：HIL测试做得好不好，直接决定了你试飞时的心态。我在项目中遇到过太多次，HIL没跑透，上了天就炸机的情况。
4.1 HIL平台架构
一个标准的HIL平台，通常由四大部分组成：
- 实时仿真机：负责跑飞行动力学模型、传感器模型、环境模型。它必须保证硬实时，说白了就是每个控制周期必须准时，不能有抖动。
- IO板卡：负责把仿真机里的数字信号，转成飞控能识别的物理信号（PWM、CAN、串口、模拟电压等）。
- 飞控硬件：就是你要测试的那块板子，它完全不知道自己接的是仿真机。
- 上位机：用来配置测试场景、监控数据、记录日志。
我画了一张架构图，帮你理清它们之间的关系：
这张图你看懂了吗？数据流是从上往下的。上位机下发场景指令，实时仿真机算出传感器数据，IO板卡转成电信号，飞控收到后做出控制决策，再通过IO板卡把PWM信号送回仿真机，形成一个闭环。
核心要点：HIL测试的关键在于「实时性」和「保真度」。实时性不够，飞控算出来的控制量就是错的。保真度不够，你测出来的结果跟真机飞行对不上号。
4.2 实时仿真机与IO板卡配置
实时仿真机这块，市面上主流的有NI PXI、dSPACE、Speedgoat。我个人用得最多的是Speedgoat，原因很简单——它跟MATLAB/Simulink的兼容性最好。你想想看，模型在Simulink里搭好，一键部署到目标机，省了多少事。
配置实时仿真机时，有几个坑你得注意：
- CPU亲和性设置：把仿真任务绑定到特定核心上，别让操作系统乱调度。我曾经遇到过，仿真任务被切到另一个核心上，导致一个控制周期延迟了2ms，飞控直接报错。
- 中断优先级：IO板卡的中断优先级必须高于其他非关键任务。否则，数据采集会丢包。
- 同步时钟：如果有多块板卡，必须用同一个时钟源。我见过有人用两块板卡各自的内置时钟，结果时间戳对不上，数据分析时一头雾水。
IO板卡配置方面，我建议你按这个表格来规划：
| 信号类型 | 常用板卡 | 配置要点 | 常见问题 |
|---|---|---|---|
| PWM输出 | NI 9401 | 频率50Hz，脉宽1000-2000us | 电平不匹配（3.3V vs 5V） |
| CAN总线 | NI 9862 | 波特率1Mbps，终端电阻120Ω | 丢帧、总线冲突 |
| 模拟量输入 | NI 9205 | 量程±10V，采样率≥1kHz | 噪声干扰、共模电压过高 |
| 串口（UART） | NI 9870 | 波特率115200，8N1 | 缓冲区溢出、流控未配置 |
小技巧：配置IO板卡时，先用示波器或逻辑分析仪抓一下实际波形。别信板卡自带的诊断工具，我吃过这个亏——诊断工具说信号正常，结果示波器一看，PWM的占空比抖动超过5%。
4.3 传感器仿真与故障注入
传感器仿真，是HIL测试里最考验功力的部分。你得让飞控「以为」自己真的在飞。常见的传感器仿真包括：
- IMU（惯性测量单元）：模拟加速度计和陀螺仪的输出。注意要加入噪声和偏置，别给飞控喂「完美数据」。真实传感器哪有那么干净？
- GPS：模拟经纬度、高度、速度、星数。要能模拟丢星、多径效应、跳变。
- 气压计：模拟高度变化对应的气压值。注意温度补偿，不然飞控的高度估计会漂。
- 磁力计：模拟地磁场向量。要能模拟磁干扰，比如飞控附近有大电流导线。
故障注入，才是HIL测试的真正价值所在。你想想看，真机试飞时你敢不敢故意让GPS丢星？不敢吧。但在HIL上，你可以随便搞。
我常用的故障注入场景有这些：
- 传感器硬故障：直接切断某个传感器的信号。比如，让GPS突然输出全零。
- 传感器软故障：给传感器数据叠加一个缓慢漂移的偏置。模拟传感器老化。
- 通信中断：让CAN总线或串口突然断连，看飞控能不能切到安全模式。
- 电源波动：模拟电池电压骤降，看飞控的稳压电路能不能扛住。
- 执行器卡死：模拟某个舵机或电机卡在某个位置不动。
警告：故障注入测试一定要有「退出条件」。我曾经有一次忘了设置故障恢复逻辑，结果飞控一直处于故障状态，整个测试序列全乱了。建议在测试脚本里写清楚：故障注入持续多久？触发什么条件后恢复？
4.4 HIL测试执行
好了，平台搭好了，配置也搞定了，接下来就是跑测试。我一般把HIL测试执行分成三个阶段：
阶段一：冒烟测试
说白了就是先看看系统能不能跑起来。给飞控上电，检查通信是否正常，传感器数据是否在合理范围内。这个阶段不要搞复杂场景，就悬停或者平飞。我习惯先跑一个30秒的悬停，看看飞控的油门输出是否稳定。
阶段二：功能测试
验证飞控的各项功能是否正常。包括：
- 起飞、降落、悬停
- 航线飞行（直线、转弯、爬升、下降）
- 模式切换（手动、增稳、自动）
- 紧急情况处理（遥控器信号丢失、低电量返航）
阶段三：极限测试
这才是HIL测试的重头戏。把飞控往死里整：
- 大风环境（风速从5m/s到20m/s逐步增加）
- 传感器故障（GPS丢星、IMU饱和）
- 执行器故障（单个电机停转、舵面卡死）
- 极端姿态（大角度俯冲、翻滚）
执行测试时，我建议你写一个自动化测试脚本。别手动跑，人容易疲劳，一疲劳就会漏掉关键步骤。下面是一个简单的Python测试脚本框架：
import hil_api
# 初始化HIL平台
hil = hil_api.HILPlatform('config.yaml')
hil.connect()
# 加载测试场景
hil.load_scenario('wind_gust_15ms.yaml')
# 开始测试
hil.start_logging('test_001.log')
hil.arm_vehicle()
hil.takeoff(altitude=50)
# 注入故障：5秒后GPS丢星
hil.schedule_fault('gps_loss', delay=5.0, duration=10.0)
# 监控飞控状态
while hil.is_running():
status = hil.get_vehicle_status()
if status.mode == 'LAND':
print('飞控已切到降落模式，测试通过')
break
time.sleep(0.1)
# 清理
hil.disarm()
hil.stop_logging()
hil.disconnect()
我的经验：测试脚本里一定要加断言。比如「GPS丢星后5秒内，飞控必须切换到降落模式」。不加断言，你跑完测试还得手动翻日志，累死人。
最后，测试执行完了，别忘了做一件事——回放数据。把HIL记录的日志，跟仿真模型里的理想值做对比。看看飞控的实际响应跟预期差多少。如果偏差太大，要么是模型有问题，要么是飞控算法有bug。
嗯，HIL测试这块内容不少，但核心就一句话：在地面上把飞控折腾到极限，别把问题带上天。你想想看，一次HIL测试的成本，可能只是真机试飞的百分之一。但能发现的问题，一点都不少。