第1章可靠性设计概述

1. 可靠性设计概述：工业控制系统的可靠性定义、失效模式与影响分析（FMEA）、可靠性指标（MTBF、MTTR、可用性）

各位工程师朋友，咱们今天聊聊可靠性。说实话，我刚入行那会儿，觉得“可靠性”就是个玄学——不就是让设备别坏吗？后来在产线上吃过几次亏，才明白这东西比你想的复杂得多。

工业控制系统，说白了就是“不能停”的系统。你想想看，一条汽车焊装线，每分钟产值好几万，停一分钟就是真金白银的损失。所以，可靠性不是锦上添花，而是生死存亡。

什么叫可靠性？标准定义是：产品在规定的条件下、规定的时间内，完成规定功能的能力。嗯，这里要注意三个关键词：规定条件、规定时间、规定功能。

我在一个化工厂项目里遇到过这样的情况：PLC在常温实验室里跑得好好的，一装到现场，温度40多度，湿度又大，三天两头死机。你说它不可靠吗？在实验室里挺可靠的。但到了现场，条件变了，可靠性就打了折扣。

所以，谈可靠性一定要绑定使用环境。工业现场常见的“杀手”有：

核心观点：可靠性不是测出来的，是设计出来的。测试只能验证，不能创造。

FMEA，全称是Failure Mode and Effects Analysis。说白了就是“先想好怎么死，再想办法不死”。

我个人习惯在做系统架构时，先拉一张FMEA表格。把每个可能的失效模式列出来，然后评估它的严重度、发生频率和可检测性。最后算出一个风险优先级数（RPN）。

举个例子，一个简单的数字量输入模块：

功能	失效模式	失效原因	影响	严重度(S)	发生频率(O)	可检测性(D)	RPN
DI采集	信号一直为高	光耦短路	误触发	8	3	4	96
DI采集	信号一直为低	光耦开路	漏报	9	3	5	135
DI采集	信号抖动	接触不良	误计数	6	6	3	108

你看，信号一直为低这个模式，RPN最高，因为漏报可能导致安全风险。那怎么办？加硬件冗余，或者做软件诊断——比如定期发送测试脉冲，检查光耦是否正常。

我的经验：FMEA不是做一次就完事的。我建议在方案设计、详细设计、测试验证三个阶段各做一次。每次迭代，RPN会越来越低，系统也越来越皮实。

这三个指标，是衡量可靠性的“三驾马车”。咱们一个一个说。

MTBF = Mean Time Between Failures。意思是“平均多久坏一次”。注意，它只统计可修复的系统。对于不可修复的元器件，我们通常用MTTF（平均失效时间）。

计算公式很简单：

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

举个例子，一台设备运行了10000小时，期间坏了5次，那MTBF就是2000小时。但这里有个坑——MTBF是统计值，不是保证值。我曾经见过一个供应商说他们的PLC MTBF是50万小时，结果现场用了3个月就坏了。为什么？因为MTBF是基于实验室数据推算的，现场环境复杂得多。

MTTR = Mean Time To Repair。意思是“坏了之后多久能修好”。包括故障定位、备件更换、系统恢复的时间。

我建议在设计阶段就考虑MTTR：

注意：MTTR不是越小越好。有些系统为了追求极低的MTTR，做了全冗余设计，结果成本翻倍，维护复杂度也上去了。要找到平衡点。

可用性 = Uptime / (Uptime + Downtime)。也可以写成：

可用性 = MTBF / (MTBF + MTTR)

这个指标最直观。比如一个系统MTBF=1000小时，MTTR=10小时，那可用性就是1000/1010 ≈ 99.01%。

工业界通常用“几个9”来衡量：

可用性	俗称	年停机时间	典型应用
99%	两个9	87.6小时	一般工业设备
99.9%	三个9	8.76小时	生产线控制系统
99.99%	四个9	52.56分钟	电力、石化
99.999%	五个9	5.26分钟	核电站、航空

你看，从三个9到四个9，年停机时间从8.76小时降到52分钟。这背后是巨大的设计投入——冗余、容错、自诊断，一样都不能少。

下面这张图，是我自己总结的可靠性设计知识框架。你可以把它当作本章的“地图”：

这张图把本章的三个核心内容串起来了。你从中间开始看：可靠性设计是核心，左边是定义（三个规定），中间是FMEA（三个步骤），右边是指标（三个数值）。底部是最终目标——高可用性。

避坑指南：我曾经在一个项目里，只盯着MTBF看，觉得数值高就万事大吉。结果设备确实很少坏，但一旦坏了，因为没有做模块化设计，现场工程师修了整整两天。可用性一算，惨不忍睹。所以，MTBF和MTTR要一起抓，缺一不可。

好了，这一章的内容就到这里。可靠性设计不是一蹴而就的，它贯穿在整个产品生命周期里。下一章咱们聊聊具体的硬件可靠性设计方法，包括降额设计、冗余设计这些实战技巧。