第4章失速保护系统架构

第4章失速保护系统架构：系统组成与冗余设计

各位同学，今天我们来聊聊失速保护系统的骨架——系统架构。说实话，我在航电这行干了快二十年，见过太多因为架构设计不合理导致的“惨案”。失速保护这东西，说白了就是飞机的最后一道防线，架构要是出了问题，后果不堪设想。

4.1 系统组成：传感器、计算机、执行器

失速保护系统，我习惯把它拆成三个部分：感知、决策、执行。你想想看，这不就跟人一样吗？眼睛看到危险，大脑做出判断，手脚去执行动作。

4.1.1 传感器——飞机的“眼睛”

传感器负责采集飞机的飞行状态参数。我个人习惯把失速相关的传感器分为两类：

迎角传感器：这是最核心的。通常安装在机头两侧，直接测量气流与机翼弦线的夹角。我在项目中遇到过，某型飞机的迎角传感器安装位置偏了3度，结果试飞时失速告警提前了整整5节。
空速管/静压孔：提供空速、高度、升降速率。这些数据用来计算失速裕度。
加速度计：测量法向过载。失速时通常伴随着抖振，加速度计能捕捉到这种高频振动。
襟翼/缝翼位置传感器：构型不同，失速迎角也不同。这个不接入，系统就是“瞎子”。

我的经验：迎角传感器最怕结冰。我曾经在东北某机场做冬季试飞，起飞前忘了开加温，结果爬升到3000米时迎角信号直接冻结。嗯，从那以后我每次起飞前都会手动检查传感器加温状态。

4.1.2 计算机——飞机的“大脑”

计算机接收传感器数据，运行失速保护算法，输出指令。这里我重点讲两个部分：

算法逻辑：说白了就是判断“什么时候该触发保护”。常见的算法有：

迎角阈值法：迎角超过某个固定值（比如15度）就触发。简单粗暴，但不够智能。
迎角-马赫数查表法：根据马赫数动态调整阈值。高速时迎角阈值低，低速时阈值高。这是目前的主流做法。
能量状态法：计算飞机的总能量（动能+势能），判断是否接近失速边界。这个更先进，但计算量大。

输出指令：通常包括：

驾驶杆抖动器激活（警告飞行员）
自动推杆器介入（强制低头）
自动油门增加推力

  注意：计算机的响应时间必须小于50毫秒。我见过一个项目，因为CPU选型太保守，算法跑完要120毫秒，结果推杆器动作时飞机已经进入深度失速。这个教训很深刻。

4.1.3 执行器——飞机的“手脚”

执行器负责把计算机的指令变成物理动作。主要有：

驾驶杆抖动器：一个偏心电机，装在驾驶杆上。失速前开始抖动，告诉飞行员“兄弟，该推杆了”。频率通常是20-30Hz。
自动推杆器：一个伺服电机或液压作动筒，直接推动驾驶杆向前。力度要适中——太轻了推不动飞行员，太重了飞行员会跟你打架。
自动油门伺服：增加发动机推力，帮助飞机改出。

这里有个细节：自动推杆器的力必须大于飞行员的最大握力。我记得某型飞机设计时，推杆力定在150N，结果有个壮汉飞行员在模拟器上硬是跟它较劲，差点把驾驶杆掰断。后来改成了200N。

4.2 冗余设计：双通道与三余度

为什么要做冗余？说白了就是怕坏。飞机在天上，一个传感器坏了、一台计算机死机了，你不能让飞行员抓瞎。我参与的第一个项目就是做冗余设计，当时师傅跟我说了一句话，我记到现在：“冗余不是堆硬件，而是让系统在故障时还能优雅地工作。”

4.2.1 双通道架构

双通道，就是两套完全独立的系统。一套工作，一套热备份。结构如下：

传感器A → 计算机A → 执行器A
传感器B → 计算机B → 执行器B

两套系统同时运行，但只有一套在控制。如果主通道故障，备份通道立即接管。切换时间通常要求小于100毫秒。

我在项目中遇到过一个问题：双通道的传感器数据不一致怎么办？比如迎角传感器A显示12度，B显示14度。这时候计算机该信谁？

交叉比较：如果差值超过阈值（比如2度），判定为故障。
多数表决：双通道没法表决，只能靠自检测（BIT）来判断哪个坏了。
降级模式：如果两个通道都坏了，系统进入降级模式，只提供告警，不提供自动干预。

避坑指南：我曾经遇到过双通道共因故障——两个通道用了同一批次的传感器，结果结冰条件下两个同时失效。所以冗余设计不仅要考虑硬件独立，还要考虑物理隔离和多样性。

4.2.2 三余度架构

三余度，就是三套系统。这是目前大型客机的主流方案。结构如下：

传感器A → 计算机A → 执行器A
传感器B → 计算机B → 执行器B
传感器C → 计算机C → 执行器C

三余度的核心优势是多数表决。三个信号，取两个一致的作为正确值。如果有一个坏了，另外两个还能形成多数。就算坏了两个，剩下的一个还能继续工作。

我画了一张三余度失速保护系统的架构图，你感受一下：

三余度系统的表决逻辑，我习惯用伪代码来描述：

// 三余度表决算法
function vote(sensorA, sensorB, sensorC) {
    // 计算两两差值
    diff_AB = abs(sensorA - sensorB);
    diff_AC = abs(sensorA - sensorC);
    diff_BC = abs(sensorB - sensorC);
    
    // 阈值判断（比如2度）
    if (diff_AB < THRESHOLD && diff_AC < THRESHOLD) {
        // A和B、A和C都一致，取A
        return sensorA;
    } else if (diff_AB < THRESHOLD && diff_BC < THRESHOLD) {
        // B和A、B和C都一致，取B
        return sensorB;
    } else if (diff_AC < THRESHOLD && diff_BC < THRESHOLD) {
        // C和A、C和B都一致，取C
        return sensorC;
    } else {
        // 三个都不一致，进入故障模式
        return FAILURE_MODE;
    }
}

4.2.3 双通道 vs 三余度：怎么选？

我整理了一个对比表，方便你理解：

特性	双通道	三余度
成本	较低	较高（多一套硬件）
重量	较轻	较重（约增加30%）
故障容限	容忍1个故障	容忍2个故障
表决能力	无法表决（只能交叉比较）	可以多数表决
典型应用	中小型飞机、通航飞机	大型客机（B737、A320等）
维护复杂度	中等	较高

我个人建议：如果是做通航飞机或无人机，双通道够用了。但如果是做运输类飞机，老老实实上三余度。为什么？因为适航条款（比如FAR 25.1309）要求：任何单一故障不能导致系统功能丧失。双通道只能满足“单一故障”，三余度才能覆盖“两个故障同时发生”这种小概率事件。

  核心要点：冗余不是越多越好。三余度已经能覆盖99.99%的故障场景。四余度？那是航天飞机用的，咱们民航用不上。而且冗余多了，交叉耦合的复杂度会指数级上升，反而引入新的故障模式。

4.3 我的实战经验

最后分享一个我亲身经历的案例。某次试飞，飞机在8000米高度做失速测试。三余度系统突然报出“传感器不一致”故障。地面分析发现，三个迎角传感器中，A和B差了1.8度，B和C差了1.9度，A和C差了0.2度。

按照表决逻辑，系统应该取A和C的一致值。但问题是，B传感器其实才是对的——它因为安装位置稍微靠后，受机身扰动影响小，反而更准确。A和C因为靠前，受气流畸变影响，读数偏大了。

这个案例告诉我们：冗余设计不能只看硬件，还要看物理安装位置。后来我们修改了表决算法，加入了“传感器健康度”权重，不再简单取多数，而是根据自检测结果动态调整权重。

嗯，这就是失速保护系统架构的核心内容。记住：传感器要可靠，计算机要快，执行器要有力，冗余要聪明。缺一个，你的失速保护就是纸老虎。

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

📚 课程目录