4. 传感器硬件设计基础：硬件架构设计要求、冗余设计（对称与非对称）、诊断覆盖率（DC）概念
各位工程师朋友，咱们今天聊点实在的。传感器硬件设计，说白了就是和安全打交道。我做了十几年功能安全，见过太多因为硬件架构考虑不周，最后返工重来的案例。这一节，咱们把硬件设计的几个核心概念掰开揉碎了讲清楚。
4.1 硬件架构设计要求：别让单点故障毁了你的设计
硬件架构设计，核心就一句话：不能让一个零件的失效，导致整个系统完蛋。ISO 26262 对硬件架构的要求，其实是在逼你思考——如果这个电阻短路了，那个电容开路，系统还能不能安全地停下来？
我个人习惯，在设计初期先画一张安全架构图。这张图不画具体电路，只画功能模块和它们之间的安全关系。比如一个刹车压力传感器，你得明确：
- 主路径：传感器采集压力 → 信号调理 → ADC → MCU
- 监控路径：独立的诊断模块，实时检查主路径是否正常
- 安全状态：一旦发现异常，系统能进入什么状态？是降级运行，还是直接切断动力？
这里有个坑，我踩过。有一次设计一个加速度传感器，主路径和监控路径共用了同一个电源芯片。结果电源芯片失效，两条路径同时瘫痪。嗯，这就是典型的共因失效。所以架构设计时，一定要做独立性分析——关键路径之间，电源、时钟、复位、通信，能分开就分开。
核心要求总结：
- 单点故障不能违反安全目标（ASIL 等级越高，要求越严）
- 潜在故障（潜伏故障）要有机制检测出来
- 硬件架构要支持故障响应时间要求（比如 10ms 内必须进入安全状态）
- 避免共因失效（独立性设计）
4.2 冗余设计：对称 vs 非对称，怎么选？
冗余设计，说白了就是「多准备一套方案」。但怎么准备，有讲究。
4.2.1 对称冗余：两个一模一样的「双胞胎」
对称冗余，就是两个完全相同的通道。比如两个同样的压力传感器，同时测量同一个压力值。输出结果一比较，如果差异超过阈值，就报故障。
这种设计的优点是简单、直观。但缺点也很明显——共因失效风险高。两个一模一样的传感器，用的同样的芯片、同样的算法，如果设计本身有缺陷，两个会同时出问题。
我记得在做一个方向盘转角传感器项目时，客户坚持用对称冗余。结果 EMC 测试时，一个强脉冲打过来，两个通道同时跳变。你说巧不巧？从那以后，我建议客户至少要在供电或采样时序上做差异化处理。
4.2.2 非对称冗余：一个主攻，一个监控
非对称冗余，是两个通道不完全相同。比如主通道用高精度 ADC，监控通道用简单的比较器。或者主通道用软件算法，监控通道用纯硬件逻辑。
这样做的好处是：
- 共因失效风险低——两个通道实现方式不同，同一个干扰很难同时影响两者
- 成本可控——监控通道可以简化，只做「好/坏」判断，不要求精度
- 诊断覆盖率更高——因为实现方式不同，能覆盖的故障模式更广
但非对称也有代价：设计复杂，验证困难。你得证明两个通道虽然不同，但都能正确完成安全任务。
我的建议：
对于 ASIL B 以下，对称冗余够用。ASIL C/D，强烈推荐非对称。我曾经在一个线控制动项目中，主通道用霍尔传感器，监控通道用磁阻传感器，两种物理原理不同，EMC 和温度特性互补，效果非常好。
4.3 诊断覆盖率（DC）概念：你的「体检」到底查出了多少问题？
诊断覆盖率，英文叫 Diagnostic Coverage，简称 DC。它衡量的是：当硬件发生故障时，你的诊断机制能检测出来的比例。
公式很简单：
DC = 检测到的故障率 / 总故障率但实际用起来，没那么简单。ISO 26262 把 DC 分成了几个等级：
| DC 等级 | 数值范围 | 含义 |
|---|---|---|
| 低 | 60% - 90% | 能检测大部分常见故障 |
| 中 | 90% - 99% | 能检测绝大多数故障 |
| 高 | ≥ 99% | 几乎能检测所有故障 |
你想想看，如果你的传感器 DC 只有 60%，意味着 100 次故障里有 40 次你完全不知道。对于 ASIL D 的系统，这是不可接受的。
怎么算 DC？我一般用故障模式与影响分析（FMEA）的方法。列出每个元件的每个故障模式，然后评估你的诊断机制能不能检测到它。
举个例子：一个电压检测电路，用电阻分压。
- 故障模式：R1 开路 → 输出为 0V → 诊断：窗口比较器能检测到 → 覆盖
- 故障模式：R1 短路 → 输出为 VCC → 诊断：窗口比较器能检测到 → 覆盖
- 故障模式：R1 阻值漂移 10% → 输出偏差 5% → 诊断：精度不够，检测不到 → 未覆盖
把所有故障模式加起来，算一个比例，就是 DC。
注意：DC 不是越高越好。追求 99.9% 的 DC，可能意味着成本翻倍、设计极其复杂。要根据 ASIL 等级合理选择。我曾经见过一个团队，为了把 DC 从 99% 提到 99.5%，多花了三个月时间，最后客户说没必要。嗯，这个度要把握好。
4.4 知识体系总览：一张图看懂
下面这张图，是我自己总结的传感器硬件设计核心逻辑。你把它打印出来贴在工位上，每次设计前看一眼，能少走很多弯路。
4.5 实战避坑指南
最后，分享几个我亲身踩过的坑，希望能帮你省点时间：
- 别迷信「双通道」：两个通道如果共用同一个晶振，一个晶振失效，两个通道一起完蛋。我曾经在一个项目中，两个 MCU 共用同一个外部晶振，结果晶振停振，系统直接死机。后来改成独立晶振 + 内部 RC 备份，才解决问题。
- 诊断覆盖率不是算出来的，是设计出来的：别等到硬件做完了才去算 DC。应该在设计阶段就规划好诊断机制。我习惯在原理图阶段，每个关键节点旁边标注「诊断方式：窗口比较器 / 看门狗 / CRC 校验」。
- 冗余不是越多越好：三重冗余（TMR）听起来很安全，但带来的问题是：三个结果不一致时，怎么投票？投票逻辑本身会不会失效？我见过一个项目用了三重冗余，结果投票逻辑的软件 bug 导致系统误判，反而比单通道更不可靠。
- 别忘了「安全状态」：冗余和诊断做得再好，如果系统检测到故障后不知道往哪跑，等于白做。每个传感器都要明确：故障时是输出 0V？还是保持最后有效值？还是切断电源？这个要在架构设计阶段就定下来。
一句话总结：
硬件架构是骨架，冗余设计是肌肉，诊断覆盖率是体检报告。三者缺一不可，互相影响。设计时别孤立地看，要整体考虑。
好了，这一节的内容就到这里。下一节咱们聊聊具体的传感器选型与电路设计，到时候我会拿几个实际项目中的电路图出来拆解。各位先消化一下今天的内容，有问题随时交流。
公众号:蓝海资料掘金营，微信deep3321