4. 功能安全概念（FSC）：定义、安全机制、FTTI 与安全状态

各位好，欢迎来到第四章。前面我们聊了危害分析与风险评估（HARA），拿到了 ASIL 等级和安全目标（SG）。但光有目标不行，你得落地。怎么落地？就是本章要讲的功能安全概念（FSC）。

说白了，FSC 就是一份“技术翻译稿”。它把安全目标这种“高层要求”，翻译成系统层面的“技术实现方案”。我个人的习惯是，在 HARA 刚做完、还没开始画架构图的时候，就先把 FSC 文档的骨架搭起来。为什么？因为后面所有的硬件软件设计，都要围着它转。

4.1 功能安全概念到底在定义什么？

FSC 不是一张电路图，也不是一段代码。它是一组系统级的安全要求。它要回答三个核心问题：

• 怎么检测故障？ —— 靠安全机制。
• 检测到故障后，多久必须反应？ —— 靠故障容错时间间隔（FTTI）。
• 反应之后，系统进入什么状态？ —— 靠安全状态。

这三者缺一不可。我见过一个项目，安全机制设计得特别复杂，但没定义清楚 FTTI。结果故障检测出来了，系统花了 2 秒才进入安全状态，而控制器在 500 毫秒内就已经失控了。这就是典型的“白忙活”。

4.2 安全机制设计：不是越多越好

安全机制是 FSC 的“手脚”。它负责检测故障，或者防止故障导致安全目标被违反。常见的分类有：

设计安全机制时，我有一条原则：够用就好，别过度设计。你想想看，ASIL B 的项目，你非要上双核锁步，成本翻倍不说，开发周期也拉长。我曾经在一个 BMS 项目中，为了追求“绝对安全”，给每个电压采样通道都加了独立的硬件比较器。结果呢？PCB 面积不够，散热出问题，最后还得改方案。所以，安全机制的粒度要和 ASIL 等级匹配。

4.3 故障容错时间间隔（FTTI）：生死时速

FTTI 是个时间窗口。从故障发生，到系统必须进入安全状态，这中间的时间就是 FTTI。它不是拍脑袋定的，而是从安全目标推导出来的。

举个例子：EPS（电动助力转向）的安全目标是“转向不能无指令自转”。如果扭矩传感器坏了，系统必须在 100 毫秒内切断助力。这 100 毫秒就是 FTTI。

FTTI 的分配很讲究。它通常被拆成三段：

1. 故障潜伏时间： 故障发生了，但还没被检测到。
2. 故障检测时间： 安全机制正在诊断，还没出结果。
3. 故障响应时间： 检测到了，开始执行降级或关断。

这三段加起来，必须小于等于 FTTI。我建议你在设计时，给每段都留 20% 的余量。为什么？因为硬件有公差，软件有抖动。我曾经在一个项目中，把 FTTI 算得死死的，结果量产时发现，某批芯片的看门狗超时时间偏大，导致总时间超了 5 毫秒。嗯，从那以后，我再也不敢把余量卡得太紧。

4.4 安全状态定义：退路要清晰

安全状态，就是系统“认怂”之后的样子。它必须明确、可执行、可验证。常见的安全状态有：

• 切断动力： 比如逆变器关断、继电器断开。
• 降级运行： 比如限速 30km/h、限制扭矩输出。
• 维持当前状态： 比如保持刹车压力不变，直到驾驶员接管。

定义安全状态时，最容易犯的错误是“一刀切”。我见过一个项目，所有故障都进入“系统关断”。结果呢？高速上动力电池过热，BMS 直接切断高压，车辆瞬间失去动力。这比过热本身更危险。所以，安全状态必须和故障的严重程度挂钩。

我个人习惯用一张表来定义安全状态：

你看，不同故障的“退路”不一样。有的可以自己恢复，有的必须进维修站。这些都要在 FSC 里写清楚。

4.5 知识结构总览

下面这张图，是我自己画的功能安全概念核心逻辑。它把 FSC 的四个要素串在了一起。你可以把它当作设计时的检查清单。

4.6 避坑指南：我踩过的几个坑

最后，分享几个实战中容易忽略的点：

• 别把 FSC 写成“愿望清单”。 我曾经见过一份 FSC，安全机制写了 50 多条，但一半以上没有对应的实现方案。这种文档评审时会被直接打回。每条安全机制，都要有明确的“谁来做、怎么做、何时做”。
• FTTI 要算，更要测。 文档里写 100 毫秒，实际跑出来 120 毫秒，这种事我遇到过。所以，我建议在系统集成测试阶段，专门安排 FTTI 验证用例。用示波器抓信号，用软件打时间戳，实测为准。
• 安全状态要考虑“恢复路径”。 很多团队只定义了“怎么进去”，没定义“怎么出来”。结果系统进入安全状态后，再也回不来了。这会导致用户体验极差。所以，每个安全状态都要配套一个“退出条件”。

好了，这一章的内容就到这里。FSC 是整个功能安全开发的“宪法”，后面所有的设计都要遵循它。希望你能把今天讲的方法，用到自己的项目中去。