2、可靠性基础理论：可靠性定义、可靠性指标（MTBF、MTTR、可用度）、失效模式与影响分析（FMEA）
各位同学，咱们今天聊聊可靠性基础理论。说实话，这章内容看起来有点“理论”，但你别小看它。我做了十几年嵌入式火控系统，见过太多“看起来没问题，一上战场就掉链子”的案例。归根结底，就是可靠性没吃透。
好，咱们直接进入正题。
2.1 可靠性的定义——到底什么叫“可靠”？
先问大家一个问题：一个火控系统，开机后能正常工作，算不算可靠？
算，但不够。
可靠性有严格的定义：产品在规定的条件下、规定的时间内，完成规定功能的能力。
注意三个关键词：
- 规定的条件——温度、湿度、振动、电磁干扰，这些都得明确。我见过一个项目，实验室里跑得好好的，拉到高原上就死机。为什么？条件变了，可靠性没覆盖到。
- 规定的时间——火控系统要求连续工作72小时不重启，那72小时就是你的“规定时间”。别跟我说“能用就行”，时间不到，可靠性就是虚的。
- 规定的功能——瞄准、解算、击发，一个都不能少。少一个，就是失效。
核心理解：可靠性不是“能用”，而是“在特定条件下、特定时间内、特定功能不失效”。
我个人习惯把可靠性比作“承诺”。你承诺系统能扛住高温高湿，那就得真扛住。扛不住，就是失信。
2.2 可靠性指标——MTBF、MTTR、可用度
光说“可靠”太抽象，得量化。嵌入式系统里，最常用的三个指标是：MTBF、MTTR、可用度。
2.2.1 MTBF（平均无故障时间）
MTBF，全称 Mean Time Between Failures。说白了，就是系统平均能连续工作多久才出一次故障。
公式很简单：
MTBF = 总工作时间 / 故障次数举个例子：你测试了10套火控系统，每套跑了1000小时，总共10000小时。期间发生了5次故障。那么 MTBF = 10000 / 5 = 2000 小时。
嗯，这里要注意：MTBF 是统计值，不是“保证值”。它不代表“每2000小时才坏一次”，而是“平均来看，2000小时坏一次”。
我的经验：做火控系统，MTBF 一般要求不低于5000小时。但别只看数字，你得看置信区间。我曾经遇到一个项目，MTBF 算出来8000小时，结果实际使用中频繁出问题。后来一查，样本量太小，置信度不够。所以，MTBF 要结合样本量和置信度一起看。
2.2.2 MTTR（平均修复时间）
MTTR，Mean Time To Repair。系统坏了，修好它需要多长时间？
公式：
MTTR = 总维修时间 / 维修次数火控系统里，MTTR 很关键。你想，战场上系统坏了，你能等多久？10分钟？1小时？
我建议：设计时就要考虑“快速定位故障”。比如，加自检程序、故障指示灯、模块化设计。我曾经设计过一个火控板，MTTR 从原来的2小时降到了15分钟。怎么做到的？把电源模块、通信模块、计算模块做成独立可插拔的，坏了直接换，不用现场修。
避坑指南：我曾经见过一个团队，MTTR 算得很漂亮，但实际维修时发现“换模块”需要拆20颗螺丝。嗯，这就不叫“快速修复”了。MTTR 要算上拆装时间、测试时间，别只算“换零件”的时间。
2.2.3 可用度（Availability）
可用度，就是系统“能用”的概率。公式：
可用度 = MTBF / (MTBF + MTTR)举个例子：MTBF = 2000小时，MTTR = 2小时，那么可用度 = 2000 / 2002 ≈ 0.999，也就是99.9%。
你想想看，99.9% 听起来很高，但一年365天，0.1% 的不可用时间就是8.76小时。对于火控系统来说，8.76小时的“掉线”可能是致命的。
| 指标 | 含义 | 火控系统典型要求 |
|---|---|---|
| MTBF | 平均无故障时间 | ≥5000小时 |
| MTTR | 平均修复时间 | ≤30分钟 |
| 可用度 | 系统可用概率 | ≥99.9% |
一句话总结：MTBF 要长，MTTR 要短，可用度要高。三者缺一不可。
2.3 失效模式与影响分析（FMEA）
FMEA，Failure Mode and Effects Analysis。说白了，就是“提前想好系统会怎么坏，以及坏了会怎样”。
我刚开始做火控时，觉得 FMEA 就是走形式。直到有一次，一个电源滤波电容失效，导致整个瞄准系统抖动，差点酿成事故。从那以后，我再也不敢跳过 FMEA。
2.3.1 FMEA 的核心步骤
- 列出所有可能的失效模式——比如：电源掉电、通信中断、传感器漂移、软件死锁。
- 分析失效原因——为什么会出现这个失效？是元器件老化？是软件bug？是外部干扰？
- 评估失效影响——这个失效会导致什么后果？系统瘫痪？精度下降？误触发？
- 确定风险优先级（RPN）——RPN = 严重度 × 发生频率 × 可检测度。分数越高，越要优先处理。
- 制定改进措施——怎么防止这个失效？或者失效后怎么快速恢复？
2.3.2 一个简单的 FMEA 示例
假设我们有一个火控系统的“通信模块”，做 FMEA 如下：
| 失效模式 | 失效原因 | 失效影响 | 严重度 | 发生频率 | 可检测度 | RPN | 改进措施 |
|---|---|---|---|---|---|---|---|
| 通信中断 | 线缆松动 | 无法接收目标数据 | 9 | 3 | 2 | 54 | 加锁紧装置、定期巡检 |
| 数据错误 | 电磁干扰 | 瞄准偏差 | 8 | 4 | 5 | 160 | 加屏蔽、加CRC校验 |
| 通信延迟 | CPU负载过高 | 响应滞后 | 6 | 2 | 3 | 36 | 优化任务调度、加看门狗 |
我的习惯：做 FMEA 时，别只盯着“常见失效”。我建议把“极端情况”也列进去，比如：电源瞬间跌落、通信线被踩断、传感器被遮挡。这些看似“不可能”的事，在战场上都有可能发生。
2.3.3 FMEA 的落地建议
- 别一个人做——FMEA 需要硬件、软件、测试、生产一起讨论。一个人想不全。
- 别只做一次——设计阶段做一次，样机阶段做一次，量产前再做一次。每次都会有新发现。
- 别只写文档——FMEA 的最终目的是“改设计”，不是“交作业”。我见过有人 FMEA 写得漂漂亮亮，但一个改进措施都没落实。那还不如不做。
避坑指南：我曾经参与过一个项目，FMEA 里把“软件死锁”的 RPN 打得很低，觉得“概率小”。结果实际测试中，死锁发生了三次。为什么？因为测试环境没覆盖到高负载场景。所以，FMEA 的“发生频率”一定要基于真实数据，别拍脑袋。
2.4 小结
这一章，咱们讲了三个核心内容：
- 可靠性定义——条件、时间、功能，三个要素缺一不可。
- 可靠性指标——MTBF 要长，MTTR 要短，可用度要高。
- FMEA——提前想失效，提前做预防。
说实话，这些理论看起来简单，但真正做好不容易。我做了这么多年，每次设计新系统，还是会老老实实做 FMEA，算 MTBF。因为我知道，战场上没有“重来一次”的机会。
下一章，咱们聊聊“硬件可靠性设计”，从元器件选型到电路保护，都是实战经验。到时候见。