3. 容错控制策略：被动容错控制、主动容错控制、混合容错控制
好，咱们进入这一章的核心内容。分布式电推进系统，说白了就是一堆电机和螺旋桨在飞机上协同工作。任何一个环节出问题，比如某个电机突然罢工，或者通信链路断了，整个推力分布就会乱套。这时候，容错控制策略就是我们的救命稻草。
我个人习惯把容错控制分成三大类：被动容错、主动容错、以及混合容错。这三者不是互斥的，更像是层层递进的关系。你想想看，一个成熟的工程方案，往往会把它们揉在一起用。
3.1 被动容错控制
被动容错，说白了就是「以不变应万变」。系统在设计阶段就考虑到了某些故障模式，通过鲁棒控制、冗余设计等手段，让系统在故障发生后依然能稳定运行，不需要在线调整控制器参数。
核心思想： 控制器是固定的，但系统本身有足够的「余量」来吸收故障冲击。
典型应用场景：
- 传感器轻微漂移或噪声增大
- 单个执行器效率下降（比如电机输出扭矩降低10%）
- 通信链路偶尔丢包
我在项目中遇到过这样的情况：某款六旋翼无人机，其中一个电机因为轴承磨损，输出功率下降了15%。由于我们采用了H∞鲁棒控制器，飞控系统几乎没有感知到异常，悬停精度依然保持在5cm以内。这就是被动容错的魅力——你不需要做任何事，系统自己扛过去了。
我的经验： 被动容错适合处理「小故障」和「慢变故障」。但如果是电机完全停转、螺旋桨断裂这种硬故障，被动容错往往扛不住。因为它的控制裕度是有限的。
3.2 主动容错控制
主动容错就完全不一样了。它需要系统实时监测自身状态，一旦发现故障，立刻调整控制策略。说白了，就是「见招拆招」。
核心流程：
- 故障检测与诊断（FDD）： 判断「有没有故障？在哪？多严重？」
- 控制器重构： 根据故障信息，重新计算控制律，切换或调整控制器参数
- 执行与验证： 新控制器上线，确认系统恢复稳定
我曾经在某个分布式电推进飞行器项目中，遇到过电机控制器CAN总线中断的故障。当时FDD模块在20ms内检测到通信超时，立刻触发了主动容错逻辑：
- 将故障电机的推力指令置零
- 重新分配剩余电机的推力权重
- 调整相邻电机的桨距角以补偿偏航力矩
整个过程不到100ms，飞机只是轻微晃动了一下，就恢复了正常飞行。嗯，这里要注意：主动容错的关键在于FDD的实时性和准确性。如果误报，反而会引入不必要的扰动。
避坑指南： 我曾经因为FDD阈值设置得太敏感，导致系统频繁切换控制器，反而引发了振荡。后来我把阈值放宽了20%，并加入了延时确认机制，才稳定下来。所以，主动容错不是越灵敏越好，要跟系统的动态特性匹配。
3.3 混合容错控制
混合容错，就是把被动和主动结合起来。为什么要这么做？因为现实中的故障是多种多样的，单一策略很难覆盖所有场景。
我的设计思路是这样的：
- 底层： 被动容错兜底。对于轻微故障、传感器噪声等，靠鲁棒控制硬扛。
- 上层： 主动容错应对硬故障。当FDD确认严重故障后，触发控制器重构。
- 中间层： 一个决策逻辑，判断「该被动扛还是主动切」。
举个例子，我在某型分布式电推进垂直起降飞行器上，就采用了这种混合架构。当某个电机效率下降到80%时，被动容错自动补偿；但当效率下降到50%以下，主动容错介入，直接切除该电机并重新分配推力。
你想想看，如果全程都用主动容错，系统会频繁切换，可靠性反而下降。如果全程都用被动容错，遇到硬故障又扛不住。混合策略才是工程上的最优解。
3.4 三种策略对比
| 特性 | 被动容错 | 主动容错 | 混合容错 |
|---|---|---|---|
| 控制器是否在线调整 | 否 | 是 | 部分情况调整 |
| 是否需要FDD模块 | 不需要 | 必须 | 需要 |
| 处理故障类型 | 轻微、慢变 | 严重、突变 | 全范围 |
| 实时性要求 | 低 | 高 | 中等 |
| 工程实现复杂度 | 低 | 高 | 最高 |
| 典型应用 | 传感器噪声抑制 | 电机完全失效 | 分布式电推进系统 |
3.5 知识体系框架图
下面这张图，是我自己梳理的三种容错策略在分布式电推进系统中的关系。你可以把它当作一个决策树来看。
从这张图可以看得很清楚：故障信号进来后，先经过一个「严重度判断」。轻微的走左边被动容错，严重的走右边主动容错。但最终，它们都会汇聚到混合容错决策逻辑里，由它来决定最终的输出策略。说白了，这就是一个「分级响应」的思路。
总结一下我的观点：
- 被动容错是「盾」，帮你挡住小风小浪
- 主动容错是「剑」，遇到大问题果断出击
- 混合容错是「盾剑合一」，该挡的挡，该砍的砍
在实际的分布式电推进系统中，我强烈建议采用混合容错架构。别想着用一种策略包打天下，那在工程上是不现实的。