2. 危害分析与风险评估(HARA):运行场景定义、危害识别、危害分类与严重度评估

好,咱们进入正题。HARA,全称 Hazard Analysis and Risk Assessment,中文叫危害分析与风险评估。这是功能安全开发的起点,也是决定你后续所有工作方向的关键一步。

说白了,HARA 就是要回答三个问题:系统在什么情况下会出问题?出问题后会带来多严重的后果?我们该用多高的安全等级去应对?

我个人习惯把 HARA 分成四个核心步骤来走:运行场景定义 → 危害识别 → 危害分类 → 严重度评估。每一步都有坑,咱们一个一个说。

核心要点:HARA 的输出是安全目标(Safety Goal)和对应的 ASIL 等级。安全目标就是“系统不能做什么”,比如“转向系统不能非预期输出扭矩”。ASIL 等级则决定了后续开发中你需要投入多少精力去证明这个目标被满足了。

2.1 运行场景定义:你得知道车在哪儿开

运行场景,就是车辆可能处于的所有工作状态和环境条件的组合。你想想看,一辆车在高速上巡航,和在市区里走走停停,出问题后的后果能一样吗?

定义场景时,我建议从三个维度去切:

  • 车辆状态:行驶、静止、泊车、充电、维修模式等。
  • 环境条件:白天/黑夜、晴天/雨雪/大雾、干燥/湿滑路面、隧道/开阔地等。
  • 人为因素:驾驶员是否在监控、是否在操作、是否分心等。

举个例子,一个电动助力转向系统(EPS),它的运行场景至少包括:

场景编号 车辆状态 环境条件 人为因素
S-01 高速行驶(100 km/h) 白天,干燥路面 驾驶员主动操控
S-02 低速泊车(5 km/h) 夜间,停车场 驾驶员主动操控
S-03 静止,发动机运转 任何环境 驾驶员未操作
S-04 高速行驶(100 km/h) 雨天,湿滑路面 驾驶员分心

我的经验:场景定义不要贪多,但关键场景一个都不能漏。我曾经在一个项目中,团队只定义了“正常行驶”场景,结果忽略了“车辆在举升机上维修”的场景。后来在维修模式下,系统误触发了一个功能,差点造成安全事故。从那以后,我每次都会专门拉一个“非预期使用”的场景清单。

2.2 危害识别:找出系统可能犯的错

场景定义好了,接下来就是找危害。危害,就是系统功能异常或失效后,可能对人员造成的伤害。

危害识别通常从功能失效入手。一个功能可能以哪些方式失效?ISO 26262 给出了常见的失效模式:

  • 功能丧失:该干活的时候不干活。比如刹车踩下去没反应。
  • 非预期功能:不该干活的时候乱干活。比如没踩油门,车自己加速。
  • 功能错误:干活了但干错了。比如转向角度输出错误。
  • 功能延迟:干活了但太晚了。比如碰撞预警晚了一秒才报警。

拿前面说的 EPS 系统举例,我们识别出几个典型危害:

危害编号 失效模式 危害描述 关联场景
H-01 非预期转向 系统无驾驶员输入时,自行输出转向扭矩 S-01, S-04
H-02 转向助力丧失 系统完全失去助力,方向盘变得极重 S-01, S-02
H-03 转向反向助力 系统输出与驾驶员意图相反的转向扭矩 S-01, S-04

注意:危害识别时,不要只盯着“最坏情况”。有些看似轻微的失效,在特定场景下可能引发连锁反应。比如“转向助力丧失”在高速上可能只是让驾驶员费力,但在泊车场景下,驾驶员可能因为突然变重的方向盘而失去对车辆的控制。

2.3 危害分类与严重度评估:给危害定个级

危害找到了,接下来就是评估它的严重程度。ISO 26262 用三个参数来给危害定级:严重度(Severity, S)、暴露概率(Exposure, E)、可控性(Controllability, C)。三个参数组合起来,就得到了 ASIL 等级(A、B、C、D,或者 QM)。

咱们一个一个说。

2.3.1 严重度(S)

严重度评估的是危害发生后,对人员可能造成的伤害程度。分为四个等级:

  • S0:无伤害。
  • S1:轻伤,比如擦伤、轻微扭伤。
  • S2:重伤,可能危及生命但能存活,比如骨折、内出血。
  • S3:致命伤,直接威胁生命,比如颅脑损伤、大出血。

2.3.2 暴露概率(E)

暴露概率评估的是,车辆在可能触发该危害的场景下运行的频率。分为四个等级:

  • E0:几乎不可能发生。
  • E1:很少发生,比如每年几次。
  • E2:偶尔发生,比如每月几次。
  • E3:经常发生,比如每次驾驶都会遇到。
  • E4:持续发生,比如车辆启动后就一直处于该场景。

2.3.3 可控性(C)

可控性评估的是,当危害发生时,驾驶员或其他人员能否通过及时反应来避免伤害。分为三个等级:

  • C0:完全可控,驾驶员可以轻松应对。
  • C1:简单可控,大多数驾驶员可以应对,但需要一定反应时间。
  • C2:一般可控,部分驾驶员可能无法应对,需要特殊技巧或运气。
  • C3:难以控制,即使经验丰富的驾驶员也很难避免伤害。

2.4 ASIL 等级确定:组合拳

有了 S、E、C 的评估结果,就可以查表确定 ASIL 等级了。ISO 26262 给出了一个标准的组合矩阵:

S E C1 C2 C3
S1 E1 QM QM QM
E2 QM QM ASIL A
E3 QM ASIL A ASIL B
E4 ASIL A ASIL B ASIL C
S2 E1 QM QM ASIL A
E2 QM ASIL A ASIL B
E3 ASIL A ASIL B ASIL C
E4 ASIL B ASIL C ASIL D
S3 E1 QM ASIL A ASIL B
E2 ASIL A ASIL B ASIL C
E3 ASIL B ASIL C ASIL D
E4 ASIL C ASIL D ASIL D

举个例子,咱们前面识别的 EPS 危害 H-01(非预期转向):

  • S:非预期转向可能导致车辆偏离车道,与对向车辆或障碍物碰撞,造成重伤甚至死亡。我评估为 S3。
  • E:这个危害在高速行驶场景下发生,而高速行驶是每次驾驶都会遇到的。我评估为 E4。
  • C:非预期转向发生时,驾驶员需要立刻反向打方向盘并修正车身姿态。对于大多数驾驶员来说,这很难在瞬间完成。我评估为 C3。

查表:S3 + E4 + C3 = ASIL D。嗯,最高等级,意味着后续开发中,这个功能需要最严格的安全措施来保证。

避坑指南:我曾经在一个项目中,团队对“可控性”的评估过于乐观。他们认为“驾驶员总能反应过来”,结果把 C3 评成了 C2,导致 ASIL 等级降了一级。后来在实车测试中,发现驾驶员根本来不及反应。所以,评估可控性时,一定要假设驾驶员是普通人,不是赛车手。

2.5 HARA 流程总结

好了,咱们把整个 HARA 流程串起来。下面这张图是我自己画的,能帮你快速理解整个逻辑:

HARA 核心流程 1. 运行场景定义 车辆状态 + 环境 + 人为 2. 危害识别 功能失效模式分析 3. 危害分类 S / E / C 评估 4. ASIL 等级确定 查表组合 S/E/C 5. 安全目标 系统级安全要求 关键说明: • 场景定义是基础,场景漏了,后续全白做。 • S/E/C 评估要基于真实数据,不要拍脑袋。 • ASIL 等级决定了开发成本,等级越高,要求越严。

嗯,到这里,HARA 的核心内容就讲完了。记住,HARA 不是一次性的工作。随着系统设计的深入,你可能会发现新的场景或新的危害,需要回头更新 HARA。它是一个迭代的过程。

最后提醒:HARA 文档是功能安全审计的重点。每个评估结论都要有依据,不能只写“我认为”。我建议你在文档中引用场景数据、事故统计、仿真结果等客观证据。这样审计老师问起来,你也能有理有据。