3. 安全机制设计原则：故障检测、故障响应、故障避免的基本概念
各位好，我是老张。今天咱们聊聊安全机制设计的三个核心原则。说实话，这三个概念我刚开始接触时也容易搞混。故障检测、故障响应、故障避免——听起来差不多，但实际应用起来差别很大。
我个人的习惯是，拿到一个功能安全项目，先问自己三个问题：
- 这个故障我能提前发现吗？——这是故障检测
- 发现了之后怎么办？——这是故障响应
- 能不能从一开始就别让它发生？——这是故障避免
你想想看，这三个问题其实对应了安全机制的不同阶段。咱们一个一个来拆解。
3.1 故障检测：发现问题
故障检测，说白了就是「看住」系统。你得有办法知道系统是不是出问题了。我在项目中遇到过不少案例，故障检测做得不到位，等到问题暴露出来，已经造成了严重后果。
常见的故障检测手段有哪些？我列几个典型的：
- 自检（Self-Test）：系统启动时或运行中，自己检查自己。比如CPU的LBIST（逻辑内建自测试），每次上电跑一遍，看看逻辑有没有坏。
- 冗余比较：两个相同的模块做同样的事，比较结果。不一致？那肯定有一个出问题了。
- 看门狗（Watchdog）：这个大家应该很熟悉。程序跑飞了？看门狗定时器超时，直接复位。
- 校验和/CRC：数据在传输或存储过程中有没有被篡改？算一下校验和就知道了。
重点来了：故障检测的覆盖率不是100%的。你设计一个检测机制，能覆盖多少故障？这个需要量化。ISO 26262里有个概念叫「诊断覆盖率」，你得算清楚。
举个例子，我之前做一个ADAS项目，用的双核锁步（Lockstep）技术。两个核执行同样的指令，每个周期比较结果。这种检测覆盖率很高，但代价也大——功耗、面积都翻倍。所以，检测手段的选择是个权衡。
3.2 故障响应：出了问题怎么办
检测到故障了，然后呢？不能光报警不处理吧。故障响应就是定义「发现故障后系统该做什么」。
我见过一些新手工程师，只关注检测，不关注响应。结果检测到故障了，系统不知道该干嘛，直接卡死。嗯，这比没检测还糟糕。
常见的故障响应策略有：
- 安全状态（Safe State）：系统进入一个已知安全的状态。比如电机驱动系统，检测到过流，立即切断动力输出。
- 降级模式（Degraded Mode）：不是完全停止，而是降低功能。比如刹车系统，主通道故障了，切换到备份通道，但性能可能下降。
- 故障容错（Fault Tolerance）：系统继续运行，但容忍这个故障。比如三模冗余（TMR），一个模块坏了，另外两个还能正常工作。
- 系统复位/重启：有时候最简单的方法就是重启。但要注意，重启后故障还在不在？如果还在，那就陷入死循环了。
我的经验：故障响应的时间窗口很重要。从检测到故障到系统进入安全状态，这个时间必须小于系统要求的故障容错时间间隔（FTTI）。我曾经在一个项目中，检测到故障用了10ms，但响应动作花了50ms，结果超出了FTTI，系统还是出了安全问题。后来我们优化了响应路径，把时间压到了20ms以内。
3.3 故障避免：从源头解决问题
故障避免，说白了就是「别让它发生」。这是最高级的策略，也是最容易被忽视的。
你想想看，如果设计阶段就把可能导致故障的因素排除了，后面检测和响应的工作量是不是就小多了？
故障避免的手段包括：
- 降额设计（Derating）：元器件不要用到极限。比如一个电阻额定功率1W，你只让它跑0.5W。这样即使有波动，也不容易烧坏。
- 冗余设计（Redundancy）：关键路径做备份。一个坏了，另一个顶上。
- 物理隔离：把高风险的电路和低风险的电路分开。比如高压和低压之间要有足够的爬电距离。
- 使用经过认证的组件：别用那些来路不明的芯片。我见过有人为了省钱，用了非车规级的电容，结果高温下全挂了。
注意：故障避免不是万能的。有些故障你根本避免不了——比如随机硬件故障（芯片内部原子级的失效）。这时候你就得靠检测和响应来兜底了。
3.4 三者之间的关系
这三个原则不是孤立的。我画个简单的逻辑图给你看：
| 原则 | 目标 | 典型手段 | 适用场景 |
|---|---|---|---|
| 故障避免 | 不让故障发生 | 降额、冗余、隔离 | 设计阶段、系统架构 |
| 故障检测 | 发现已发生的故障 | 自检、看门狗、CRC | 运行阶段、持续监控 |
| 故障响应 | 处理已发现的故障 | 安全状态、降级、复位 | 检测到故障后 |
实际项目中，这三者是配合使用的。举个例子：
- 设计时先做故障避免——选好元器件，做好降额。
- 运行时做故障检测——看门狗盯着，CRC校验着。
- 一旦检测到故障，立即执行故障响应——进入安全状态。
你看，缺了哪个环节都不行。只做避免，万一有漏网之鱼呢？只做检测，发现了不处理等于白搭。只做响应，没有检测机制你响应个啥？
3.5 避坑指南
最后，我分享几个自己踩过的坑：
- 别把故障检测和故障响应混为一谈。我曾经在一个项目里，把看门狗超时直接当成故障响应——超时了就复位。但问题是，看门狗只是检测手段，复位才是响应。你得明确区分，否则设计文档写出来一团糟。
- 故障避免不是越贵越好。我见过有人为了追求高可靠性，所有器件都选军用级。结果成本翻了好几倍，客户根本接受不了。合理的做法是：根据ASIL等级来定，该花的地方花，不该花的地方省。
- 别忘了故障响应的可测试性。你设计了一个安全状态，但怎么验证它确实能进入安全状态？我在一个项目中，安全状态是切断电源，但测试时发现切断电路本身有bug，根本切不断。所以，响应机制本身也要做测试。
好了，关于故障检测、故障响应、故障避免的基本概念，今天就聊到这儿。下一节咱们会深入讲具体的实现方法，比如怎么用ETAS的工具链来做这些安全机制的开发和验证。到时候我会结合实际的代码和配置，带大家走一遍完整的流程。