2. 故障诊断基础：传感器、执行器与通信链路故障检测
各位工程师朋友，咱们今天聊聊分布式电推进系统里最让人头疼，也最绕不开的一个话题——故障诊断。说白了，就是怎么在系统出问题的时候，第一时间知道“谁病了、病在哪、病得多重”。
我个人习惯把故障诊断比作“给飞机做体检”。你想想看，分布式电推进系统里几十个电机、上百个传感器、密密麻麻的通信线，任何一个环节出问题，轻则性能下降，重则直接炸机。我在项目中就遇到过，一个不起眼的温度传感器漂移，愣是让整个推力分配算法跑偏了，差点酿成大祸。
所以，这一节咱们就聚焦三个最基础的故障检测对象：传感器、执行器、通信链路。掌握了这三板斧，你基本就能应付80%的现场问题了。
2.1 传感器故障检测
传感器是系统的“眼睛”。眼睛花了，后面所有决策都是瞎的。常见的传感器故障有：硬故障（比如断线、短路，信号直接没了）和软故障（比如漂移、精度下降，信号还在但不准了）。
硬故障好办，一般用阈值检测就能搞定。比如转速传感器，正常范围是0~12000 RPM，你读到15000 RPM，那肯定有问题。
核心方法：基于解析冗余的残差生成
说白了，就是利用系统模型，算出一个“理论值”，然后跟“实测值”做差。这个差值就是残差。正常情况下残差接近0，故障时残差会显著偏离。
我建议你至少掌握以下三种传感器故障检测方法：
- 直接冗余法：同一个物理量装两个传感器，比如左右电机各装一个转速传感器。两者读数一对比，差异超过阈值就报警。简单粗暴，但成本高。
- 解析冗余法：利用系统动力学方程，用其他传感器的数据估算当前传感器的值。比如用电压和电流估算转速，再跟实测转速对比。我在项目中常用这个方法，省成本，但模型要准。
- 信号处理法：分析传感器信号的频谱、均值、方差等统计特征。比如振动传感器，正常时频谱很干净，轴承坏了就会出现特定频率的峰值。
避坑指南
我曾经在调试一个六旋翼无人机时，发现某个电机转速传感器总是间歇性报故障。查了半天，结果是传感器线束跟碳纤维机臂摩擦，偶尔短路。所以，别忘了检查物理连接！
2.2 执行器故障检测
执行器是系统的“手脚”。手脚不灵，飞机就失控。分布式电推进系统里，执行器主要是电机和螺旋桨。常见故障包括：卡死（电机不转）、效率下降（电机转但推力不够）、完全失效（彻底罢工）。
执行器故障检测的核心思路是：看指令和响应是否匹配。你给电机发了个2000 RPM的指令，结果实际转速只有1500 RPM，那肯定有问题。
具体方法我归纳为三类：
| 方法 | 原理 | 适用场景 | 我的经验 |
|---|---|---|---|
| 基于模型的方法 | 建立电机动态模型，对比模型输出和实际输出 | 效率下降、部分失效 | 模型参数要在线辨识，否则容易误报 |
| 基于信号的方法 | 分析电流、转速信号的波形特征 | 卡死、断相 | 电流谐波分析很有效，但计算量大 |
| 基于知识的方法 | 利用专家规则或历史数据训练分类器 | 复杂故障模式 | 数据要足够多，否则泛化能力差 |
注意
执行器故障检测最怕“误报”。你想想看，如果系统频繁误报电机故障，导致频繁切换控制策略，反而会引入不必要的扰动。所以，阈值设置要留有余量，最好加一个“确认时间”——连续N个采样点都超阈值，才判定为故障。
2.3 通信链路故障检测
分布式电推进系统里，各个节点之间靠通信总线（比如CAN、EtherCAT）交换数据。通信链路一旦出问题，整个系统就变成“聋子”和“哑巴”。
通信故障主要有三种：丢包（数据没到）、延迟（数据到了但晚了）、数据错误（数据到了但内容不对）。
检测方法其实很成熟，我直接给你列出来：
- 心跳检测：每个节点定期发送一个“我还活着”的信号。如果连续几个周期没收到，就判定该节点通信中断。这是最基础、最可靠的方法。
- 超时检测：发送方发出数据后，启动一个定时器。如果在规定时间内没收到接收方的确认，就认为通信失败。嗯，这里要注意，超时时间要设置合理，太短容易误报，太长反应太慢。
- 校验和/CRC：每个数据包末尾附加一个校验码。接收方收到后重新计算校验码，跟收到的对比。不一致就说明数据在传输过程中被篡改了。
- 序列号检测：每个数据包带一个递增的序列号。接收方检查序列号是否连续。如果发现跳号，说明有丢包；如果收到重复的序列号，说明有重传。
一个实用的通信健康度指标
我个人习惯用一个综合指标——通信质量因子（CQF），它综合了丢包率、平均延迟、最大延迟和误码率。公式很简单：
CQF = w1 * (1 - 丢包率) + w2 * (1 - 延迟/最大允许延迟) + w3 * (1 - 误码率)其中w1、w2、w3是权重，根据系统要求调整。CQF低于某个阈值就报警。这个指标在项目里帮了我大忙，能提前发现通信链路劣化的趋势。
2.4 知识体系总览
讲了这么多，我画了一张图帮你梳理一下。这张图展示了故障诊断的三大支柱，以及它们之间的逻辑关系。
这张图你看懂了吗？三大检测模块各自独立，但最终都汇聚到“故障诊断结果”这个输出上。实际工程中，这三个模块往往是并行运行的，互不干扰。
我的一个小建议
刚开始做故障诊断时，别想着一步到位。先实现最简单的阈值检测和心跳检测，跑通了再慢慢加高级算法。我在第一个分布式电推进项目里，就是先用这些“土办法”撑起了整个故障诊断系统，后来才逐步迭代升级的。
好了，这一节的内容就到这里。传感器、执行器、通信链路，这三个基础你吃透了，后面讲容错控制就好办了。记住，故障诊断不是目的，目的是为容错控制提供准确的“病情报告”。
公众号:蓝海资料掘金营，微信deep3321