2. 功能安全核心概念：危害与风险、安全目标、ASIL、安全状态、FTTI
各位好，欢迎来到第二章。上一章我们聊了功能安全为什么重要，以及它到底在解决什么问题。这一章，我们得把几个最核心的概念掰开揉碎了讲清楚。说白了，这些概念就是功能安全这门语言的“单词”。你不懂这些单词，后面读需求、做设计、搞测试，全都会卡壳。
我记得我刚入行那会儿，带我的老工程师扔给我一份几十页的HARA报告，让我自己看。我当时盯着“ASIL D”、“FTTI”、“安全状态”这些词，完全是一头雾水。后来踩了不少坑，才慢慢把这些概念串起来。今天我就把这些经验直接告诉你，省得你再走一遍弯路。
2.1 危害与风险：到底有什么区别？
很多人一开始会把“危害”和“风险”混着用。其实这两个词在功能安全里，意思完全不同。
- 危害（Hazard）：指系统或功能失效后，可能对人造成伤害的潜在源。它是个“客观存在”的东西。比如，刹车踩下去没反应，这就是一个危害。
- 风险（Risk）：指危害实际发生的概率，以及它造成伤害的严重程度。它是个“概率+后果”的综合评估。同样是刹车失效，在高速公路上和在停车场里，风险完全不一样。
一句话总结：危害是“会不会出事”，风险是“出事的可能性有多大、后果有多严重”。
在ISO 26262里，我们做危害分析和风险评估（HARA），目的就是把每个危害对应的风险量化出来。量化出来的结果，就是后面要讲的ASIL等级。
2.2 安全目标：功能安全的“宪法”
安全目标（Safety Goal），是功能安全里最顶层的安全要求。它直接告诉你：为了把某个危害的风险降到可接受的水平，系统必须做到什么。
举个例子。假设我们分析出一个危害：“车辆在行驶中，转向助力突然丢失，导致驾驶员无法正常转向”。那么对应的安全目标可能就是：“转向助力功能在车辆行驶过程中，必须保持可用，且失效概率低于某个阈值”。
安全目标有几个特点：
- 它是顶层要求，所有后续的安全机制都要围绕它来设计。
- 它必须可验证。你不能写“系统要足够安全”，你得写“系统在发生某种故障后，必须在100ms内进入安全状态”。
- 每个安全目标都会关联一个ASIL等级，这个等级决定了开发过程中需要多严格。
我的经验：写安全目标的时候，千万别写得太抽象。我曾经见过一个安全目标写着“系统应避免意外加速”。这太模糊了。什么叫“意外”？什么条件下算“避免”？后来我们把它改成了“当油门踏板位置传感器信号不一致时，系统必须在50ms内将扭矩请求降为0，并点亮故障灯”。这样测试工程师才知道怎么测。
2.3 ASIL：功能安全等级到底怎么定？
ASIL，全称是Automotive Safety Integrity Level，汽车安全完整性等级。它分为四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个等级叫QM（Quality Management），意思是按普通质量管理做就行，不需要额外功能安全措施。
ASIL等级是怎么定的？ISO 26262给了三个参数：
| 参数 | 含义 | 等级 |
|---|---|---|
| Severity (S) | 危害发生时，对人员伤害的严重程度 | S0（无伤害）~ S3（致命） |
| Exposure (E) | 危害场景发生的概率（暴露程度） | E0（几乎不可能）~ E4（非常高） |
| Controllability (C) | 驾驶员或其他人员控制住危害的能力 | C0（完全可控）~ C3（几乎不可控） |
把这三个参数组合起来，查ISO 26262里的表格，就能得到对应的ASIL等级。比如S3+E4+C3，组合出来就是ASIL D。
注意：ASIL等级不是越高越好。等级越高，开发成本、验证难度、时间周期都会成倍增加。我见过有些团队为了“保险”，把所有功能都定成ASIL D。结果项目做到一半发现预算根本不够，最后不得不返工重新评估。合理分配ASIL等级，是功能安全工程师的核心能力之一。
2.4 安全状态：系统出问题后该往哪跑？
安全状态（Safe State），指的是系统发生故障后，能够避免或减轻危害的一种系统状态。说白了，就是系统“认怂”之后，待在哪里最安全。
常见的安全状态有：
- 断电/关断：比如电机控制器检测到过流，直接切断功率管驱动信号。
- 降级运行：比如ADAS摄像头被遮挡，系统自动把车速限制在30km/h以下，并提示驾驶员接管。
- 维持当前状态：比如转向系统检测到传感器故障，但还能维持当前转向角度，直到驾驶员停车。
设计安全状态时，有几个关键点：
- 安全状态必须是可达的。你不能说“系统进入安全状态”，但实际硬件已经坏了，根本进不去。
- 安全状态必须是可保持的。进入之后，系统不能自己又跑出来。
- 安全状态必须明确文档化。每个安全目标对应的安全状态是什么，要在需求里写清楚。
我踩过的坑：有一次我们设计一个电子水泵的安全状态，想的是“检测到故障就停机”。结果测试发现，水泵停机后，发动机冷却液不循环，水温迅速升高，反而引发了更严重的问题。后来我们改成了“降速运行+报警”，让驾驶员有时间开到安全地点。所以，安全状态不是越“安全”越好，得结合系统上下文来看。
2.5 故障容错时间间隔：给系统留多少“抢救时间”？
FTTI，全称Fault Tolerant Time Interval，故障容错时间间隔。它指的是：从故障发生，到危害实际发生之间，留给系统反应的时间窗口。
这个时间窗口决定了：
- 故障检测必须在多长时间内完成。
- 故障响应（比如进入安全状态）必须在多长时间内完成。
- 整个安全机制的反应速度必须快于FTTI。
举个例子。假设一个电子刹车助力系统，如果助力电机突然失效，驾驶员还能靠人力踩下刹车，但需要更大的力。如果这个“人力可踩”的时间窗口是500ms，那么FTTI就是500ms。系统必须在500ms内检测到故障，并给出提示（比如仪表盘报警），或者切换到备用模式。
FTTI的确定，通常需要结合系统仿真、实车测试和工程经验。它不是拍脑袋定的，而是有依据的。
| 系统类型 | 典型FTTI | 说明 |
|---|---|---|
| 线控制动 | 10~100 ms | 制动响应要求极高，时间窗口很短 |
| 电动助力转向 | 100~500 ms | 驾驶员可以短时间补偿，但时间长了会失控 |
| 电池管理系统 | 1~10 s | 热失控过程相对较慢，但一旦发生后果严重 |
| 车载信息娱乐 | 通常不适用 | 不涉及直接安全危害，一般不做FTTI要求 |
特别提醒：FTTI不是“故障检测时间”，也不是“故障响应时间”。它是整个时间窗口的上限。你设计的安全机制，从故障发生到系统进入安全状态，总时间必须小于FTTI。我曾经见过一个团队，把FTTI当成了故障检测的deadline，结果检测是按时完成了，但响应动作花了更长时间，最终超出了FTTI，危害还是发生了。
2.6 知识结构总览
下面这张图，把本章的核心概念串在了一起。你可以把它当作一张“功能安全概念地图”。
2.7 本章小结
这一章我们讲了五个核心概念：
- 危害与风险：一个是“潜在伤害源”，一个是“概率+后果”。
- 安全目标：顶层安全要求，所有设计的出发点。
- ASIL等级：由S、E、C三个参数决定，等级越高要求越严。
- 安全状态：系统出问题后的“避风港”，必须可达、可保持、可文档化。
- FTTI：留给系统“抢救”的时间窗口，决定了检测和响应的速度要求。