第二章 飞控系统架构与测试层级
做飞控测试这么多年，我最大的体会是：不懂架构，就没法做测试。你想想看，连系统长什么样、各部分怎么配合都不知道，测试方案怎么可能靠谱？
这一章，咱们就聊聊飞控系统的硬件架构、软件架构，以及贯穿整个开发过程的V模型测试流程。嗯，内容有点多，但都是干货。
2.1 飞控系统硬件架构
飞控硬件，说白了就是三大块：传感器、飞控计算机、作动器。这三者构成了一个闭环——传感器感知外界，计算机做决策，作动器执行动作。
核心要点：硬件架构决定了系统的可靠性边界。我在项目中见过太多因为硬件选型不当导致的测试失败案例。
2.1.1 传感器子系统
传感器是飞控系统的「眼睛」和「耳朵」。eVTOL常用的传感器包括：
- IMU（惯性测量单元）：测量加速度和角速度，是姿态估计的核心
- GPS/GNSS：提供位置和速度信息，但容易受干扰
- 气压计：测量高度，精度受天气影响
- 磁力计：提供航向参考，但容易受电磁干扰
- 激光雷达/视觉传感器：用于避障和地形跟随
我个人习惯，在测试传感器时重点关注冗余配置。为什么？因为单点故障会直接导致坠机。我曾经遇到过一个项目，IMU只有单套配置，结果飞行中IMU失效，飞机直接失控。从那以后，我坚持至少三冗余设计。
避坑指南：我曾经在测试中发现，同一批次的两颗IMU，温度特性差异很大。所以传感器测试一定要做温度循环测试，别偷懒。
2.1.2 飞控计算机
飞控计算机是系统的大脑。它负责运行控制律、导航算法和健康管理逻辑。常见的架构有：
| 架构类型 | 特点 | 适用场景 |
|---|---|---|
| 单核单板 | 成本低，可靠性一般 | 小型无人机 |
| 双核冗余 | 主备切换，可靠性较高 | 中型eVTOL |
| 三模冗余（TMR） | 三取二表决，极高可靠性 | 载人eVTOL |
我建议在测试飞控计算机时，重点关注看门狗定时器和内存保护。这两个东西看似简单，但一旦出问题，后果很严重。我记得有一次测试，看门狗配置超时时间太短，导致正常飞行中频繁复位，差点把飞机摔了。
2.1.3 作动器子系统
作动器包括电机、舵机、螺旋桨等。它们负责把飞控计算机的指令转化为物理动作。
测试作动器时，我特别关注响应延迟和死区。你想想看，如果作动器响应慢了50毫秒，在高速飞行中可能就是几米的偏差。我曾经在项目中遇到过舵机死区过大，导致悬停时飞机一直晃，调了好几天才找到原因。
2.2 飞控系统软件架构
软件架构决定了飞控系统的功能和灵活性。eVTOL的飞控软件通常包含三大模块：控制律、导航、健康管理。
核心要点：软件架构的测试重点在于接口一致性和时序确定性。我见过太多因为模块间通信延迟导致的奇怪故障。
2.2.1 控制律模块
控制律是飞控的核心算法。它负责把期望姿态/位置转化为作动器指令。常见的控制律包括：
- PID控制：经典方法，简单可靠
- LQR/H∞控制：现代控制方法，性能更好
- 自适应控制：能应对参数变化，但验证难度大
我个人习惯，在测试控制律时先做模型在环（MIL）测试，再做软件在环（SIL）测试。为什么？因为MIL能快速验证算法逻辑，SIL能验证代码实现。我曾经跳过MIL直接做SIL，结果发现算法逻辑有bug，浪费了大量时间。
避坑指南：我曾经在测试PID控制律时，发现积分项饱和导致响应变慢。解决办法是加抗饱和逻辑，这个在测试中一定要覆盖到。
2.2.2 导航模块
导航模块负责融合传感器数据，估计飞行器的状态。常用的方法包括：
- 卡尔曼滤波：经典方法，适用于线性系统
- 扩展卡尔曼滤波（EKF）：适用于非线性系统
- 粒子滤波：适用于非高斯噪声
测试导航模块时，我重点关注传感器故障注入。你想想看，如果GPS突然失效，导航模块能不能平滑切换到其他传感器？我曾经在测试中注入GPS故障，结果导航模块直接发散，飞机姿态估计完全错误。嗯，这个问题后来通过增加故障检测逻辑解决了。
2.2.3 健康管理模块
健康管理模块负责监控系统状态，检测故障并采取应对措施。它通常包括：
- 故障检测：通过阈值或模型判断是否异常
- 故障隔离：定位故障源
- 故障恢复：切换到冗余通道或降级运行
我建议在测试健康管理模块时，重点关注误报率和漏报率。误报太多会导致不必要的降级，漏报则可能导致灾难。我记得有一次测试，健康管理模块把正常的传感器噪声误判为故障，导致飞机频繁切换通道，飞行品质很差。
2.3 V模型测试流程
V模型是飞控系统测试的经典流程。它把测试活动与开发活动对应起来，形成「左端开发、右端测试」的结构。
下面这张图展示了V模型的核心逻辑：
V模型的核心思想是：测试活动应该与开发活动并行开展。需求分析阶段就要开始写测试计划，系统设计阶段就要设计测试用例。这样做的好处是，能尽早发现需求或设计中的问题，避免后期返工。
2.3.1 单元测试
单元测试是最底层的测试，针对单个函数或模块。我建议用覆盖率工具来评估测试充分性。常见的覆盖率指标包括：
- 语句覆盖率：每行代码是否都执行过
- 分支覆盖率：每个条件分支是否都覆盖到
- MC/DC覆盖率：每个条件独立影响结果
我个人习惯，单元测试至少达到语句覆盖率100%，分支覆盖率90%以上。为什么？因为语句覆盖能保证代码没有死代码，分支覆盖能保证逻辑正确。我曾经在项目中遇到一个bug，分支覆盖率只有70%，结果漏掉了一个边界条件，导致飞行中姿态解算错误。
警告：不要迷信覆盖率数字。100%覆盖率不代表没有bug。我见过太多覆盖率很高但依然有严重bug的案例。覆盖率只是手段，不是目的。
2.3.2 集成测试
集成测试关注模块之间的接口和交互。常见的集成策略包括：
- 大爆炸集成：所有模块一次性集成，风险高
- 增量集成：逐步集成模块，风险可控
- 持续集成：每次代码提交都做集成测试
我建议在eVTOL项目中采用增量集成策略。你想想看，如果一次性集成所有模块，出了问题根本不知道是哪个模块导致的。我曾经在一个项目中采用大爆炸集成，结果花了整整一周才定位到一个通信接口的时序问题。
2.3.3 系统测试
系统测试验证整个飞控系统是否满足需求。测试内容包括：
- 功能测试：所有功能是否正常
- 性能测试：响应时间、精度等是否达标
- 可靠性测试：长时间运行是否稳定
- 安全性测试：故障注入后系统是否安全
我个人习惯，系统测试一定要做边界条件测试。比如，在最大风速下测试悬停精度，在最低电压下测试作动器响应。我记得有一次系统测试，在高温环境下飞控计算机频繁重启，后来发现是散热设计不足。嗯，这个问题在常温测试中根本发现不了。
2.3.4 验收测试
验收测试是交付前的最后一道关卡。它通常由客户或第三方机构执行，验证系统是否满足合同要求。
验收测试的要点包括：
- 需求追溯：每个需求都有对应的测试用例
- 测试环境：尽量模拟真实飞行环境
- 测试记录：所有测试结果都要存档
我建议在验收测试前，先做一次预验收测试。为什么？因为验收测试一旦失败，会影响项目进度和客户信任。我曾经在一个项目中，预验收测试发现了3个严重问题，及时修复后才顺利通过正式验收。
避坑指南：我曾经在验收测试中，发现测试环境与实际飞行环境差异很大。比如，实验室的GPS信号比实际飞行环境强很多，导致GPS故障测试不充分。所以验收测试一定要考虑环境差异。
2.4 本章小结
飞控系统架构与测试层级，说白了就是搞清楚「测什么」和「怎么测」。硬件架构决定了测试的物理边界，软件架构决定了测试的功能范围，V模型流程决定了测试的节奏和顺序。
我个人觉得，做飞控测试最重要的不是技术，而是系统思维。你想想看，一个飞控系统有成百上千个组件，任何一个组件出问题都可能导致灾难。只有从系统层面理解架构和流程，才能设计出有效的测试方案。
嗯，这一章的内容就到这里。记住：测试不是找bug，而是建立信心。当你对系统有了足够的信心，飞行安全才有保障。
公众号:蓝海资料掘金营，微信deep3321