📚 课程目录第1章课程导入

1. 课程导入

各位工程师朋友，欢迎来到这门实战课。我是老周，在嵌入式这行摸爬滚打了十几年。今天咱们先聊聊最基础、也最容易被忽视的问题——可靠性。

说实话，我刚入行那会儿，总觉得可靠性是“玄学”。代码能跑、功能正常，不就完了吗？直到有一次，我负责的一个工业控制器项目，在实验室测了三个月都没问题，结果发到客户现场，夏天高温一烤，批量死机。那滋味，真不好受。

从那以后，我养成了一个习惯：在设计阶段就把可靠性当硬指标来抓。这节课，咱们就把这块硬骨头啃下来。

说白了，可靠性就是：系统在规定的条件下、规定的时间内，完成规定功能的能力。

你想想看，一个智能门锁，在东北零下三十度的冬天，或者在海南四十度高温的夏天，能不能正常开锁？一个汽车ECU，在颠簸路面上连续跑十万公里，会不会突然死机？这些，都是可靠性要回答的问题。

我个人习惯把可靠性拆成三个维度来看：

核心观点：可靠性不是测出来的，是设计出来的。测试只是验证手段，不是补救措施。

FMEA，听起来高大上，其实就是一句话：提前想好“哪里会坏、坏了会怎样、怎么预防”。

我在项目中遇到过最典型的例子：一个温控器产品，MCU的ADC引脚在采样时偶尔会读到异常值。当时团队觉得是软件滤波没做好，改了好几版算法都没用。后来做FMEA才发现，问题出在PCB布局上——ADC走线紧挨着一根高频时钟线，电磁耦合导致的干扰。

FMEA的流程，我一般按这五步走：

失效模式	严重度(1-10)	发生频率(1-10)	可检测度(1-10)	RPN
电源上电时序异常	9	3	4	108
看门狗误复位	7	6	2	84
Flash数据位翻转	10	2	8	160
通信CRC校验漏检	8	4	5	160

我的经验：RPN超过100的，必须优先处理。别想着“概率低就没事”，嵌入式系统里，小概率事件一旦发生，往往就是灾难性的。

这两个指标，很多工程师容易搞混。我简单解释一下：

MTBF（Mean Time Between Failures）：平均故障间隔时间。适用于可修复系统。比如一个基站设备，坏了可以换板子，修好继续用。
MTTF（Mean Time To Failure）：平均失效前时间。适用于不可修复系统。比如一个一次性传感器，坏了就直接报废。

你想想看，一个消费级智能家居产品，MTBF做到多少算合格？我个人的经验是：至少10万小时，换算下来大概11年。工业级产品，通常要求30万小时以上。汽车级？那就更严了，很多车规芯片的MTBF目标在100万小时以上。

计算MTBF，最常用的方法是：

MTBF = 总运行时间 / 故障次数

举例：
100台设备，连续运行1000小时，期间发生2次故障
MTBF = (100 × 1000) / 2 = 50,000 小时

注意：MTBF是统计值，不是单个设备的寿命。别跟客户说“这个产品MTBF是5万小时，所以能用5年”——这是典型的误解。MTBF 5万小时，意味着100台设备连续运行500小时，平均会发生1次故障。

为了让大家有个整体认识，我画了一张图，把可靠性的核心要素串起来：

这些年我带过不少团队，发现大家在可靠性验证上，容易踩这几个坑：

误区一：功能测试通过 = 可靠性达标
我曾经见过一个团队，产品功能测试全过就敢发货。结果客户现场温度一高，LCD显示乱码。功能测试只验证“能不能用”，可靠性验证要回答“能用多久、多稳”。
误区二：MTBF越高越好
不是的。MTBF每提高一个数量级，成本可能翻几倍。消费级产品MTBF做到10万小时就够了，非要做到100万小时，成本上去了，市场不一定买单。
误区三：FMEA做一次就完事
我建议：每个设计迭代都要重新做FMEA。改了一版固件、换了一颗芯片、调了一处布局，都可能引入新的失效模式。

我曾经踩过的坑：一个项目为了赶工期，FMEA草草了事，只写了几个显而易见的失效模式。结果量产三个月后，批量出现看门狗误复位。查到最后，是固件里一个中断优先级配置问题——这在FMEA阶段完全被忽略了。从那以后，我要求团队：FMEA不过，不进入下一阶段。

这一章，咱们把可靠性的底子打好了：