4. 危害分析与风险评估(HARA)

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 三个参数给风险定级。

关键区别:ISO 26262 的 HARA 评估的是「故障导致的风险」,而 ISO 21448 的 HARA 评估的是「功能表现不足导致的风险」。两者不能混用,但可以互补。

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

HARA 核心流程框架图 HARA 核心流程框架 功能定义 场景分析 危害识别 风险等级评估 (S/E/C) HARA 报告 注意 SOTIF 的 HARA 关注 功能不足与可预见误用 而非硬件随机故障

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

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

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

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

我的经验:做场景分析时,一定要拉上系统工程师和测试工程师一起 brainstorm。一个人闭门造车,很容易漏掉那些「看似不可能」的边缘场景。我曾经就因为漏掉「隧道出口强光 + 前方静止车辆」的场景,导致 AEB 功能在实车测试时没触发,差点撞上目标车。

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

场景 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 几乎不可控 驾驶员无法避免危害

核心原则:S、E、C 的评估必须基于真实数据或合理假设。不要拍脑袋定级。如果缺乏数据,就做敏感性分析,看看不同假设对结果的影响有多大。

4.5 我的 HARA 实战建议

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

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

最后一句:HARA 做得好不好,直接决定了 SOTIF 开发的成败。花在 HARA 上的时间,永远不会浪费。