一、故障模式分析：飞控系统常见故障类型与影响等级
大家好，我是老张。干飞控系统这行快十五年了，今天咱们聊聊故障模式分析。说实话，这活儿看着枯燥，但它是整个故障注入实验的根基。你想想看，连故障长什么样都不知道，怎么去注入？怎么去验证？
我个人习惯，做任何故障注入之前，先把故障模式梳理清楚。就像医生看病，得先知道有哪些病，才能对症下药。飞控系统的故障，我把它分成四大类：传感器故障、执行器故障、通信故障、计算故障。咱们一个一个说。
核心观点：故障模式分析不是纸上谈兵，它直接决定了你的故障注入实验有没有价值。我曾经见过一个团队，花了两周做故障注入，结果注入的全是系统根本不会出现的故障——白干了。
1.1 传感器故障
传感器是飞控系统的眼睛和耳朵。它坏了，飞控就是瞎子。我在项目中遇到过最典型的传感器故障，是IMU（惯性测量单元）的漂移问题。
常见的传感器故障类型包括：
- 硬故障（Hard Failure）：传感器完全失效，输出固定值或零值。比如陀螺仪突然输出0，或者加速度计卡死在某个数值上。
- 软故障（Soft Failure）：传感器还在工作，但精度下降。比如温度变化导致的零偏漂移，或者噪声异常增大。
- 间歇性故障（Intermittent Failure）：时好时坏，最让人头疼。我记得有一次，空速管在结冰条件下偶尔堵塞，数据一会儿正常一会儿异常，排查了整整三天。
- 偏差故障（Bias Failure）：输出值整体偏移一个固定量。比如气压计高度读数始终比真实值高5米。
- 比例因子故障（Scale Factor Failure）：输出值与真实值成比例关系变化。比如角速率陀螺的输出变成了真实值的1.2倍。
实战技巧：做传感器故障注入时，我建议优先关注软故障和间歇性故障。为什么？因为硬故障太容易被检测到了，大多数飞控都有完善的硬件监控机制。反而是那些"半死不活"的故障，最容易让飞控系统做出错误决策。
1.2 执行器故障
执行器是飞控系统的手和脚。传感器告诉飞控"该怎么做"，执行器负责"真的去做"。执行器出问题，飞控再聪明也没用。
常见的执行器故障类型：
- 卡死故障（Jam Failure）：舵面或电机卡在某个位置不动了。比如升降舵卡死在-5度位置。
- 松浮故障（Float Failure）：执行器失去控制，随风摆动。说白了就是舵面不受力了，像断了线的风筝。
- 饱和故障（Saturation Failure）：执行器只能到达某个极限位置，无法响应更大指令。比如舵机只能转到30度，但飞控要求转到45度。
- 效率下降（Efficiency Degradation）：执行器还能动，但响应变慢或力矩变小。比如电机老化后推力下降20%。
- 反向故障（Reversal Failure）：执行器动作方向与指令相反。这个最危险，我曾经在仿真中遇到过，飞控指令"抬头"，结果舵面反而让飞机低头——后果可想而知。
注意：执行器故障的注入要格外小心。尤其是卡死和反向故障，在真实硬件上做实验时，一定要有物理限位和紧急切断机制。我见过有人做舵机卡死注入，结果舵机过热烧了——教训深刻。
1.3 通信故障
通信是飞控系统的神经网络。传感器数据要传过来，控制指令要发出去，这些全靠通信链路。通信断了，系统就瘫痪了。
常见的通信故障类型：
- 数据丢失（Data Loss）：部分数据包在传输过程中丢失。比如CAN总线上的某个传感器节点突然不发了。
- 数据延迟（Data Latency）：数据到达时间超出预期。比如GPS数据本该20ms到一次，结果延迟到了100ms。
- 数据错误（Data Corruption）：数据内容被篡改。比如CRC校验失败，或者数据位翻转。
- 总线冲突（Bus Contention）：多个节点同时发送数据，导致总线拥堵。这在ARINC 429或CAN总线中比较常见。
- 链路中断（Link Loss）：物理连接断开。比如线缆被切断，或者无线链路失联。
你想想看，通信故障最麻烦的地方在哪？在于它有时候是"软"的。数据看起来正常，但时间戳不对；或者数据偶尔丢一帧，但飞控没检测到。嗯，这里要注意，双余度设计对通信故障的容错能力，很大程度上取决于故障检测的灵敏度。
1.4 计算故障
计算故障是飞控系统的"脑子"出问题了。传感器和执行器都好好的，但飞控计算机自己算错了，那也白搭。
常见的计算故障类型：
- CPU挂起（CPU Hang）：处理器陷入死循环或死锁，不再执行正常任务。
- 内存错误（Memory Error）：包括内存泄漏、位翻转、栈溢出等。我在项目中遇到过SRAM的SEU（单粒子翻转）问题，在高空辐射环境下，内存数据莫名其妙就变了。
- 时序错误（Timing Error）：任务执行超时，或者任务调度顺序错乱。比如控制律计算本该在1ms内完成，结果花了5ms。
- 逻辑错误（Logic Error）：软件算法本身有bug，导致计算结果错误。比如某个条件判断写反了，或者浮点数精度问题。
- 看门狗复位（Watchdog Reset）：系统频繁复位，导致飞控间歇性失效。
避坑指南：我曾经在DO-178C的测试中，发现一个计算故障特别隐蔽——浮点运算的精度问题。两个看起来相等的浮点数，因为精度差异，导致控制律切换条件永远不满足。从那以后，我养成了一个习惯：所有浮点数比较都加一个epsilon容差。
1.5 故障影响等级划分
故障不能一概而论。有些故障只是"小感冒"，有些故障直接"要命"。我们需要给故障分个等级，这样才能决定：哪些故障需要立即处理，哪些可以容忍，哪些必须通过余度设计来覆盖。
我一般把故障影响分为四个等级：
| 等级 | 名称 | 影响描述 | 典型示例 | 容错策略 |
|---|---|---|---|---|
| I级 | 灾难性 | 导致飞机失控、坠毁 | 所有余度同时失效、CPU完全挂死 | 必须通过物理隔离和独立余度避免 |
| II级 | 严重 | 导致任务失败或安全裕度大幅降低 | 单余度传感器失效、执行器卡死 | 通过余度切换或降级模式处理 |
| III级 | 轻微 | 导致性能下降，但不影响安全 | 传感器精度下降、通信延迟增大 | 通过软件补偿或自适应控制处理 |
| IV级 | 无影响 | 系统可完全容忍，无感知 | 单次数据丢帧、内存单比特错误（ECC纠正） | 无需处理，或由底层机制自动修复 |
说实话，这个等级划分不是死的。不同项目、不同安全等级要求，划分标准会有差异。但核心逻辑是一样的：故障的影响越严重，容错设计就要越强。
我的经验：做故障影响分析时，别只看单个故障。要关注"组合故障"——两个看似轻微的故障同时发生，可能变成灾难性的。比如传感器A精度下降（III级）+ 通信链路延迟（III级），两个III级叠加，可能让飞控的估计值完全偏离真实状态，变成II级甚至I级故障。
1.6 知识体系总览
下面这张图，是我梳理的本章知识体系。它把四大故障类型和影响等级串在了一起，方便你理解整体逻辑。
这张图把四大故障类型和四个影响等级串在了一起。你可以看到，每种故障类型下面都有具体的子类型，而所有故障最终都要落到影响等级上。说白了，故障模式分析的最终目的，就是回答两个问题："会出什么故障？" 和 "出了故障会怎样？"
个人建议：刚开始做故障模式分析时，别贪多。先把最常见的故障列出来，比如传感器硬故障、执行器卡死、通信丢包、CPU挂起。把这些搞透了，再慢慢扩展。我当年带新人时，就让他们先做这四种，做完再谈别的。
公众号:蓝海资料掘金营，微信deep3321