HARA — Hazard Analysis & Risk Assessment

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

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

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

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

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

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

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

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

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

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

ISO 26262 HARA 是最常用但不是唯一的危害分析方法。SAE J3187 推荐的 STPA-PHA、ISO 21448 SOTIF 各有侧重,三者并行覆盖不同范围。

实战搭配:

• ICE 主驱 / EPS 项目:HARA 主导,STPA-PHA / SOTIF 选做
• L2 ADAS(自适应巡航 / 车道保持):HARA + SOTIF 并行
• L3+ AD(高速领航 / 城市领航):HARA + STPA-PHA + SOTIF 三者必做
• AI 感知模块:SOTIF 主导(感知误判属"无故障出事"),HARA 配做 E/E 层

三者的输出关系:STPA-PHA 的 UCA 可以反向滋养 HARA 的 hazard 清单;SOTIF 的 trigger condition 给 HARA 提供新的 operational situation 类。好的项目把三者输出统一管理,而不是分三套独立 DB。

HARA 第 1 步危险识别 = Hazard × Operational Situation 笛卡尔积。OS 不全则 hazard 漏识别——这是上节 §8 反模式"漏识别情境"的根因。

OS 必含 6 大类:道路类型 / 工况 / 天气能见度 / 路面附着 / 交通密度 / 车辆状态。每类有多子项,笛卡尔积组合数指数爆炸(6 类 × 4 子项 = 4^6 = 4096 组合)——所以 OEM 给一个 100-200 条预筛选 list,只跑真实可能发生的组合。

OS 与评分的对应:

• 道路类型 → E 评分主轴:高速 = E4 / 城市 = E3 / 山路 = E2 / 停车场 = E1
• 工况 → S 评分主轴:120 km/h 巡航 = S3 / 60 km/h 变道 = S2 / 倒车 = S1
• 天气 → C 评分修正:雾天 / 夜间降 C 一级(降低可控性)
• 路面 → 后果严重度修正:冰面 μ=0.1 → controllability 下降
• 交通密度 → controllability:拥堵下司机反应窗口更短
• 车辆状态 → actuator 响应:满载 + 高 SoC → 扭矩响应不一样

Item Def 必须文档化 OS 全集,SC 引用 — 不然 HARA 范围被审计员判模糊。

HE(Hazardous Event)= (Hazard × OS) 笛卡尔积的每个有效格子。HARA 表格的本质就是这张矩阵。

关键 5 条规则:

• 同一 Hazard 在不同 OS 下 ASIL 可不同:意外加速 + 高速 = ASIL D,意外加速 + 停车场 = ASIL A,源于 S/E/C 各不一样
• n/a 格也要写入表:不能简单留空——审计员问"你考虑过 X Hazard 在 Y OS 下吗?",答 "n/a 因为 Z" 是合规的,空白是 NC
• QM 行也必写入:作为 SC evidence("我们考虑过该 HE,判 QM,处理在 quality 流程")
• 最高 ASIL HE 决定 item ASIL:主驱表里 ASIL D HE → 整个 item ASIL D
• 每行有唯一 HE ID:Safety Case GSN 树用 ID 反向追溯

S/E/C 评分实战陷阱:

• S 评严重度,不评概率——S3 不是"经常出严重事故",是"如果出事最严重可能是致命"
• E 用车队真实数据——不要拍脑袋,要用 OEM 提供的实际运行 mile profile
• C 用 ADAS UI 实测——不要假设"司机能反应",要看实际 reaction time 数据
• 三人独立打分 → 投票——单人评最易偏,跨职能 review 必须

HARA 表格每行完整字段:ID / Hazard / OS / Effect / S / E / C / ASIL / Safety Goal。下图是主驱节选(实际 60-100 行)。

观察:

• HE-1 / HE-7 同样 S3 E4 C3 → ASIL D:意外加速和反向扭矩在高速直行下后果都致命,且 controllability 差
• HE-10 在高速 = ASIL C / HE-12 在停车场 = QM:同一 Hazard(3 相短路)在不同 OS 下 ASIL 跨 4 档
• 每个 HE → 1 个 SG:SG-1 防意外扭矩 / SG-2 防反向扭矩 / SG-3 防 HV 短路
• FTTI 跟 hazard 严重度反向:反向扭矩 50 ms,HV 短路 10 ms(因为短路一旦发生,energy release 极快)

HARA 字段扩展(实务):每行还有 owner / status / verification method / verified date,DOORS / Polarion 维护。

HARA 不是"M3 写完归档"。Living document——随项目演进多次更新。

4 级 review 节奏:

• M3 — 初版 review:Item Def 完成,Safety Engineer + Sys Lead + Functional Mgr 联评
• M6 — 半 stable review:FSC 完成后回审 HARA,补 corner case
• M9-M12 — 设计 review:HW/SW 设计阶段发现新 hazard → 触发 HARA 更新
• M15-M17 — Final review:Sa.Val 阶段实测数据回写 E / C 评分

触发 HARA 重审的 5 类事件:

• 系统功能变更(增 / 删 / 改 function)
• 工况范围扩展(新国家上市 / 新车型 derivative)
• 现场 feedback(已上市车型出现新 hazard)
• 法规变更(UN R157 / GB 18384 等更新)
• Sa.Val 阶段发现假设不成立

HARA 与 SC 的同步:任何 HARA 更新 → SG 列表可能变 → Safety Case GSN 树相应分支重写。好项目把 HARA 与 SC 用同一 ID 体系串起来,改 HARA 的 HE-X 自动触发 SC 检查 SG-X 对应分支。

• case · case_sg2_reverse_torque_asil_d — SG2 — 避免反向扭矩 (ASIL D)
• standard · standard_iso26262_part3_hara — ISO 26262-3 (2018) 概念阶段 / HARA