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 就废了——以 EPS 为例:纯软件 SM(100 ms 反应)在 FTTI = 50 ms 的 EPS 项目里完全没用,必须硬件 SM(< 5 ms)。主驱 SG-1(FTTI = 200 ms)理论上允许纯软件 SM,但 100kW EV 逆变器实务仍选硬件 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 严重度反向:反向扭矩 200 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 对应分支。

HARA 最难教的部分是「S/E/C 三个维度各自的认知边界」——E 是工况频率不是故障频率、S 评最严可信后果不是平均后果、C 评司机/用户逃逸能力不是系统设计预期。本节用一台真实的 22kW 双向 OBC(V2G 能力、单相/三相、输入 AC 220/380V、输出 DC 350–800V、接 BEV 高压电池包)走一遍完整 HARA,在每个 HE 上逐维给出「为什么这么打分」——这比只看分数表更重要。

HARA 的 gotcha 与开关电源的不同——大多数错误在评审流程和概念混淆层,而非公式推导层。以下 7 条是从真实 OEM/Tier1 项目中归纳的高频错误链。

Gotcha-1: S 评「设计可信度」而非「物理后果」。工程师对自己的设计有信心,会把 S 评低:「我们的 HV 继电器双冗余,焊死概率极低,所以 S2 够了」。根本错误:S 评的是危险事件真实发生时的后果严重度,与发生概率无关(概率是 E 和故障率的工作)。一旦 HV 暴露,无论继电器多好,物理后果都是 S3。把低发生概率混入 S 评,会系统性地把整个 ASIL 降一到两档,导致 SM 投入严重不足。修法:S 评论证时明确只讨论「如果这个危险事件发生,最严重可信后果是什么」,把「多低概率」从这一栏完全隔离出去。

Gotcha-2: E 评用故障率而非运行概率。工程师查 FIT 数据:「我们的传感器 FIT = 10,非常可靠,所以 E 只需 E1」。根本错误:E 是车辆处于该 operational situation 的时间占比(SAE J2980),不是元件故障率。OS-1(充电中)每天持续 4–8h,E4 是客观运行数据,与传感器好坏无关。ISO 26262-3:2018 §6.4.3 明确把 E 定义为运行情境的暴露概率,不能用 FIT 替代。把 FIT 当 E,会把 ASIL 降级,而 SM 要求也随之宽松——刚好在最危险的高频场景留下保护空洞。

Gotcha-3: C 评「系统 safe 后」而非「故障瞬间」。工程师说:「我们有报警系统,用户听到警告后会拔枪,C2 足够」。隐蔽逻辑错误:报警系统是一个安全机制,HARA 阶段评 C 时,该 SM 可能已经失效(正是你在分析的故障场景)。C 评必须在**「SM 也失效」或「SM 无法工作」**的前提下评用户可控性。正确做法:把「报警响应」作为 FSC 阶段的 SM 加入,在 SM 独立失效率和有效性中论证,而不是在 HARA 的 C 评中预先计入。

Gotcha-4: n/a 格留白让审计判 NC。工程师跳过了「HE-5 V2G 反馈在 OS-1 充电中」这个组合,认为「V2G 模式不会在 OS-1 下发生,不用填」。审计问题:空格等于「未分析」,审计员会标 Not Conformant。正确做法:即使是 n/a 组合,也必须填写「n/a — 因为 OS-X 和 HazY 物理上互斥(理由)」,作为 Safety Case 的 completeness evidence。

Gotcha-5: BMS 已保护所以 OBC ASIL 可降。工程师说:「过充由 BMS 保护,BMS 已 ASIL D,OBC 不需要重复达到 ASIL D」。根本问题:HARA 是 item-level 分析,OBC 是独立 item。在 OBC 的 HARA 里,不能假设另一个 item(BMS)会提供保护(那是 FSC 里的 SM apportionment 工作,且需要 DFA 验证 BMS 和 OBC 无共因失效)。HARA 中写 OBC HE 的 ASIL,不能因「BMS 有 SM」而降档。只有在 FSC 阶段做正式 apportionment 并论证 BMS SM 独立性后,才能降 OBC 架构的 ASIL 要求。

Gotcha-6: FTTI 与充电控制周期混淆。工程师设 FTTI = 10s,理由是「充电控制 PID 周期 10s 足够响应」。根本混淆:FTTI 是物理/人体安全的时间约束(从故障到伤害发生的物理时间窗),而不是控制响应时间。电化学热失控一旦开始,10s 内会进入不可控相(见 §14.5 SG-3 的 50 ms 推导)。用控制周期代替 FTTI,会让 SM 的响应时间预算完全错误——SM 必须快得多。

Gotcha-7: HARA 冻结后从不更新(Living doc 失守)。HARA 在 M3 写完归档,项目后期 OBC 增加了 V2G 双向功能(M8 ECO)。工程师认为「功能只是增加了,安全性更好了」,未触发 HARA 更新。实际后果:V2G 引入了反向电流路径,产生了新的 HE(如 HE-5,G2V 无法停止导致电网侧过流)。漏识别该 hazard 让其 ASIL 默认等于 QM,而实际应分析。触发规则:任何 Item Definition 变更(新功能/模式/接口/OS 范围)都必须触发 HARA 影响分析,有变化必须更新 HARA,并重审所有受影响的 SG/FTTI。

边界工况不是例外,而是 HARA 必须覆盖的设计点——S/E/C 在边界处的变化直接决定 ASIL 是否降档。

Corner-1: 商用车/卡车 vs 乘用车。同一台 OBC 装到卡车,运行 profile 变:卡车每日充电频率较低、更多时间在行驶,OS-1(充电中)的暴露可能从 E4 降到 E3——则 HE-1 变 S3/E3/C3,经 Table 4 查得 ASIL C(D 降一档到 C)。另一方向,卡车维修工况 OS-5 的司机多为职业人员、对 HV 更有意识,C 可能从 C3 降到 C2,对应 HE 也随之降档。结论:不同应用场景 HARA 不能共用,必须分开做(或在 Item Def 里明确声明 intended vehicle class)。若 OBC 作为 SEooC 认证,其 AoU(Assumptions of Use,ISO 26262-10 SEooC 指南)必须包含 vehicle class 的 E 前提。

Corner-2: 封闭车库充电 vs 开放空间充电。HE-7(OBC 过热起火)在封闭车库(烟气积累 + 无法快速逃离)的 C 评应从 C2 升到 C3,则 S3/E4/C3 查表得 ASIL D,比开放空间的 S3/E4/C2 = ASIL C 高一档。若只按「开放空间」评 C2,则封闭场景的用户保护被系统性低估。正确处理:在 OS catalog 中把充电地点拆分(OS-1a 开放充电桩 / OS-1b 地库/封闭停车场),分别评 C,取最严 ASIL 作为 SG。

Corner-3: 紧急救援人员的 Exposure。碰撞后(OS-6),HE-8 的 E 通常评 E1(事故罕见)。但若 item 装在救援车辆(消防 EV)上,救援人员在 OS-6 中的暴露可能更高(日常接触事故车辆),E 可能从 E1 升到 E3;同时救援人员受过培训,C 可能从 C3 降到 C1。两者变化方向相反:E 上升让 ASIL 趋高、C 下降让 ASIL 趋低,合计影响取决于具体 S/E/C 三维组合(如 S3/E3/C1 与 S3/E1/C3 经 Table 4 同为 ASIL A)。通用原则:若 item 的用户群体超出「普通驾驶员」(如专业维修工、消防员),必须在 HARA 中单独建 OS 并评 C。

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