第2章飞控系统架构安全

2. 飞控系统架构安全：冗余设计

各位工程师，咱们今天聊点硬核的。飞控系统的冗余设计，说白了就是给飞机装“备份大脑”。我做了这么多年飞控安全，见过太多因为单点故障导致的事故。你想想看，几万英尺高空，一个传感器坏了就失控？这绝对不行。

冗余设计不是简单堆硬件。它是一门平衡艺术——既要保证安全，又不能把飞机变成“铁疙瘩”。我个人习惯把冗余分为三个层次：传感器冗余、计算通道冗余、执行机构冗余。今天咱们重点讲前两个。

2.1 三余度 vs 双余度：选型背后的逻辑

先问个问题：为什么有的飞机用三余度，有的用双余度？

我遇到过不少年轻工程师，上来就说“三余度肯定比双余度好”。其实不然。三余度能容忍一次故障，双余度只能检测故障但不能容忍。但代价呢？成本、重量、功耗都上去了。

三余度架构（Triple Modular Redundancy, TMR）是高端货。三个通道同时运行，通过多数表决输出。我参与过一个大型无人机项目，飞控系统就是三余度。当时有个场景让我印象深刻：一个ADC通道突然漂移，输出值偏了5%。表决机制直接把它踢出去了，飞机稳如泰山。

双余度架构（Dual Modular Redundancy, DMR）更常见。两个通道互为备份，但遇到分歧时谁对谁错？这就需要额外的健康监测逻辑。我建议在成本敏感或空间受限的场景下考虑双余度，比如小型电动垂直起降飞行器（eVTOL）。

核心区别总结：

三余度：容忍1次故障，输出可靠，但成本高
双余度：检测1次故障，需外部仲裁，成本适中

2.2 表决机制：多数说了算，但怎么算？

表决机制是冗余系统的“裁判”。三余度系统里，最常用的是多数表决（Majority Voting）。三个输入，取两个相同的作为输出。听起来简单，但坑不少。

我曾经遇到过一个案例：三个IMU（惯性测量单元）数据，两个正常，一个故障。但故障的那个输出值恰好和正常值非常接近，只是噪声大了点。多数表决通过了，但噪声被带进了控制环路。结果飞机开始轻微抖动。

所以，我建议在表决前加一道合理性检查。比如：

范围检查：值是否在物理极限内？
变化率检查：变化速度是否合理？
一致性检查：与历史数据是否吻合？

表决算法也不复杂。下面是一个简化版的三余度表决代码，我习惯用中值滤波的思路：

// 三余度表决函数
float vote_triplex(float val1, float val2, float val3) {
    float values[3] = {val1, val2, val3};
    
    // 先做合理性检查
    for (int i = 0; i < 3; i++) {
        if (!is_within_range(values[i])) {
            values[i] = NAN;  // 标记为无效
        }
    }
    
    // 统计有效值
    int valid_count = 0;
    float valid_values[3];
    for (int i = 0; i < 3; i++) {
        if (!isnan(values[i])) {
            valid_values[valid_count++] = values[i];
        }
    }
    
    // 表决逻辑
    if (valid_count >= 2) {
        // 取中值作为输出（比均值更鲁棒）
        return median(valid_values, valid_count);
    } else {
        // 故障太多，触发安全模式
        trigger_failsafe();
        return 0.0f;
    }
}

我的经验：表决输出不要直接用均值。中值滤波能有效抑制单点异常。我在一个项目中用均值，结果一个传感器尖峰脉冲直接拉偏了输出。换成中值后，问题解决。

2.3 故障隔离：别让坏蛋传染好蛋

冗余设计最怕什么？怕故障传播。一个通道坏了，把其他通道也拖下水。这就是共因故障（Common Cause Failure）。

我见过最典型的例子：三个飞控计算机共用同一个电源模块。电源纹波一大，三个通道同时重启。嗯，这冗余等于白做。

故障隔离的核心原则是物理隔离和电气隔离。具体做法：

独立电源：每个通道有自己的电源轨
独立时钟：避免时钟同步故障
独立通信总线：通道间通过隔离的交叉链路通信
看门狗定时器：每个通道独立监控

我曾经在一个项目中，坚持要求三个IMU安装在飞机不同位置。结构工程师觉得我多事，说“装一起多方便”。结果后来一次振动测试，一个IMU安装座松了，数据异常。但因为物理隔离，另外两个完全不受影响。那次之后，没人再质疑我的隔离要求了。

注意：故障隔离不只是硬件的事。软件层面也要做隔离——独立的堆栈空间、独立的任务调度、独立的错误处理。我曾经见过一个软件bug导致三个通道同时进入死循环，就是因为共享了同一个中断向量表。

2.4 架构层级的安全分解

冗余设计不是拍脑袋决定的。它需要从系统级到组件级逐层分解。我习惯用安全架构分解树来做这件事。

下面这张图是我自己总结的飞控安全架构分解逻辑，你一看就明白：

从这张图你能看到，安全分解是从上到下的。系统级定目标，架构级定策略，子系统级定方案，组件级定实现。每一层都要回答一个问题：如果这一层出故障，上一层怎么兜底？

我举个例子。传感器子系统的IMU组件用了三余度+表决。但如果三个IMU都因为同一个原因（比如温度过高）同时失效呢？这就是共因故障。所以架构级要加一个多样性设计——比如一个IMU用MEMS技术，另一个用光纤陀螺技术。这样即使一种技术全部失效，另一种还能工作。

安全分解的关键输出：

每个层级的安全需求文档
故障模式与影响分析（FMEA）表
故障树分析（FTA）图
冗余策略选择矩阵

2.5 避坑指南：我踩过的那些雷

最后，分享几个我亲身经历的教训。这些坑，我希望你别再踩。

坑一：表决逻辑的“活锁”问题。 我曾经设计过一个三余度系统，表决逻辑里有个状态机。结果一个通道反复故障-恢复-故障-恢复，导致表决逻辑在两个状态间来回切换，输出剧烈抖动。后来我加了去抖计时器——一个通道被标记为故障后，必须连续正常运行N个周期才能恢复。

坑二：故障隔离的“木桶效应”。 三个通道各自独立，但共享了一个复位信号。结果一个通道触发复位，把其他两个也带复位了。嗯，这就是典型的隔离不彻底。从那以后，我要求每个通道的复位电路完全独立，包括复位芯片和RC电路。

坑三：表决机制的“沉默故障”。 双余度系统里，两个通道都输出同样的错误值。表决通过了，但结果是错的。这种情况怎么防？我建议加第三参考源——不一定需要完整的三余度，但至少有一个独立的监测通道，比如一个低精度的备用传感器，用来做交叉校验。

我的建议：冗余设计不是越多越好。每增加一个冗余通道，系统的复杂度、成本、重量都会增加。关键是找到那个“刚刚好”的点。我一般用安全完整性等级（SIL）来指导决策。SIL 3以上的系统，我才会考虑三余度。

好了，关于飞控系统架构安全的冗余设计，今天就聊到这儿。记住一句话：冗余不是目的，安全才是。设计时多问自己一句“如果这里坏了，系统还能安全吗？”——这比任何公式都管用。

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

📚 课程目录

2. 飞控系统架构安全：冗余设计

2.1 三余度 vs 双余度：选型背后的逻辑

2.2 表决机制：多数说了算，但怎么算？

2.3 故障隔离：别让坏蛋传染好蛋

2.4 架构层级的安全分解

2.5 避坑指南：我踩过的那些雷