功能安全基础概念：危险、风险、安全目标、安全状态、容错时间间隔
各位工程师朋友，欢迎来到第二章。这一章我们聊点实在的——功能安全里那几个绕不开的核心概念。
说实话，我刚入行那会儿，看标准里这些术语，感觉每个字都认识，连起来就懵了。什么危险、风险、安全目标……它们到底啥关系？
后来做项目做多了，才慢慢摸出门道。今天我就用大白话，把这些概念掰开揉碎了讲清楚。
2.1 危险（Hazard）—— 到底哪里会出问题？
先问个问题：你开车时最怕什么？
刹车失灵？转向卡死？油门突然自己加速？
这些，就是「危险」。标准里的定义是：危险是可能导致伤害的潜在源。
说白了，就是系统里可能出故障的地方，而且这个故障一旦发生，会伤到人。
危险的三要素：
- 事件：什么故障发生了？（比如：刹车助力失效）
- 场景：在什么情况下发生？（比如：高速行驶中）
- 后果：会导致什么？（比如：车辆无法减速，碰撞）
我习惯用「如果……那么……」的句式来识别危险。举个例子：
- 如果转向助力突然丢失，那么驾驶员需要施加更大的力才能转向，在低速泊车时可能导致碰撞。
- 如果电池管理系统误报过温，那么系统会强制切断动力，在高速超车时可能导致后车追尾。
你看，同一个故障，在不同场景下，后果完全不一样。这就是为什么做危险分析时，一定要把场景想清楚。
2.2 风险（Risk）—— 这事儿到底有多悬？
危险是「可能出事」，风险是「出事的概率有多大 + 后果有多严重」。
标准里给了一个公式，虽然没明写，但大家都这么理解：
风险 = 危害的严重度 × 发生的概率
举个例子：
- 刹车完全失效：严重度极高（S3），但概率极低（E1）—— 风险中等。
- 车窗升降卡住：严重度极低（S1），但概率较高（E3）—— 风险低。
- 油门非预期加速：严重度高（S2），概率中等（E2）—— 风险高。
我在做ASIL等级评定时，最头疼的就是概率评估。你想想看，一个故障发生的概率，怎么量化？
标准给了三个维度：严重度（S）、暴露概率（E）、可控性（C）。三者组合，得出ASIL等级。
| 维度 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 伤害的严重程度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 危险场景出现的概率 | E0（几乎不）~ E4（非常高） |
| C（Controllability） | 驾驶员或其他人控制局面的能力 | C0（可控）~ C3（不可控） |
我的经验：做风险分析时，别只盯着「最坏情况」。我曾经有个项目，团队把所有场景都按最坏情况评估，结果ASIL等级全是D，根本没法做。后来我们重新梳理了场景，把那些「理论上可能但实际几乎不会发生」的场景单独处理，才把等级降下来。
2.3 安全目标（Safety Goal）—— 我们要做到什么？
识别了危险，评估了风险，接下来就是定目标。
安全目标，就是针对每个危险，我们要达到的安全要求。它回答一个问题：系统必须做到什么，才能避免这个危险？
安全目标的写法有讲究。我总结了一个模板：
「系统应防止 [危险事件] 发生，当 [故障条件] 出现时，系统应在 [时间要求] 内进入 [安全状态]。」
举个例子：
- 危险：高速行驶中，转向助力突然丢失，导致驾驶员无法及时转向。
- 安全目标：系统应防止转向助力意外丢失。当助力系统发生故障时，应在100ms内检测到故障，并提示驾驶员，同时保持基本的机械转向功能。
每个安全目标都会分配一个ASIL等级。这个等级决定了后续开发工作的严格程度。
安全目标的属性：
- ASIL等级：A、B、C、D 或 QM
- FTTI：容错时间间隔（后面会讲）
- 安全状态：故障后系统应该进入什么状态
- 容错机制：用什么方式保证安全
2.4 安全状态（Safe State）—— 出事了怎么办？
安全目标里提到了「进入安全状态」。那什么是安全状态？
安全状态，就是系统发生故障后，能保证人员安全的一种系统状态。
常见的几种安全状态：
- 降级模式：功能受限，但还能用。比如：转向助力降低，但还能转。
- 关闭模式：系统完全关闭。比如：电池管理系统检测到严重故障，直接切断高压。
- 故障容错模式：系统有冗余，一个通道坏了，另一个通道顶上。比如：双路制动系统，一路失效，另一路还能提供50%制动力。
这里有个坑，我踩过。有一次，我们给一个电控单元定义了安全状态为「关闭输出」。结果测试时发现，关闭输出后，系统进入了「死锁」状态，再也醒不过来了。后来我们加了一个「看门狗复位」机制，才解决这个问题。
注意：安全状态不是「一关了之」那么简单。你要考虑：
- 进入安全状态后，系统还能不能恢复？
- 进入安全状态的过程本身会不会引入新的危险？
- 安全状态是否对所有场景都安全？
2.5 容错时间间隔（FTTI）—— 你有多长时间？
最后一个概念，也是很多工程师容易忽略的——容错时间间隔（Fault Tolerant Time Interval, FTTI）。
FTTI的定义是：从故障发生，到危险事件发生之间的时间窗口。
说白了，就是系统有多长时间来响应这个故障，避免危险发生。
举个例子：
- 刹车助力失效：从失效到驾驶员需要全力踩刹车，可能只有200ms。所以FTTI是200ms。
- 电池过温：从检测到过温到电池热失控，可能有10秒。所以FTTI是10秒。
FTTI决定了你的诊断策略和响应速度。如果FTTI很短，你就得用硬件快速检测，比如比较器、看门狗。如果FTTI很长，你可以用软件诊断，比如周期性自检。
| FTTI范围 | 典型场景 | 推荐诊断方式 |
|---|---|---|
| < 10ms | 安全气囊点火 | 硬件冗余 + 硬件比较器 |
| 10ms ~ 100ms | 制动助力失效 | 硬件检测 + 快速软件响应 |
| 100ms ~ 1s | 转向助力失效 | 软件周期性诊断 |
| > 1s | 电池热管理故障 | 软件诊断 + 降级策略 |
我的建议：定义FTTI时，别只盯着「故障检测时间」。你还要考虑：
- 故障检测时间（FDTI）
- 故障响应时间（FRTI）
- 进入安全状态的时间
这三者之和，必须小于FTTI。否则，危险就发生了。
2.6 知识结构图：这些概念怎么串起来？
说了这么多，我画张图帮你理一理思路。
这张图的核心逻辑是：
- 先识别危险：找出所有可能出问题的地方。
- 再评估风险：判断每个危险到底有多严重、多容易发生。
- 然后定安全目标：针对每个危险，明确系统必须做到什么。
- 最后定义安全状态和FTTI：故障发生后，系统怎么响应、多快响应。
这五个概念，就是功能安全的「五环」。缺一个，整个安全体系就不完整。
2.7 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的教训：
坑一：安全目标写得太模糊
我曾经写过一个安全目标：「系统应保证安全」。结果评审时被问：什么叫「安全」？怎么验证？后来我改成：「当制动主缸压力传感器故障时，系统应在50ms内检测到故障，并点亮警告灯，同时启用备用传感器。」—— 这样才可验证、可测试。
坑二：忽略了FTTI的累积效应
有一次，我们定义了一个安全目标的FTTI为200ms。但实际测试时发现，从故障发生到系统进入安全状态，用了350ms。为什么？因为故障检测用了80ms，诊断确认用了50ms，响应执行用了120ms，再加上通信延迟……加起来就超了。所以，定义FTTI时，一定要留余量。
坑三：安全状态本身不安全
这个最要命。我们给一个电机控制器定义了安全状态为「停止输出」。结果在高速公路上，电机突然停止输出，车辆瞬间失去动力，反而更危险。后来我们改成了「降功率输出」，同时提示驾驶员。
嗯，这些坑，希望你们别重蹈覆辙。
好了，这一章就到这里。概念虽然多，但核心就一句话：识别危险、评估风险、定好目标、想好退路、算好时间。把这五个点吃透了，后面的内容就好办了。