4、非正常程序触发机制：系统故障（单/双/多故障）、传感器数据异常、执行器卡阻、通信丢失、软件逻辑错误
各位同事，今天我们聊一个核心问题——非正常程序到底是怎么被触发的？说白了，就是飞控系统在什么情况下会判定“我不行了，需要人工接管”。
我做了十几年飞控，见过太多因为触发机制理解不到位，导致接管时机延误的案例。你想想看，如果飞行员都不知道系统什么时候会“喊救命”，那人工接管就成了一句空话。
非正常程序的触发，不是单一原因。它是一整套逻辑判断的组合。我个人习惯把触发源分成五类：系统故障、传感器数据异常、执行器卡阻、通信丢失、软件逻辑错误。咱们一个一个说。
4.1 系统故障：单故障、双故障、多故障
系统故障是最常见的触发源。飞控系统通常采用余度设计——说白了就是备份。一个传感器坏了，另一个顶上。但余度也有极限。
单故障：一个通道或一个部件失效。比如一个空速管堵了。这时候系统通常还能正常工作，但会触发告警。我记得有一次在试飞中，左侧空速管被冰堵了，系统立刻切换到右侧数据，同时弹出“空速不一致”的警告。这就是单故障的典型处理。
双故障：两个独立通道同时失效。比如两个空速管都堵了。这时候系统就尴尬了——它不知道该信谁。我建议在双故障场景下，系统必须立即触发非正常程序，因为余度已经耗尽。
多故障：三个或以上通道失效。嗯，这种情况基本就是灾难性故障了。系统会直接进入“最低安全模式”，把所有能交的控制权全部交给飞行员。
核心原则：单故障告警，双故障触发，多故障强制接管。
4.2 传感器数据异常
传感器是飞控系统的眼睛。眼睛花了，系统就瞎了。传感器数据异常包括：
- 数据跳变：数值在极短时间内发生不合理变化。比如高度从1000米瞬间跳到10000米。我在项目中遇到过，一个大气数据计算机的加热器坏了，导致数据在结冰条件下疯狂跳变。
- 数据冻结：数值长时间不变。比如迎角传感器卡在5度不动了。这比跳变更危险，因为系统可能以为一切正常。
- 数据超限：数值超出物理范围。比如空速显示800节，但飞机根本飞不到那个速度。
- 数据不一致：多个同类型传感器读数差异过大。比如三个陀螺仪的角速率读数相差超过阈值。
为什么会这样？传感器本身会老化，线路会松动，环境会干扰。我曾经处理过一个案例，一个振动传感器因为安装支架共振，输出数据全是假的。系统差点因为这个误触发非正常程序。
我的经验：传感器数据异常检测，不要只看单一阈值。要结合变化率、一致性、物理模型三重校验。单一阈值太容易误报了。
4.3 执行器卡阻
执行器是飞控系统的手和脚。手卡住了，飞机就动不了。执行器卡阻分为：
- 机械卡阻：舵面被异物卡住，或者机械连杆断裂。我记得有一次，一个升降舵的铰链因为润滑不良，在低温下卡死了。
- 电气卡阻：伺服电机或作动筒的电气部分失效。比如电机烧毁、霍尔传感器故障。
- 液压卡阻：液压系统泄漏或压力不足，导致作动筒无法移动。
执行器卡阻的检测，通常靠位置反馈和指令的对比。如果指令要求舵面偏转10度，但反馈只有2度，而且持续一段时间，系统就会判定卡阻。
这里有个坑：卡阻和滞环很容易混淆。滞环是响应慢，但最终能到位。卡阻是根本不动。我曾经见过一个项目，因为滞环阈值设得太紧，把正常的滞环误判为卡阻，导致频繁触发非正常程序。
避坑指南：我曾经吃过这个亏。卡阻检测一定要加时间窗口和死区。不要因为一次指令-反馈偏差就触发，要连续多次确认。否则你会被误报烦死。
4.4 通信丢失
飞控系统内部有大量的通信总线——ARINC 429、CAN、AFDX、以太网等等。通信丢失意味着系统“失聪”了。
通信丢失的触发条件通常包括：
- 心跳信号丢失：每个节点定期发送“我还活着”的信号。如果连续几个周期没收到，就判定丢失。
- 数据帧校验失败：CRC校验、奇偶校验等。连续出错超过阈值。
- 总线静默：总线上完全没有数据活动。这通常是总线控制器挂了。
通信丢失的后果很严重。如果飞控计算机和舵机之间的通信断了，那舵机就收不到指令了。我建议在通信丢失后，系统要立即进入“保持最后指令”模式，同时触发非正常程序。
你想想看，如果通信丢失了，系统还在傻等数据，那飞机就失控了。所以通信丢失的检测必须快，而且要有冗余路径。
4.5 软件逻辑错误
这是最头疼的一种。硬件故障你能看到、摸到。软件逻辑错误，它藏在代码里，平时不发作，关键时刻给你来一下。
软件逻辑错误包括：
- 除零错误：某个计算中分母意外为零。比如在计算攻角时，动压为零导致除零。
- 数组越界：访问了不该访问的内存地址。这会导致系统崩溃或数据污染。
- 死循环：某个任务卡在循环里出不来。整个任务调度就停了。
- 状态机跑飞：状态机进入了未定义状态。比如从“巡航”直接跳到了“着陆”，中间跳过了“进近”。
- 资源竞争：多个任务同时访问同一个资源，导致数据不一致。
软件逻辑错误的检测，通常靠看门狗定时器、断言检查、健康监控任务。我建议在飞控软件中，每个关键计算模块都要加输入合法性检查。不要相信任何输入数据。
我的习惯：在飞控软件中，我要求所有除法操作前都要检查分母是否为零。所有数组访问都要加边界检查。所有状态机都要有默认的“错误处理”状态。这些看似简单，但能避免90%的软件逻辑错误。
4.6 触发机制的综合逻辑
实际系统中，这些触发源不是孤立的。它们会组合出现。比如传感器数据异常可能是由通信丢失引起的，执行器卡阻可能是由软件逻辑错误导致的。
我建议采用“投票机制”来判断是否触发非正常程序。比如三个传感器中，两个报异常，就触发。两个飞控计算机中，一个报故障，就触发。这种投票机制能有效降低误报率。
下面这张图展示了非正常程序触发机制的整体逻辑：
从图中可以看出，五大触发源各自独立检测，但最终都要经过投票机制的综合判断，才能决定是否触发非正常程序。这个投票机制是防止误触发的最后一道防线。
4.7 触发阈值的设计原则
触发阈值怎么设？设得太松，故障漏报。设得太紧，频繁误报。我建议遵循以下原则：
| 触发源 | 阈值设计原则 | 典型值 |
|---|---|---|
| 系统故障 | 余度耗尽即触发 | 双故障触发 |
| 传感器数据异常 | 连续N次超限才触发 | N=3~5 |
| 执行器卡阻 | 偏差持续T秒才触发 | T=0.5~2秒 |
| 通信丢失 | 连续丢失M个周期才触发 | M=3~5 |
| 软件逻辑错误 | 看门狗超时即触发 | 50~200ms |
这些值不是固定的。不同机型、不同飞行阶段，阈值可以动态调整。比如在起飞和着陆阶段，阈值应该更紧一些。在巡航阶段，可以适当放松。
我的建议：阈值设计要留有余量。不要卡着物理极限设。我曾经见过一个项目，把传感器超限阈值设在物理极限的99%，结果温度一变化就误报。留10%的余量，你会感谢自己的。
好了，关于非正常程序的触发机制，我们就聊到这里。记住一句话：触发机制是系统的“自我诊断”，它决定了什么时候该喊救命。喊早了是狼来了，喊晚了是来不及了。这个度，要靠经验和数据来把握。
公众号:蓝海资料掘金营，微信deep3321