4、安全机制设计：故障检测与响应机制、看门狗与心跳监控、内存校验（ECC/SECDED）、冗余传感器信号校验
安全机制，说白了就是系统的「免疫系统」。ISO 26262 要求我们，光把功能做对还不够，还得在出问题时能自己发现、自己处理。这一章，我带你过一遍制动控制里最常用的几套安全机制。
4.1 故障检测与响应机制
故障检测不是目的，响应才是。我见过不少项目，检测做得挺全，但响应策略一塌糊涂——要么过度反应导致频繁宕机，要么反应太慢错过安全窗口。
4.1.1 故障检测的层级
按我的习惯，故障检测分三个层级：
- 信号级：检查单个信号是否在合理范围内（比如电压、频率、时序）。
- 功能级：检查功能逻辑是否正确（比如制动请求与实际制动压力的偏差）。
- 系统级：检查系统状态是否一致（比如双通道冗余结果是否匹配）。
4.1.2 故障响应策略
检测到故障后，系统必须进入安全状态。对于 ASIL D 的制动系统，常见的响应策略有：
| 故障严重程度 | 响应策略 | 典型动作 |
|---|---|---|
| 轻微 | 降级运行 | 降低制动助力，提示驾驶员 |
| 中等 | 切换冗余通道 | 主通道故障，切到备份通道 |
| 严重 | 安全停机 | 激活紧急制动，进入安全状态 |
4.2 看门狗与心跳监控
看门狗，老生常谈了。但在 ASIL D 的制动系统里，它可不是随便一个定时器就能糊弄过去的。
4.2.1 窗口看门狗 vs 功能看门狗
我个人习惯把看门狗分成两类：
- 窗口看门狗：要求程序必须在规定的时间窗口内喂狗。太早或太晚都算故障。这能防止程序跑飞后「碰巧」喂狗。
- 功能看门狗：除了时间约束，还要求喂狗时携带特定的「问题-答案」校验。比如，主核计算一个 CRC，喂狗时把 CRC 值传过去，看门狗核对是否正确。
4.2.2 心跳监控
心跳监控，说白了就是两个核之间互相「打招呼」。每个核定期发送一个递增的序列号，对方收到后检查序列号是否连续。如果连续丢了几次心跳，就认为对方挂了。
4.3 内存校验（ECC/SECDED）
内存里的数据，随时可能被宇宙射线打翻一个比特。对于 ASIL D 的系统，单比特翻转必须能被检测并纠正。
4.3.1 ECC 与 SECDED
ECC（Error Correcting Code）和 SECDED（Single Error Correction, Double Error Detection）其实是一回事。它们能：
- 纠正 1 比特错误
- 检测 2 比特错误
对于制动控制器的 RAM 和 Flash，我建议至少使用 SECDED。如果成本允许，还可以加上 BIST（Built-In Self Test）定期检查内存单元是否 stuck-at 故障。
4.3.2 内存校验的覆盖范围
| 内存区域 | 推荐保护方式 | 诊断覆盖率 |
|---|---|---|
| 程序 Flash | CRC + SECDED | >99% |
| 数据 RAM | SECDED | >99% |
| 寄存器 | 硬件三模冗余（TMR） | >99.9% |
4.4 冗余传感器信号校验
制动系统里，传感器信号是命根子。轮速、制动压力、踏板位移……任何一个信号出错，都可能导致制动失效。
4.4.1 信号校验的常用方法
我总结了几种常用的校验方法：
- 范围检查：信号是否在物理合理范围内（比如轮速不可能为负）。
- 变化率检查：信号变化是否过快（比如制动压力不可能在 1ms 内从 0 跳到 100bar）。
- 冗余比较：两个独立传感器测量同一个物理量，差值是否在容忍范围内。
- 模型预测：用系统模型预测当前信号值，与实际值对比。
4.4.2 冗余传感器的投票机制
对于 ASIL D 的制动系统，我通常用三冗余传感器 + 2oo3（2 out of 3）投票。具体做法：
- 三个传感器独立测量同一个物理量。
- 两两比较，如果两个值一致，第三个不一致，则取一致的两个值。
- 如果三个值都不一致，则进入安全状态。
4.5 安全机制的整体架构
下面这张图，是我做项目时常用的安全机制架构。它把上面讲的内容串在了一起。
嗯，这张图把整个安全机制的层次关系讲清楚了。应用层在最上面，安全机制层在中间，硬件层和诊断层在下面。每一层都依赖下一层提供的能力。