2. 风险评估框架：HAZOP方法、STPA方法、FMEA方法、FTA方法、风险矩阵
各位同学，咱们今天聊点实在的。做预期功能安全，说白了就是跟「未知风险」打交道。你想想看，一个自动驾驶系统在路上跑，传感器可能被遮挡，算法可能误判，执行器可能延迟——这些都不是传统硬件故障能解释的。
那怎么把这些「妖魔鬼怪」揪出来？靠的就是一套靠谱的风险评估框架。我这些年做过的项目，从ADAS到L4级系统，基本都离不开这五个工具：HAZOP、STPA、FMEA、FTA，再加上风险矩阵。今天我就把它们的用法、坑点、以及我个人的实战经验，一次性讲透。
核心观点：没有完美的工具，只有合适的组合。预期功能安全的风险评估，从来不是「一招鲜」，而是「组合拳」。
2.1 HAZOP方法：老牌化工工具，在自动驾驶里照样能打
HAZOP，全称是Hazard and Operability Study。这玩意儿最早是化工行业搞出来的，用来分析管道泄漏、反应釜爆炸之类的问题。我刚开始做汽车安全时，也觉得这跟自动驾驶八竿子打不着。但后来发现——其实逻辑是通的。
HAZOP的核心思路是：用「引导词」去挑战系统的每一个功能。比如「没有」、「更多」、「更少」、「相反」、「部分」等等。你对着一个功能问：如果这个功能没有发生会怎样？如果它相反了会怎样？
举个例子，ACC自适应巡航的「目标检测」功能：
| 引导词 | 偏差描述 | 潜在后果 |
|---|---|---|
| 没有 | 未检测到前方车辆 | 追尾碰撞 |
| 更多 | 检测到多个虚假目标 | 频繁误制动 |
| 相反 | 将静止物体识别为移动车辆 | 错误决策 |
| 部分 | 只检测到部分目标（如卡车尾部） | 碰撞风险 |
我在一个L2+项目中用过HAZOP。当时团队花了三天时间，把每个功能都过了一遍。说实话，过程很枯燥，但效果出奇的好——我们找到了三个之前STPA没覆盖到的场景。其中一个就是「目标部分遮挡」的情况，后来成了我们测试用例的重点。
我的建议：HAZOP适合在系统设计早期使用。别想着一次做完，分模块、分功能、分阶段推进，效率更高。
2.2 STPA方法：系统论视角，专治「看不见的风险」
STPA，全称是System-Theoretic Process Analysis。这玩意儿跟HAZOP最大的区别在于：它不盯着「组件故障」，而是盯着「控制行为」。
你想想看，自动驾驶出事故，很多时候不是某个传感器坏了，而是控制器做出了错误的决策。比如，系统认为前方是安全区域，实际上那里有个施工围挡。这种风险，FMEA很难抓到，但STPA可以。
STPA的流程大致分四步：
- 定义系统边界和损失（比如：碰撞、偏离车道、违反交规）
- 建立控制结构图（谁控制谁？谁反馈给谁？）
- 识别不安全控制行为（UCA）
- 分析致因场景（为什么会发生UCA？）
我印象最深的一个案例，是在一个自动泊车项目中。我们用STPA分析「车辆在泊入过程中突然检测到行人」这个场景。控制结构图一画出来，发现感知模块和规划模块之间有个反馈延迟——感知已经检测到行人，但规划还在执行上一帧的轨迹。这个风险，如果用FMEA，根本不会想到去查「反馈延迟」这种系统级问题。
注意：STPA的学习曲线比较陡。我第一次用的时候，光画控制结构图就改了三版。建议新手先拿一个简单的功能（比如AEB）练手，别一上来就搞全系统。
2.3 FMEA方法：经典中的经典，但别滥用
FMEA，Failure Mode and Effects Analysis。这应该是大家最熟悉的工具了。它的逻辑很简单：列出每个组件的失效模式，分析它对系统的影响，然后打分。
但在预期功能安全里，FMEA有个天然的短板——它默认失效是「组件坏了」。而预期功能安全的风险，更多是「组件没坏，但表现不如预期」。比如，摄像头没坏，但在逆光下看不清；雷达没坏，但把路边的金属牌当成了障碍物。
所以我的做法是：把FMEA用在「硬件层面」，比如分析激光雷达的视场角受限、IMU的漂移、执行器的响应延迟。至于「算法误判」、「场景覆盖不全」这类问题，交给STPA和HAZOP。
FMEA的表格长这样：
| 组件 | 失效模式 | 失效原因 | 影响 | 严重度(S) | 发生度(O) | 探测度(D) | RPN |
|---|---|---|---|---|---|---|---|
| 摄像头 | 逆光下对比度下降 | 阳光角度低、无遮光罩 | 目标检测失效 | 8 | 6 | 4 | 192 |
| 毫米波雷达 | 多径反射 | 隧道内、护栏反射 | 虚假目标 | 7 | 5 | 5 | 175 |
我曾经在一个项目中，看到有人把FMEA做成了「填表游戏」——几百行表格，但真正有用的没几个。说白了，FMEA的价值不在于表格有多漂亮，而在于你愿不愿意去追问「然后呢？」。每个失效模式，至少要追问三层原因，才能找到根因。
2.4 FTA方法：自上而下，追根溯源
FTA，Fault Tree Analysis。这玩意儿跟FMEA正好相反——FMEA是自下而上（从组件到系统），FTA是自上而下（从顶事件到底层原因）。
我习惯在已经知道某个危险事件后，用FTA去追溯它的根本原因。比如，顶事件是「车辆在高速上误触发AEB」，那我们就往下拆：
- 是感知误报？（雷达误检？摄像头误检？融合算法出错？）
- 是决策错误？（阈值设置太低？场景分类错误？）
- 是执行器异常？（制动响应过快？）
FTA用逻辑门（与门、或门）把这些原因串起来。画出来之后，整个因果链一目了然。我特别喜欢FTA的一点是——它能帮你找到「最薄弱」的环节。比如，如果某个分支全是「与门」，那说明需要多个条件同时成立才会出事，风险相对低；如果某个分支全是「或门」，那任何一个条件成立就会出事，这就是需要重点防护的地方。
实战技巧：FTA和FMEA可以搭配使用。先用FTA从顶事件往下拆，拆到最底层的原因后，再用FMEA去分析这些底层原因的失效模式和应对措施。这样既不会漏，也不会重复。
2.5 风险矩阵：把定性分析变成定量决策
最后说说风险矩阵。这东西本身不是分析方法，而是评估工具。你把前面HAZOP、STPA、FMEA、FTA找到的风险，放到矩阵里，按「严重度」和「发生概率」打分，然后决定哪些风险需要处理，哪些可以接受。
一个典型的5×5风险矩阵：
| 严重度\概率 | 几乎不可能(1) | 很少(2) | 偶尔(3) | 可能(4) | 频繁(5) |
|---|---|---|---|---|---|
| 灾难性(5) | 高 | 高 | 极高 | 极高 | 极高 |
| 严重(4) | 中 | 高 | 高 | 极高 | 极高 |
| 中等(3) | 低 | 中 | 高 | 高 | 极高 |
| 轻微(2) | 低 | 低 | 中 | 高 | 高 |
| 可忽略(1) | 低 | 低 | 低 | 中 | 中 |
但这里有个坑——概率怎么定？ 预期功能安全不像传统安全，有现成的失效率数据库。你很难说「这个场景发生的概率是10^-6/h」。我的做法是：用场景频率代替概率。比如，这个场景在真实道路上每1000公里出现一次？还是每100万公里出现一次？结合OEM的测试数据、公开数据集、以及专家经验，综合判断。
我曾经在一个项目中，团队为了一个风险的概率争论了两天。后来我拍板说：「别争了，先按最坏情况处理，等有了实车数据再调整。」结果三个月后，实车数据证明我们的判断是对的。所以，风险矩阵不是一成不变的，它需要随着数据积累不断迭代。
2.6 五种方法的对比与选择
说了这么多，你可能想问：到底该用哪个？我的建议是——别单选，要组合。
下面这张SVG图，是我自己总结的「风险评估工具选择逻辑」：
简单总结一下我的选择逻辑：
- 设计早期，想全面覆盖 → HAZOP + STPA，一个查功能偏差，一个查控制行为，互补性极强。
- 已经知道某个危险事件，想追根溯源 → FTA，从顶事件往下拆，找到最薄弱的环节。
- 需要分析硬件组件的具体失效 → FMEA，但别滥用，只用在「组件层面」。
- 最后，所有风险都要进风险矩阵 → 定严重度、定概率、定优先级，然后决定是「接受」还是「处理」。
避坑指南：我曾经见过一个团队，把所有方法都用了一遍，结果文档写了300页，但真正落地的措施没几个。记住，工具是手段，不是目的。你的目标是找到风险、量化风险、然后消除或降低风险。别为了用工具而用工具。
好了，这一章的内容就到这里。五种方法，各有各的脾气。你只要记住：HAZOP查偏差，STPA查控制，FMEA查组件，FTA查因果，风险矩阵定优先级。把这五句话刻在脑子里，你的风险评估框架就不会跑偏。