2、故障诊断总览：常见故障分类、诊断流程框架、诊断系统设计要求
各位同学，欢迎来到故障诊断的总览章节。
做FOC控制这些年，我最大的感触就是：算法写得再漂亮，扛不住一次硬件炸机。电机控制这东西，说白了就是跟能量打交道。能量一旦失控，轻则丢步、重则烧板子。我个人习惯，在项目初期就把故障诊断框架搭好，而不是等出了问题再临时抱佛脚。
这一章，咱们把故障诊断的全局地图先铺开。你想想看，如果连敌人长什么样、从哪里来都不知道，那防御体系根本无从谈起。
2.1 常见故障分类：把敌人分清楚
我在项目中遇到过各种各样的故障。总结下来，FOC系统的故障可以分成三大类。嗯，这里要注意，分类的目的是为了快速定位，而不是为了分类而分类。
2.1.1 电气类故障
这类故障最直接，也最危险。说白了就是电流、电压不在正常范围内。
- 过流故障：相电流超过MOS管或电机额定值。我曾经遇到过因为PID参数整定太激进，启动瞬间电流直接冲到80A，把采样电阻炸飞了。
- 过压/欠压故障：母线电压超出安全窗口。比如电池供电的无人机，电压掉到临界值以下，电机力矩瞬间不足，直接坠机。
- 缺相故障：三相中有一相断开。电机表现为剧烈抖动、噪音大、力矩输出严重下降。
- 对地短路/相间短路：这是最严重的故障，通常伴随冒烟和火光。
2.1.2 机械类故障
这类故障往往被忽视，但后果同样严重。
- 堵转故障：转子被卡住，无法转动。电流会瞬间飙升，如果不及时保护，几秒钟内就会烧毁线圈。
- 失步故障：转子转速跟不上磁场旋转速度。这在开环启动阶段尤其常见。
- 轴承磨损/负载突变：表现为电流波形异常、速度波动大。
2.1.3 通信与逻辑类故障
这类故障最隐蔽，排查起来最头疼。
- 传感器故障：霍尔传感器信号丢失、编码器ABZ脉冲异常、电流采样ADC通道漂移。
- 通信中断：CAN总线断线、SPI通信CRC校验失败、PWM信号丢失。
- 软件逻辑异常：看门狗超时复位、堆栈溢出、状态机进入非法状态。
核心观点：故障分类不是死的。同一个现象，可能是多种原因叠加的结果。比如电机抖动，既可能是缺相（电气），也可能是编码器安装松动（机械），还可能是SPI通信受到干扰（通信）。
2.2 诊断流程框架：从现象到根因
有了故障分类，接下来就是怎么诊断。我个人习惯用“三步走”的框架。这个框架我用了很多年，基本覆盖了90%的场景。
第一步：故障检测（Detection）
这是最底层的工作。通过硬件比较器或软件阈值判断，快速识别异常状态。
- 硬件检测：利用比较器、过流检测引脚、欠压锁定电路。响应时间通常在微秒级。
- 软件检测：在FOC控制循环中，每个PWM周期（比如10kHz）检查一次电流、电压、速度值是否越界。
我的经验：硬件检测和软件检测要配合使用。硬件检测负责“保命”，软件检测负责“诊断”。比如过流，硬件比较器在1微秒内关断PWM，软件则在后续周期中记录故障码、判断故障类型。
第二步：故障识别（Identification）
检测到异常后，需要识别具体是哪种故障。这一步需要结合多个信号进行综合判断。
- 单一信号判断：比如母线电压低于阈值，直接判定为欠压。
- 多信号融合判断：比如电流异常 + 速度异常 + 编码器信号异常，综合判断为传感器故障。
举个例子。我曾经遇到一个案例：电机运行中突然停机，报过流故障。但检查电流采样值，并没有真正过流。后来发现是编码器Z脉冲丢失，导致速度环计算错误，输出了一个巨大的电流指令。你看，表面是过流，根因是传感器故障。
第三步：故障处理（Action）
识别出故障后，系统必须做出响应。处理策略分为三个等级：
| 等级 | 处理方式 | 适用场景 |
|---|---|---|
| 一级（警告） | 记录故障码，继续运行 | 轻微过温、通信偶发错误 |
| 二级（降额） | 降低功率或转速，限制运行 | 持续过温、母线电压偏低 |
| 三级（停机） | 立即关断PWM，切断动力 | 过流、短路、堵转 |
警告：千万不要把所有故障都处理成“停机”。有些场景下（比如无人机），直接停机等于坠毁。合理的做法是：能降额就降额，能恢复就恢复，实在不行再停机。
2.3 诊断系统设计要求：好的设计是防患于未然
诊断系统不是事后诸葛亮，而是事前预防。我总结了几条设计原则，供你参考。
2.3.1 实时性要求
故障检测必须在故障造成损坏之前完成。对于FOC系统，这个时间窗口通常只有几十到几百微秒。
- 硬件检测：响应时间 < 1μs
- 软件检测：响应时间 < 100μs（一个PWM周期内完成）
- 故障处理：响应时间 < 10μs（关断PWM）
2.3.2 可靠性要求
诊断系统本身不能成为新的故障源。说白了，不能因为诊断逻辑的bug导致系统误动作。
- 去抖处理：对检测信号进行软件滤波，避免噪声导致误报。
- 冗余设计：关键信号（如过流）同时使用硬件和软件两路检测。
- 自检机制：系统上电时，对诊断电路进行自检，确保其工作正常。
2.3.3 可扩展性要求
诊断系统要方便后续增加新的故障类型。我建议采用模块化设计。
/* 故障诊断模块接口示例 */
typedef struct {
uint32_t fault_code; // 故障码
uint8_t fault_level; // 故障等级
uint32_t timestamp; // 故障发生时间
float fault_value; // 故障时的采样值
} FaultRecord_t;
// 注册一个新的故障检测函数
void Fault_RegisterDetector(FaultDetector_t *detector);
// 主循环中统一调用
void Fault_RunDiagnosis(void) {
for (int i = 0; i < g_detector_count; i++) {
if (g_detectors[i]->check() == FAULT_DETECTED) {
Fault_Handle(g_detectors[i]->fault_code);
}
}
}你看，这样设计后，新增一种故障类型，只需要写一个检测函数，然后注册进去就行。主循环不用改，维护起来非常方便。
2.3.4 可追溯性要求
故障发生后，要能查清楚“什么时候、什么原因、什么状态”。
- 故障日志：记录最近N次故障的详细信息，包括时间戳、故障码、关键变量值。
- 黑匣子功能：故障发生前一段时间（比如100ms）的波形数据保存下来，方便事后分析。
避坑指南：我曾经设计过一个诊断系统，故障日志只记录了故障码。结果现场报了一个“过流故障”，但查日志发现电流值完全正常。后来花了三天时间排查，才发现是ADC采样芯片的参考电压漂移了。从那以后，我要求故障日志必须同时记录故障发生时的原始采样值。
2.4 小结
这一章咱们把故障诊断的全局框架搭好了。你记住三个核心点：
- 分类要清晰：电气、机械、通信，三类故障各有特点。
- 流程要闭环：检测 → 识别 → 处理，三步缺一不可。
- 设计要系统：实时性、可靠性、可扩展性、可追溯性，四个要求都要满足。
下一章，咱们会深入具体的故障检测技术，比如过流检测的硬件电路设计、软件阈值如何设置。到时候我会拿出几个实际项目的案例，跟你聊聊那些年我踩过的坑。
好，这一章就到这里。有问题随时交流。