一、冗余设计概述：为什么需要冗余？

各位工程师朋友，咱们今天聊聊飞控冗余设计。说实话，我刚入行那会儿，对冗余的理解特别肤浅——不就是多备几套东西嘛。直到有一次，我在一个无人机项目里亲眼看着飞机因为一个传感器故障直接栽下来，才真正明白：冗余不是锦上添花，是保命用的。

1.1 飞控系统的可靠性要求

飞控系统有多重要？你想想看，飞机在天上，一旦飞控出问题，后果是什么？我参与过几个军工级项目，他们对可靠性的要求是这样的：

应用场景	可靠性要求	失效概率
消费级无人机	MTBF ≥ 1000小时	10⁻³/飞行小时
工业级无人机	MTBF ≥ 5000小时	10⁻⁵/飞行小时
载人飞行器	MTBF ≥ 10⁵小时	10⁻⁹/飞行小时

说白了，消费级炸了也就赔个机器钱。但载人飞行器呢？那可是人命关天。我见过一个做eVTOL的团队，他们的可靠性目标是——每十亿飞行小时才允许出一次致命故障。这个数字，单靠一个飞控计算机根本不可能实现。

1.2 为什么单系统靠不住？

你可能会问：现在的芯片不是很可靠吗？嗯，这话对，也不对。芯片本身确实不容易坏，但整个系统呢？

• 传感器会漂移：陀螺仪用久了零偏会变，加速度计温度一高就飘。我在项目里遇到过，IMU用了200小时，数据直接偏了5度。
• 通信会中断：CAN总线被干扰、SPI线接触不良、PWM信号丢包。有一次调试，我发现舵机偶尔抽搐，查了两天才找到——是排线松动。
• 电源会波动：电机启动瞬间拉低电压，飞控直接复位。这个坑我踩过，飞机刚离地1米就掉下来了。
• 软件会跑飞：指针越界、堆栈溢出、死循环。嗯，写代码的都知道，bug这东西，你永远测不完。

所以，单系统再可靠，也扛不住这么多潜在风险。冗余设计，说白了就是给系统上「双保险」。

1.3 冗余设计的核心思想：N-1原则

冗余设计的灵魂是什么？我个人习惯用一句话概括：「任何单一故障，都不能导致系统失效」。这就是N-1原则。

什么叫N-1？N是你需要的资源数量，1是允许同时失效的数量。举个例子：

• 飞控需要1个IMU正常工作 → 你装2个IMU → N=2, 允许1个失效
• 飞控需要1个电源供电 → 你装2个独立电源 → N=2, 允许1个失效
• 飞控需要1条通信总线 → 你布2条独立总线 → N=2, 允许1条断掉

我参与过一个项目，客户要求「单点故障不影响飞行」。我们最后做了三余度飞控——3个IMU、3个CPU、3套电源。当时有个同事觉得太浪费，我说：「你想想看，飞机在天上，任何一个焊点虚焊都可能要命。三余度，至少能扛住两次故障。」

1.4 冗余设计的层次

冗余不是只在飞控计算机上堆硬件。我习惯把冗余分成几个层次：

1. 传感器冗余：多套IMU、GPS、空速计。数据要交叉校验，不能简单取平均。
2. 计算冗余：多核CPU、多块飞控板。投票机制决定最终输出。
3. 通信冗余：双CAN总线、冗余以太网。一条断了，另一条自动接管。
4. 执行冗余：双舵机、双电机。一个卡死，另一个还能控制。
5. 电源冗余：双电池、双BEC。一路短路，另一路继续供电。

我在做农业无人机项目时，就吃过「只做传感器冗余、不做电源冗余」的亏。那次是电池接头松了，飞控直接掉电，三套IMU全白搭。从那以后，我设计任何系统，第一件事就是画电源树——看看有没有单点故障。

1.5 冗余设计的代价

当然，冗余不是免费的。你得多花钱、多占空间、多耗电、多写代码。我见过一个团队，为了追求「极致可靠」，在无人机上装了4套飞控，结果飞机太重飞不起来。

所以，冗余设计要权衡：

• 成本：多一套传感器，BOM成本可能翻倍
• 重量：多一块飞控板，无人机载荷就少一分
• 复杂度：冗余管理逻辑，比单系统复杂10倍不止
• 故障模式：冗余本身也可能引入新故障（比如投票逻辑出错）

我个人的建议是：先做FMEA（故障模式与影响分析），找出真正的单点故障，然后针对性地做冗余。别一上来就「三余度走起」，那是土豪的做法。

1.6 本章知识体系

下面这张图，是我自己总结的冗余设计知识框架。你可以把它当成一个「思维导图」来看：

好了，这一章咱们把冗余设计的「为什么」讲清楚了。下一章，我会带你看看具体的冗余架构——怎么搭一个真正能用的双余度飞控系统。

---

公众号:蓝海资料掘金营，微信deep3321