4、需求阶段可靠性：需求捕获、FMEA与可靠性指标分解
各位工程师朋友，今天我们聊聊需求阶段的可靠性。很多人觉得可靠性是测试阶段的事，等样机出来了再测一测就行。说实话，这种想法很危险。我在IVI项目里吃过不少亏，后来才明白——可靠性是从需求阶段就开始设计的。
4.1 需求捕获：别让模糊的需求坑了你
需求捕获听起来简单，不就是把客户要的东西写下来吗？其实没那么简单。我见过太多项目，需求文档写得漂漂亮亮，结果做出来根本不是那么回事。
为什么会这样？因为需求捕获有三个常见陷阱：
- 需求模糊：比如“系统响应要快”，多快算快？200ms还是2s？
- 需求遗漏：只关注功能，忽略了非功能需求（温度、振动、EMC等）
- 需求冲突：性能要求和成本要求打架，没人拍板
我的经验：做需求捕获时，一定要把“可靠性需求”单独列出来。比如工作温度范围、湿度范围、振动等级、使用寿命等。这些不是可选项，是必选项。
我个人习惯用QFD（质量功能展开）来梳理需求。把客户声音（VOC）转化成技术指标。举个例子：
| 客户需求 | 技术指标 | 可靠性关联 |
|---|---|---|
| 导航不能死机 | 连续运行72小时无重启 | 高 |
| 屏幕夏天不黑屏 | 85℃环境下正常工作 | 高 |
| 倒车影像不延迟 | 从挂R挡到显示画面≤200ms | 中 |
4.2 FMEA：把失效扼杀在摇篮里
FMEA（失效模式与影响分析）是需求阶段最重要的可靠性工具。说白了，就是提前想好“这东西会怎么坏”。
我记得刚入行时，觉得FMEA就是填表格，走形式。直到有一次，一个IVI项目在高温测试时频繁重启，查了两个月才发现是电源芯片的散热设计有问题。如果当初做了FMEA，这个坑完全可以避免。
4.2.1 FMEA怎么做？
我建议分三步走：
- 识别失效模式：每个功能模块，想想它可能怎么失效。比如屏幕可能黑屏、花屏、触摸失灵。
- 分析影响：这个失效会带来什么后果？是影响用户体验，还是影响安全？
- 制定措施：怎么预防？怎么检测？怎么补救？
避坑指南：我曾经犯过一个错误——只分析硬件，忽略了软件。其实IVI系统的软件失效比硬件更频繁。比如内存泄漏、死锁、看门狗超时等，都要纳入FMEA范围。
这里给一个简化的FMEA示例：
| 功能模块 | 失效模式 | 影响 | 严重度(S) | 发生度(O) | 探测度(D) | RPN | 措施 |
|---|---|---|---|---|---|---|---|
| 电源管理 | 电压跌落 | 系统重启 | 9 | 4 | 3 | 108 | 增加欠压保护电路 |
| 存储模块 | eMMC寿命耗尽 | 数据丢失 | 8 | 3 | 5 | 120 | 增加磨损均衡算法 |
| 显示驱动 | LVDS信号干扰 | 屏幕闪烁 | 6 | 5 | 4 | 120 | 增加屏蔽和滤波 |
RPN（风险优先数）超过100的，必须要有改进措施。这是硬性要求。
4.3 可靠性指标分解：从上到下，层层落实
有了需求，做了FMEA，接下来就是把可靠性指标分解到各个子系统。你想想看，整车厂给我们的MTBF（平均无故障时间）要求可能是5000小时，但你不能直接把这个指标扔给硬件团队和软件团队。得拆开。
4.3.1 怎么分解？
我常用的方法是可靠性框图（RBD）。把系统拆成串联和并联的模块，然后计算每个模块的失效率。
举个例子，IVI系统可以拆成：
- 主控板（CPU+内存+存储）
- 显示模组（屏幕+背光+触摸）
- 通信模块（WiFi+蓝牙+4G/5G）
- 音频模块（功放+喇叭）
- 电源模块（DCDC+LDO）
如果系统是串联结构（任何一个模块失效，整个系统就失效），那么系统失效率就是各模块失效率之和。
计算公式：λ_system = λ_1 + λ_2 + ... + λ_n
MTBF_system = 1 / λ_system
假设整车厂要求MTBF≥5000小时，那么系统失效率λ_system ≤ 0.0002/小时。如果系统有5个串联模块，每个模块的失效率就要控制在0.00004/小时以内。
4.3.2 软件可靠性怎么分？
嗯，这里要注意。软件没有“磨损”的概念，所以不能用硬件那套MTBF。我建议用缺陷密度和故障率来评估。
比如：
- 每千行代码的缺陷数（Defects/KLOC）
- 每百万次运行的故障次数（FPM）
- 软件重启率（次/月）
警告：千万不要把硬件的MTBF直接套到软件上。我见过有项目这么干，结果软件团队被逼得没办法，只能“造假”数据。软件可靠性要用软件的方法来评估。
4.4 需求阶段的可靠性评审
最后，我建议在需求阶段结束时做一次可靠性评审。评审清单包括：
- 可靠性需求是否完整？（温度、湿度、振动、寿命、EMC等）
- FMEA是否覆盖了所有高风险模块？
- 可靠性指标是否分解到子系统/模块？
- 是否有明确的验证计划？（HALT、HASS、ALT等）
- 是否有备选方案？（关键器件是否有第二供应商？）
说实话，很多项目在需求阶段花的时间不够，后面测试阶段就得花十倍的时间来补。我个人的经验是：需求阶段多花一周，测试阶段能省一个月。这笔账，你算算就明白了。
好了，需求阶段的可靠性就聊到这里。下一章我们讲设计阶段的可靠性——怎么把需求转化成可靠的设计方案。