4. 危险事件识别：触发条件、可控性、危害分析与风险评估（HARA）
好，咱们进入SOTIF分析里最核心的一步——HARA。全称是Hazard Analysis and Risk Assessment，危害分析与风险评估。说白了，就是回答三个问题：哪里会出问题？后果多严重？我们能不能兜住？
我在做L3级高速领航项目时，第一次完整跑完HARA，发现之前漏掉的场景比想象中多得多。嗯，这步走扎实了，后面的功能设计和测试才不至于翻车。
4.1 触发条件：什么情况下危险会冒出来？
触发条件，就是导致系统进入危险状态的导火索。它分两类：
- 系统内部触发：传感器噪声、算法误判、执行器延迟、通信丢包
- 环境外部触发：光照突变、雨雪遮挡、路面标线模糊、施工区域、动物横穿
你想想看，一个AEB系统在晴天干路表现完美，但到了隧道出口逆光场景，摄像头瞬间过曝，目标丢失——这就是典型的环境触发条件。
关键原则：触发条件必须可观测、可复现、可测试。不能写“偶尔出现异常”，要写“当光照强度从10000 lux骤降至200 lux且持续超过200ms时”。
我个人习惯把触发条件整理成一张清单表，方便后续场景库构建：
| 触发类别 | 典型示例 | 影响系统 |
|---|---|---|
| 环境光照 | 逆光、隧道出入口、夜间无路灯 | 视觉感知 |
| 天气条件 | 大雨、大雾、积雪覆盖车道线 | 感知+定位 |
| 道路结构 | 急弯、无保护左转、匝道合流 | 规划+控制 |
| 目标特性 | 异形车、行人撑伞、动物突然横穿 | 感知+预测 |
| 系统退化 | 传感器脏污、算力过载、定位精度下降 | 全系统 |
4.2 可控性：驾驶员能不能救回来？
可控性，英文叫Controllability，评级从C0到C3。它衡量的是：当危险事件发生时，驾驶员（或者远程监控员）有没有能力避免事故。
- C0：完全可控，驾驶员轻松应对
- C1：简单可控，需要一点反应时间
- C2：一般可控，需要熟练操作
- C3：难以控制，事故几乎无法避免
我曾经在一个项目中，把某个场景的可控性评成了C1，结果测试时发现驾驶员只有不到0.8秒的反应窗口——这明显应该是C2甚至C3。嗯，这里要注意：可控性评估不能只看理论，一定要结合人因实验数据。
避坑指南：我曾经见过团队把“驾驶员注意力分散”作为降低可控性评级的理由，这是不对的。SOTIF的可控性假设驾驶员处于正常驾驶状态，不是分心状态。分心属于功能安全或使用场景偏差，别混在一起。
4.3 危害分析与风险评估（HARA）完整流程
HARA不是一步到位的，它是个迭代过程。我一般按下面几步走：
- 定义功能场景：明确ODD、系统功能、人机交互方式
- 识别危害事件：结合触发条件，列出所有可能的危险行为
- 评估严重度（S）：对人员伤害的严重程度，S0~S3
- 评估暴露率（E）：该场景在真实运行中出现的概率，E0~E4
- 评估可控性（C）：如上所述，C0~C3
- 计算ASIL等级：查ISO 26262的ASIL矩阵，得到QM / ASIL A/B/C/D
- 确定安全目标：每个ASIL B以上的危害事件，都要写对应的安全目标
举个例子，我做过一个自动变道功能的HARA：
| 危害事件 | 触发条件 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|
| 变道时与相邻车道车辆碰撞 | 盲区目标被遮挡，传感器未检测到 | 3 | 3 | 2 | B | 系统必须在变道前确认目标车道无碰撞风险 |
| 变道中目标突然加速 | 后车加速行为超出预测模型范围 | 3 | 2 | 2 | A | 系统必须实时监控目标相对速度，预留安全距离 |
| 变道过程中车道线消失 | 路面标线磨损或施工覆盖 | 2 | 3 | 1 | QM | 系统应检测车道线置信度，低于阈值时退出变道 |
个人经验：我建议HARA文档里每个危害事件都附一段场景描述，包括道路类型、天气、目标运动状态、系统响应时间线。这样后续做测试用例时，直接就能映射到具体场景，不用重新脑补。
4.4 HARA与SOTIF的衔接
传统功能安全的HARA主要针对系统故障，比如传感器坏了、软件跑飞了。但SOTIF的HARA要覆盖功能不足和性能局限——也就是系统本身没坏，但能力不够。
举个例子：
- 功能安全HARA：摄像头信号丢失 → 导致AEB不触发 → ASIL C
- SOTIF HARA：摄像头被强光致盲，但信号正常 → 导致AEB不触发 → 同样需要分析
你看，同样的后果，触发条件不同，对应的安全措施也不同。功能安全靠冗余和诊断，SOTIF靠场景覆盖和算法鲁棒性。
下面这张图展示了HARA在SOTIF开发中的位置：
4.5 实操中的几个坑
最后，分享几个我在项目里踩过的坑：
- 别漏了“正常功能下的异常场景”：比如ACC正常跟车，但前车突然急刹——这不是系统故障，是场景突变，但HARA必须覆盖。
- 可控性别拍脑袋：我建议至少做一轮驾驶员在环测试，拿真实反应时间数据说话。纸上谈兵容易评低。
- 安全目标要可验证：别写“系统应足够安全”，要写“系统在目标车道有车且相对速度大于5m/s时，不得执行变道”。
- HARA文档要活：随着场景库扩充和算法迭代，HARA要持续更新。我见过最惨的项目，HARA写完就锁柜子，结果测试发现一堆新场景，全得返工。
一句话总结：HARA不是交作业用的文档，它是你设计安全系统的导航地图。地图画得越细，后面走弯路就越少。