4. 危害与风险分析：从“可能出事”到“到底多严重”
好，咱们进入SOTIF最核心的一步——危害与风险分析。
前面几章我们聊了场景、聊了功能，但说到底，工程师最关心的是：这车到底会不会出事？出事了有多严重？
我个人习惯把这一步叫做“算账”。算清楚哪些情况可能伤人，伤人的概率多大，我们能不能接受。算明白了，后续的测试验证才有方向。
4.1 危害识别：先找到“敌人”在哪
危害识别，说白了就是问一个问题：系统在什么情况下，会对人造成伤害？
注意，这里说的“危害”不是故障。故障是系统坏了（比如传感器掉线），危害是系统没坏但行为不安全（比如该刹车没刹）。SOTIF主要管后者。
核心区别：
- 功能安全（ISO 26262）： 系统故障导致的危害（硬件随机失效、系统故障）
- SOTIF（ISO 21448）： 系统性能局限或可预见误用导致的危害（没故障，但就是不行）
我在项目里见过一个典型例子：某款车的AEB系统，在晴天测试一切正常。但到了雨天，摄像头被泥水遮挡，系统没报故障（硬件没坏），但就是识别不到前方静止车辆。结果追尾了。这就是SOTIF的危害——系统没坏，但能力不够。
危害识别通常从这几个角度入手：
- 功能行为异常： 该加速时减速、该转向时不转
- 功能性能不足： 识别距离不够、响应太慢、精度太低
- 功能边界模糊： 系统在边缘场景下行为不确定（比如车道线模糊时，系统左右摇摆）
- 人机交互误导： 系统给了驾驶员错误的信息或提示
4.2 风险评价方法：给危害“打分”
找到危害之后，不能眉毛胡子一把抓。得给每个危害排个优先级——哪些要立刻解决，哪些可以缓缓。
SOTIF里常用的评价方法，我个人觉得跟功能安全很像，但侧重点不同。核心看三个维度：
| 维度 | 含义 | 典型问题 |
|---|---|---|
| 严重度（Severity） | 伤害的严重程度 | 会死人吗？还是只擦破皮？ |
| 可控性（Controllability） | 驾驶员或周围人能否避免伤害 | 普通人能反应过来吗？还是根本来不及？ |
| 暴露率（Exposure） | 触发事件发生的概率 | 这种情况一年遇到一次？还是每天遇到？ |
你想想看，一个危害如果严重度是“死亡级”，但可控性很高（驾驶员轻松避开），暴露率极低（百年一遇），那它的风险其实不高。反过来，一个危害虽然只是“轻伤”，但每天都会触发，驾驶员完全控制不了，那风险反而更大。
我的经验： 很多团队容易犯一个错——只盯着严重度。觉得“会死人”就是最高风险。但实际项目中，那些“中严重度、高暴露率、低可控性”的危害，往往才是事故的主要来源。比如城市道路中，AEB对“鬼探头”的误触发——虽然不会死人，但每天触发几次，驾驶员每次都吓一跳，早晚出事故。
4.3 触发事件（Triggering Events）：危害的“导火索”
危害是结果，那原因是什么？SOTIF里叫触发事件。
触发事件就是那个“导火索”——它让系统从正常状态，变成了不安全状态。
我习惯把触发事件分成三类：
- 环境因素： 天气（雨、雪、雾）、光照（逆光、夜晚）、道路（施工、急弯）、交通参与者（行人突然冲出）
- 系统自身局限： 传感器感知范围有限、算法对特定场景识别率低、计算资源不足导致延迟
- 可预见的用户误用： 驾驶员过度依赖系统（比如玩手机）、错误操作（比如强行接管）、不按说明使用
举个例子：
- 危害： 车辆在高速上未识别到静止的故障车，导致追尾
- 触发事件： 傍晚逆光（环境因素）+ 摄像头动态范围不足（系统局限）+ 驾驶员正在看导航（用户误用）
你看，一个危害往往不是单一原因造成的，而是多个触发事件叠加的结果。这也是SOTIF分析最头疼的地方——组合爆炸。场景千千万，触发事件组合起来更是天文数字。
避坑指南： 我曾经在一个项目里，团队花了两个月列触发事件清单，列了上千条。结果发现大部分根本不会发生，或者发生了也没影响。后来我改了方法：先找危害，再反向推导触发事件。效率高很多。记住，触发事件是为危害服务的，别为了列而列。
4.4 严重度与可控性：两个最难评的维度
严重度和可控性，是风险评价里最主观、也最容易吵架的两个维度。
严重度怎么评？
SOTIF没有像功能安全那样给出明确的S1/S2/S3分级表。但实践中，大家基本沿用功能安全的思路：
- S0： 无伤害
- S1： 轻伤（比如擦伤、扭伤）
- S2： 重伤（比如骨折、内出血）
- S3： 致命伤
但要注意，SOTIF里严重度要考虑二次伤害。比如系统误刹车导致后车追尾，直接伤害是追尾的碰撞，但间接伤害可能是车辆翻滚、起火。我一般建议团队把“最坏情况”作为严重度基准。
可控性怎么评？
可控性更难。它问的是：普通人（不是专业车手）在那种情况下，能不能避免伤害？
我常用的判断标准：
- C0： 完全可控（驾驶员有足够时间反应）
- C1： 简单可控（需要一点反应，但大多数人都能做到）
- C2： 一般可控（需要一定技巧，部分人做不到）
- C3： 难以控制（几乎没人能避免）
嗯，这里要注意：可控性不是看“系统能不能控制”，而是看“人能不能控制”。很多团队搞混了，把系统自身的控制能力算进去，那就不对了。
4.5 知识结构图：危害与风险分析全景
下面这张图，是我自己总结的SOTIF危害与风险分析流程。每次做项目，我都会贴在白板上。
这张图的核心逻辑是：先找危害，再找触发事件，然后评价风险，最后决定怎么降风险。 每一步都环环相扣。
4.6 小结：别让分析变成“纸上谈兵”
危害与风险分析，听起来很理论，但做起来全是实战。
我见过太多团队，花几个月写出一本厚厚的HARA报告，结果项目后期发现，实际路试中暴露的问题，报告里根本没提到。为什么？因为分析的时候太“理想化”了——只考虑了单一故障、单一场景，没考虑真实世界的复杂性。
所以我的建议是：分析要“粗”一点，验证要“细”一点。 先快速识别出最可能出事的几个危害，然后立刻去跑场景、做测试。发现问题再回来补分析。迭代着来，比一次性做完要靠谱得多。