4. SOTIF开发流程总览

HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？在什么场景下出问题？后果有多严重？

我刚开始接触 SOTIF 时，总觉得 HARA 就是走个过场。直到有一次，一个简单的车道保持功能，因为没分析到「车道线模糊 + 强逆光」的组合场景，差点在验收时翻车。嗯，从那以后，我对 HARA 再也不敢马虎了。

4.1 HARA 的核心方法

ISO 21448 里的 HARA，和功能安全 ISO 26262 的 HARA 思路很像，但侧重点不同。功能安全关注的是系统故障，而 SOTIF 关注的是功能不足和可预见误用。

我个人习惯把 HARA 分成四个步骤：

1. 功能定义：明确系统的预期功能及其边界。
2. 场景分析：找出所有可能触发危害的运行场景。
3. 危害识别：分析功能不足或误用会导致什么危害。
4. 风险等级评估：用 S、E、C 三个参数给风险定级。

下面这张图，是我自己总结的 HARA 流程框架，你可以对照着看：

4.2 场景分析：别漏掉「边缘场景」

场景分析是 HARA 里最花时间的环节。你想想看，一个自动驾驶系统可能遇到的场景几乎是无限的。但 ISO 21448 要求我们系统性地覆盖，而不是穷举。

我建议把场景拆成三个维度：

• 运行场景：天气、光照、道路类型、交通密度等。
• 自车行为：加速、减速、变道、转弯等。
• 交互对象：其他车辆、行人、自行车、动物、静态障碍物等。

场景分析的结果，通常用场景矩阵来记录。下面是一个简化的例子：

场景 ID	运行场景	自车行为	交互对象	潜在危害
S-001	夜间、小雨、城市道路	直行 50 km/h	横穿行人（深色衣服）	行人检测延迟或漏检
S-002	强逆光、隧道出口	加速出隧道	前方静止车辆	摄像头过曝，无法识别静止目标
S-003	高速公路、弯道	LCC 激活	车道线模糊/缺失	车道保持失效，偏离车道

4.3 危害识别：从「功能不足」到「危害」

危害识别，就是回答「如果这个功能在某个场景下表现不足，会导致什么后果？」

举个例子：

• 功能不足：摄像头在强逆光下无法检测到前方静止车辆。
• 危害事件：自车未减速，追尾前方车辆，导致乘员受伤。

这里要注意，危害识别要具体到可测量的后果。不要只说「碰撞」，要说「追尾碰撞，相对速度 50 km/h，可能导致乘员颈部受伤」。越具体，后续的风险评估越准确。

4.4 风险等级评估：S、E、C 三参数

ISO 21448 的风险等级评估，沿用了 ISO 26262 的 S、E、C 框架，但含义略有调整：

• S（Severity，严重度）：危害发生时，对人员伤害的严重程度。分 S0（无伤害）到 S3（致命伤害）。
• E（Exposure，暴露概率）：场景发生的概率。分 E0（几乎不可能）到 E4（非常高）。
• C（Controllability，可控性）：驾驶员或其他人员能否避免危害。分 C0（完全可控）到 C3（几乎不可控）。

三个参数组合，得到风险等级（ASIL 或 SOTIF 风险等级）。ISO 21448 没有强制要求用 ASIL，但很多企业会沿用 ASIL 的思维来定级。

下面是我常用的评估表：

参数	等级	描述	示例
S（严重度）	S0	无伤害	轻微制动，无碰撞
	S1	轻伤	低速追尾，轻微擦伤
	S2	重伤	中速碰撞，骨折
	S3	致命	高速碰撞，死亡
E（暴露概率）	E0	几乎不可能	车辆被陨石击中
	E1	非常低	每年一次
	E2	低	每月一次
	E3	中	每周一次
	E4	高	每天一次
C（可控性）	C0	完全可控	驾驶员可轻松接管
	C1	简单可控	驾驶员有足够时间反应
	C2	一般可控	驾驶员需要紧急干预
	C3	几乎不可控	驾驶员无法避免危害

4.5 我的 HARA 实战建议

最后，分享几个我在项目中踩过的坑和总结的经验：

• 场景分析要「广撒网，再收网」：先尽可能多地列出场景，再通过专家评审筛选出高优先级场景。不要一开始就想着精简。
• 危害识别要「追根究底」：每个功能不足，都要追问「然后呢？」，直到找到对人员伤害的最终后果。
• 风险等级要「保守但不夸张」：保守是为了安全，但过度夸张会导致开发成本失控。我个人习惯，在不确定时取中间值，然后通过测试数据来修正。
• HARA 是活的文档：随着系统迭代和新场景的出现，HARA 需要持续更新。不要做完就扔到一边。