系统架构设计的陷阱：冗余设计不足或过度设计
各位工程师朋友，咱们接着聊。这一章我想聊聊系统架构设计里一个特别容易踩坑的地方——冗余设计。
说白了，冗余就是给系统多留几手。但问题来了：留少了，安全目标达不到；留多了，成本蹭蹭往上涨。这个平衡点，我做了十几年功能安全，至今觉得是最考验功力的地方。
陷阱一：冗余设计不足
先说说不足的情况。我见过不少项目，为了省成本，把冗余砍得太狠。结果呢？
- 单点故障直接导致系统失效
- 安全机制覆盖率低，FIT值超标
- 诊断覆盖率不够，ISO 26262审核过不去
举个例子。我之前参与过一个EPS（电动助力转向）项目。架构设计时，扭矩传感器只用了单路。大家觉得「这个传感器挺可靠的，没必要做双路」。结果呢？
路试时传感器确实坏了，方向盘瞬间失去助力。驾驶员吓出一身冷汗。嗯，这个案例后来成了我们内部的反面教材。
陷阱二：冗余设计过度
反过来，过度设计也是个坑。我见过一个团队，给一个ASIL B的系统做了三模冗余（TMR）。
你想想看，三个MCU同步运行，还要做投票机制。成本翻了三倍不说，功耗、体积、散热全成了问题。最后项目因为成本太高被砍掉了。
我个人习惯是：先问自己三个问题——
- 这个冗余真的有必要吗？
- 有没有更经济的替代方案？
- 冗余带来的复杂度，我们团队能驾驭吗？
如何平衡安全性与成本？
这个问题没有标准答案。但我可以分享一些实战经验。
1. 按ASIL等级分级对待
不同安全等级，冗余策略完全不同。我整理了一个表格，供你参考：
| ASIL等级 | 推荐冗余策略 | 典型成本增加 |
|---|---|---|
| ASIL A | 单通道 + 软件监控 | 5-10% |
| ASIL B | 单通道 + 硬件安全机制 | 10-20% |
| ASIL C | 双通道（部分冗余） | 30-50% |
| ASIL D | 双通道（完全冗余） | 50-100% |
注意，这只是参考。实际项目中还要考虑具体功能、失效模式、诊断覆盖率等因素。
2. 善用多样性冗余
同构冗余（两个一样的通道）成本高，而且容易有共因失效。我建议多用多样性冗余。
比如：
- 一个用硬件比较，一个用软件监控
- 一个用电流检测，一个用温度检测
- 一个用主MCU，一个用独立的监控芯片
这样做的好处是：成本增加不多，但安全性能大幅提升。
3. 做FMEA和FTA时就要想清楚
很多团队把FMEA和FTA当成走过场。其实这两个工具是帮你做冗余决策的利器。
我的做法是：
- 先做FMEA，找出所有单点故障
- 再用FTA，分析每个故障对安全目标的影响
- 最后决定：哪些点必须冗余，哪些点可以接受
这样出来的冗余方案，既不会漏，也不会过。
避坑指南
我曾经...在一个ADAS项目中，为了省成本，把制动系统的冗余从双通道改成了单通道加软件监控。结果审核时被安全专家质疑：软件监控的覆盖率够吗？潜伏故障怎么处理？
最后不得不重新设计，反而多花了两个月时间。教训是：冗余设计不能拍脑袋，要用数据说话。
总结一下
冗余设计，说白了就是一场博弈。你既要满足安全目标，又要控制成本。
我的建议是：
- 别盲目追求高冗余，也别为了省钱砍得太狠
- 多用多样性冗余，少用同构冗余
- 用FMEA和FTA指导决策，别靠感觉
- 留好余量，但别过度
嗯，这一章就到这里。下一章我们聊聊「软件架构设计中的常见陷阱」，到时候见。