3. 相关标准与法规

好，咱们进入SOTIF实战里最核心的一步——危害分析与风险评估，也就是HARA。

传统功能安全的HARA大家可能都做过，但SOTIF里的HARA，侧重点完全不同。传统HARA盯着的是系统故障（比如硬件短路、软件跑飞），而SOTIF的HARA，盯的是功能不足和可预见的人为误用。

说白了，就是系统本身没坏，但它在某些场景下就是干不好活，或者驾驶员操作不当，导致了危险。我们得把这些情况揪出来。

3.1 SOTIF中HARA的独特视角

我个人习惯把SOTIF的HARA看作一场「场景-触发条件-危害」的三角博弈。你想想看，一个自动驾驶系统在高速上跑得好好的，突然遇到一个逆光的隧道出口（场景），摄像头瞬间过曝（触发条件），车辆没有减速（功能不足），结果撞上了隧道内的静止车辆（危害事件）。

这就是SOTIF要管的典型问题。系统硬件没坏，但感知能力在特定环境下失效了。

3.2 触发条件（TC）的识别——找「导火索」

触发条件，就是那个让系统功能不足暴露出来的「最后一根稻草」。我在项目中遇到过很多次，大家容易把触发条件和故障混为一谈。记住，触发条件不是系统坏了，而是系统能力被场景「碾压」了。

触发条件通常分为三大类：

• 环境条件：光照（逆光、隧道口、夜间无照明）、天气（雨、雪、雾、路面反光）、道路结构（急弯、无车道线、施工区域）。
• 系统自身局限：传感器视野遮挡、算法对特定目标的漏检（如异形车、行人穿深色衣服）、控制器的计算延迟。
• 用户行为：驾驶员过度依赖系统（玩手机）、误操作（误踩油门当刹车）、对系统能力边界不了解（在ODD外强行激活）。

3.3 危害事件（HE）的识别——定义「后果」

危害事件，就是触发条件被激活后，系统功能不足直接导致的人员伤亡或财产损失。注意，这里一定要描述到「人」或「物」的伤害。

比如：

• 「车辆在高速上因未识别静止障碍物，导致追尾，造成乘员受伤」——这是危害事件。
• 「车辆未识别静止障碍物」——这只是功能不足，不是危害事件。

我建议在识别HE时，直接套用这个公式：

危害事件 = [系统功能不足] + [具体场景] + [导致的具体伤害]

举个例子：

功能不足	场景	触发条件	危害事件
AEB未识别横穿行人	夜间城市道路	行人穿深色衣服，背景灯光复杂	车辆未制动，碰撞行人，导致行人重伤
LKA无法保持车道	雨天高速	车道线磨损 + 路面反光	车辆偏离车道，与相邻车道车辆碰撞，造成乘员受伤

3.4 HARA分析流程——五步走

在实际项目中，我一般把SOTIF的HARA拆成五步。每一步都要有记录，方便后续评审和追溯。

1. 场景定义：列出所有可能的运行场景（高速、城区、泊车、夜间、雨天等）。
2. 功能不足分析：针对每个场景，问自己「系统在这里可能哪里不行？」。比如，摄像头在逆光下可能失效，雷达在多目标下可能误报。
3. 触发条件识别：找到那个让功能不足「显形」的具体条件。比如，逆光角度在30°-60°之间，且隧道出口亮度差大于1000lux。
4. 危害事件推导：把功能不足 + 场景 + 触发条件组合起来，推导出具体的伤害后果。
5. 风险等级评估：评估危害事件的严重度（S）、暴露率（E）、可控性（C），确定ASIL等级或SOTIF风险等级。

3.5 知识结构图：HARA核心逻辑

下面这张图，是我自己总结的SOTIF HARA核心逻辑。它把场景、触发条件、功能不足和危害事件串在了一起。你把它印在脑子里，做分析时就不会跑偏。

3.6 实战中的几个关键点

最后，分享几个我在项目里踩过的坑，希望能帮你少走弯路。

• 别贪多：HARA分析不是一次性把所有场景都列完。我建议先聚焦已知不安全场景（Known Unsafe Scenarios），比如逆光、雨雾、施工区。先把这些硬骨头啃下来。
• 触发条件要量化：别写「光照不好」，要写「光照强度低于 1 lux」或「逆光角度大于 45°」。量化了，测试才能复现。
• 危害事件要具体到伤害：别写「车辆失控」，要写「车辆偏离车道，与对向车辆碰撞，导致驾驶员重伤」。这样后续评估严重度（S）时才有依据。
• 别忘了用户误用：我见过一个案例，驾驶员在系统激活状态下，故意把方向盘打到最大角度，结果系统没有及时退出，导致车辆失控。这种「可预见的误用」也要纳入HARA。