HARA — Hazard Analysis & Risk Assessment

功能安全L7别名 HARA · hazard analysis · risk assessment · 危害分析与风险评估 · 风险评估

本质 HARA 是 ISO 26262 概念阶段的起点——把"这个 item 出错可能伤人"这件模糊的工程直觉,变成可论证的安全目标(Safety Goal)+ ASIL 等级。一旦 HARA 错(漏识别一个 hazard、ASIL 评低一档),整条 FuSa 工作链(FSC → TSR → 硬件设计 → V&V)都建立在错误前提上,中后期改回来代价是数量级。HARA 不是写文档,是 3 步推理:① 罗列 item 在所有运行情境下的危险事件;② 对每个事件按 S(Severity)× E(Exposure)× C(Controllability) 三维评分;③ 查 ISO 26262 表 4 得到 ASIL。本页拆 HARA 的 3 步流程 + S/E/C 评分依据 + 经典 EPS / 主驱例子 + 5 个反模式。

学习目标

读完本页后,你应该能够:

  • 说出 HARA 在 ISO 26262 V 模型中的位置(概念阶段第 2 步,在 Item Definition 之后)
  • 走通 HARA 3 步流程:危险事件识别 → S/E/C 评分 → ASIL 查表
  • 区分 S0-S3 / E0-E4 / C0-C3 各级别的判定依据
  • 用 ISO 26262-3 表 4 把 (S, E, C) 映射到 ASIL (QM, A, B, C, D)
  • 写出安全目标(Safety Goal)的标准模板(避免 X 危险、给 FTTI、给 safe state)
  • 识别 5 个 HARA 反模式(漏情境、S 评低、E 评高、C 评乐观、不收敛)

1. HARA 在 V 模型里的位置

HARA 是 ISO 26262 概念阶段的第 2 步——前承 Item Definition(定义 item 是什么),后接 FSC(Functional Safety Concept,把 SG 拆成具体功能安全需求)。理解这个位置决定 HARA 输出对接什么。

Mermaid diagram
输入HARA 三步输出
Item Definition(系统功能 / 边界 / 接口 / 运行情境)危险识别 → S/E/C → ASILSafety Goals + ASIL + Safe State + FTTI

关键认知:HARA 不是从硬件起,是从功能 / 用户场景起——"司机踩油门但车不加速"是危险事件,不论这是软件 bug 还是 MOSFET 失效引起。HARA 的输出是功能层面的安全目标,不绑定实现。

2. 三步流程

HARA 走三个串行步骤——每步缺失或潦草都让最终 ASIL 不可信。下面分别展开。

Mermaid diagram
步动作关键输出
1 危险识别列出 item 在所有 driving situation 下可能产生的危险事件hazard 清单(20-100 条)
2 S/E/C 评分每个 hazard 按严重度 / 暴露率 / 可控性打 0-3 分三维评分表
3 ASIL 查表用 ISO 26262-3 Table 4 查 (S, E, C) → ASILhazard → ASIL 映射

3. 第 1 步:危险识别

危险识别走"驾驶情境 × 失效模式"二维笛卡尔积——任一组合都可能产生危险事件。漏一个组合 = 漏一个 hazard。

3.1 输入 / 输出

危险识别输入有 4 类——Item Definition 给定边界、driving situation 库给情境清单、历史 FMEA 给失效模式、跨职能脑暴补漏。这 4 类输入交叉才能产出完整 hazard 清单。

输入来自哪里
Item Definition上一步的输出
Driving SituationsSAE J2980 等列了 30+ 标准情境
已有 FMEA / 历史数据失效模式库
头脑风暴跨职能 review(系统 + 软件 + 硬件 + 测试)

输出:hazard 清单,每条至少含:

  • 危险事件描述:用户视角("车辆突然加速 / 转向失控 / 制动失败")
  • 触发条件:item 内部什么失效模式
  • 运行情境:发生在什么 driving situation

3.2 EPS 危险事件清单(部分)

EPS(Electric Power Steering)是最常被研究的 HARA 案例——下面 5 条是 ASIL D EPS 项目的标准 hazards。

#危险事件触发情境
H1自转向(unintended steering)控制环错误转矩高速直行
H2失去助力(loss of assist)系统断电 / 故障低速大角度转弯
H3转向过冲助力比例错误低速调头
H4卡滞(jam)机械 / 电气 stuck任意速度
H5反向助力(reverse assist)极性错高速变道

3.3 主驱(Traction Inverter)危险事件清单

主驱几个核心 hazards——每个对应 FTA 顶事件。

#危险事件触发情境
H1危险扭矩输出(unintended torque)控制链算错 / 误转向静止 / 低速
H2失去扭矩(loss of propulsion)关键器件失效高速过弯
H3加速 stuck油门信号 stuck任意
H4异常制动(unintended regen)再生制动失控高速
H5高压暴露HVIL / 绝缘失效维修 / 事故

4. 第 2 步:S / E / C 评分

每个 hazard 三维评分——S(Severity 严重度) × E(Exposure 暴露率) × C(Controllability 可控性)。每维 0-3 分(S 例外,从 S0 = 无伤害到 S3 = 致命)。

4.1 Severity(S0-S3)

S 是伤害严重度——衡量 hazard 真正发生时,人受伤多严重。

级别含义例
S0无伤害仪表显示乱码
S1轻伤(可恢复)低速擦碰挫伤
S2中重伤(可能后遗症)中速碰撞骨折
S3致命或严重不可逆伤害高速失控、高压触电

关键判定原则:S 评的是最严重可信场景,不是平均场景——高速失控可能擦边过去,但可信(reasonable)的最坏后果是致命,所以 S3。

4.2 Exposure(E0-E4)

E 是司机 / 用户处于该危险情境的概率——衡量"这种危险什么时候发生"出现频率。

级别含义量化区间
E0不发生不可能在该情境运行
E1极低< 1% 运行时间
E2低1-10% 运行时间
E3中10-50% 运行时间
E4高> 50% 运行时间

例: 高速直行 E4(大量时间)、高速过弯 E3、停车泊车 E2、维修工况 E1。

4.3 Controllability(C0-C3)

C 是司机 / 用户能否在 hazard 发生后避免伤害——衡量"通常能不能 escape"。

级别含义判定
C0通常可控> 99% 司机能避险
C1简单可控90-99% 司机能避险
C2中等可控困难但有经验司机能避险
C3难以控制 / 不可控< 90% 司机能避险

例:高速失控 C3(几乎无法救)、低速 stuck C1(简单松油门)、轻微转向偏差 C0(司机自然修正)。

4.4 评分协作

S/E/C 评分必须由跨职能 team 共同 review——单一职能(尤其 Hardware engineer 单独)容易评偏。建议:

  • System engineer 主持,定义 driving situation
  • Software engineer 评失效行为
  • Hardware engineer 评失效模式
  • Test engineer 评 Controllability(实测过类似场景)
  • OEM 代表 复核,因为 OEM 有更多车队数据

5. 第 3 步:ASIL 查表

S/E/C 三维 → ASIL 不是公式,是 ISO 26262-3 Table 4 的查表——下面是简化版。

5.1 ASIL 查表

完整查表 ISO 26262-3 Table 4。下面是高频组合的简化:

SECASIL
S3E4C3ASIL D(最严)
S3E4C2ASIL C
S3E3C3ASIL C
S3E3C2ASIL B
S2E4C3ASIL C
S2E3C2ASIL A
S1E4C3ASIL A
S1E3C3QM(质量管理即可)
S0**QM
*E0*QM
**C0QM(部分情况)

5.2 一维下降的代价

理解"为什么 S/E/C 错评一档代价那么大"——三维任一下降一级,ASIL 都可能下降一档(D → C → B → A → QM)。

反向也成立:漏识别一个 hazard 等于把它当 QM,到中后期发现实际是 ASIL D,整个 FSC 推倒重来——这是 HARA 错误的最大代价。

6. 输出:Safety Goal

Safety Goal(SG)是 HARA 的最终交付物——每个 ASIL ≥ A 的 hazard 对应1 个 SG。SG 描述"避免什么危险 + 安全状态是什么 + 反应时间约束(FTTI)"。

6.1 SG 标准模板

Safety Goal 必须包含 4 个元素——避免危险描述、ASIL、Safe State、FTTI。任何 1 个缺失都让后续 FSC 无法落地。

元素内容例(EPS H1)
避免危险简短描述避免自转向(unintended steering)
ASILHARA 输出ASIL D
Safe State失效后的安全状态切换至机械备份(无助力)
FTTI失效到 safe state 的最大允许时间100 ms

6.2 EPS 实例 SG

SG-1:The EPS shall not provide unintended steering torque exceeding ±0.5 Nm.

  • ASIL: D
  • Safe State: Mechanical fallback (no electric assist)
  • FTTI: 100 ms

6.3 主驱实例 SG

SG-1:The traction inverter shall not produce unintended torque exceeding ±20 Nm at the wheels in any drive condition.

  • ASIL: D
  • Safe State: Active Short Circuit (ASC) or Free-wheeling (depending on vehicle speed)
  • FTTI: 50 ms

7. FTTI 的物理意义

FTTI(Fault Tolerant Time Interval)是 HARA 给硬件设计的最强约束——比 ASIL 等级更直接。它定义"从故障发生到必须进 safe state 的最长时间",这个时间在硬件层面分成三段:

Mermaid diagram
段含义典型值(EPS / 主驱)
fault → detect检测时间(SM 反应)1-10 ms
detect → reaction决策 + 触发响应1-5 ms
reaction → safe state物理动作完成(STO 关栅、ASC 启动)5-50 ms
total FTTI必须 ≤ HARA 给的窗50-100 ms

关键约束:SM 反应慢于 FTTI 就废了——用纯软件 SM(100 ms 反应)在 FTTI = 50 ms 的项目里完全没用,必须硬件 SM(< 5 ms)。

8. 5 个 HARA 反模式

HARA 失败集中在 5 个反模式——这 5 个让 ASIL 评估"看起来合理"但实际有系统性盲区。

反模式表现修法
漏识别情境只考虑高速直行,漏掉变道 / 倒车 / 雨天 / 维修工况用 SAE J2980 标准情境清单逐个核对
S 评低把"严重失控"评 S2 因为"大多数情况擦边"S 评的是最严重可信场景,不是平均
E 评高(把 ASIL 拉上去)给 stable 工况 E4,实际只 E2用车队数据 / 真实运行 profile 校核
C 评乐观假设司机能反应,实际 100 ms 内根本反应不了实测!或参考 ADAS UI 测试数据
HARA 不收敛反复 review 改评分,数月不出 ASIL设 tighter timebox,有争议挂 issue 走 OEM 仲裁

8.1 S 评低的隐蔽危险

最常见也最危险的反模式:工程师对自己设计有信心,觉得"实际不会那么严重",把 S 评低 → ASIL 评低 → 后续 SM 投入不足 → 真实失效场景下确实出事。修法:S 评严重度,不评概率(那是 E 的工作)。

8.2 HARA 不收敛的隐蔽成本

HARA 是工程协作活动,容易被无穷无尽的"corner case"卷入。设 timebox(如 4 周)+ 仲裁机制(OEM 决断分歧)是必须的。否则整个 FuSa 项目卡在概念阶段。

核心要点
  • HARA 是 ISO 26262 概念阶段第 2 步——Item Definition 之后,FSC 之前;输入功能 / 边界 / 情境,输出 SG + ASIL + FTTI
  • 走 3 步流程:危险识别(笛卡尔积情境 × 失效) → S/E/C 评分 → Table 4 查 ASIL
  • S(0-3)严重度 / E(0-4)暴露率 / C(0-3)可控性 —— 三维必须跨职能 team 共评,单职能容易偏
  • ASIL 查表:S3+E4+C3 = ASIL D,任一下降一级都可能让 ASIL 降一档
  • 漏识别 hazard 等于评 QM,但实际可能是 ASIL D —— 最贵的错误
  • Safety Goal 标准模板:避免危险 + ASIL + Safe State + FTTI
  • FTTI 决定 SM 选型——< 50 ms 的 FTTI 让纯软件 SM 完全没用
  • 5 反模式戒除:漏情境 / S 评低 / E 评高 / C 评乐观 / 不收敛

Cross-references