📚 课程目录第4章 HARA 入门

4. HARA 入门

HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）是 ISO 26262 功能安全流程的起点，也是 BMS 安全开发中最关键、最容易被低估的一步。它的核心任务不是“把风险算出来”，而是回答三个问题：什么会出错？出错后有多严重？在什么场景下会出错？ 只有把这三个问题回答清楚，后续的安全目标（Safety Goal）、功能安全概念（FSC）和技术安全需求（TSR）才有立足点。

HARA 的本质是“从危害出发，反推安全需求”。它不追求精确的定量概率，而是通过严重度（S）、暴露度（E）、可控性（C）三个维度，把危害事件映射到 ASIL 等级，从而决定后续开发投入的强度。

4.1 HARA 的目的与在安全生命周期中的位置

在 ISO 26262 的安全生命周期中，HARA 位于“概念阶段”的最前端。它上承“相关项定义（Item Definition）”，下启“功能安全概念（FSC）”。没有 HARA，就无法确定安全目标，也无法分配 ASIL 等级，后续的硬件随机失效指标、软件架构约束、验证确认活动都会失去依据。

对 BMS 而言，HARA 的典型对象包括：过充、过放、过流、过温、绝缘失效、接触器粘连、SOC 跳变、采样链路失效等。每一个对象都需要被放入具体的整车场景中分析，而不是孤立地看电芯或电路。

4.2 HARA 的基本流程：七步法

ISO 26262-3 给出了 HARA 的标准流程，工程上通常归纳为以下七步。每一步都有明确的输入和输出，缺一不可。

定义相关项与边界：明确 BMS 的功能、接口、与整车其他系统的交互关系，确定哪些部分在分析范围内。
识别危害：从功能失效出发，识别可能造成伤害的整车级危害，而不是停留在“电芯过压”这种部件级描述。
确定危害事件：将危害与具体运行场景结合，形成“危害 + 场景”的危害事件。
评估严重度 S：判断危害事件对驾驶员、乘客、行人等造成的伤害等级，S0～S3。
评估暴露度 E：判断该场景在车辆生命周期中出现的概率，E0～E4。
评估可控性 C：判断驾驶员或其他人员能否及时控制危害，C0～C3。
确定 ASIL 与安全目标：查表得到 ASIL 等级，并据此定义安全目标、安全状态和 FTTI。

4.3 S/E/C 参数关系与 ASIL 判定

S、E、C 三个参数不是独立打分，而是共同决定 ASIL。严重度越高、暴露越频繁、可控性越差，ASIL 等级越高。下表给出了 BMS 常见危害事件的评分示例。

危害事件	典型场景	S	E	C	ASIL
过充导致热失控	快充过程中充电桩未按协议停止	S3	E3	C2	ASIL C
行驶中意外断电	高速超车时接触器误断开	S2	E4	C2	ASIL C
绝缘失效导致触电	车辆涉水后高压系统漏电	S3	E2	C3	ASIL D
SOC 跳变导致续航误判	城市道路正常行驶	S1	E4	C1	QM

ASIL 等级从 QM、A、B、C 到 D 逐级升高。QM 表示仅需质量管理，不要求功能安全开发；ASIL D 则要求最严格的开发流程、硬件指标和验证确认活动。BMS 中涉及高压安全和热失控的危害，通常至少为 ASIL C。

4.4 案例场景：过充危害的 HARA 推演

以“快充过程中 BMS 未能及时请求停止充电”为例，HARA 的推演路径如下：

功能失效：BMS 过充保护功能失效
    ↓
整车危害：动力电池持续过充 → 电芯热失控 → 整车起火
    ↓
危害事件：快充场景下，充电桩持续输出而 BMS 未切断
    ↓
S 评估：可能造成乘员重伤或死亡 → S3
E 评估：快充是日常高频场景 → E3
C 评估：驾驶员无法直接干预充电回路 → C2
    ↓
ASIL 判定：S3 + E3 + C2 → ASIL C
    ↓
安全目标：防止动力电池在充电过程中发生不可控过充
    ↓
安全状态：主动请求充电桩停止输出，并断开高压继电器
    ↓
FTTI：从检测到过充到进入安全状态，通常要求 ≤ 100 ms

这个案例说明，HARA 的输出不是一句“防止过充”，而是一个可验证、可分配、可追溯的安全目标体系。安全目标必须包含安全状态和 FTTI，否则后续的硬件和软件设计就没有量化约束。

4.5 常见误区与复盘要点

误区一：把部件失效当危害。“电芯过压”是失效模式，不是危害事件。危害必须落到整车层面，例如“过充导致热失控起火”。
误区二：忽略场景。同一个失效在不同场景下 ASIL 可能完全不同。充电、行车、驻车、维修场景必须分别分析。
误区三：S/E/C 打分随意。打分必须有依据，通常需要参考历史事故、法规要求、企业安全规范和专家评审记录。
误区四：安全目标不可验证。安全目标如果只写“防止过充”，没有安全状态和 FTTI，后续无法分解为 TSR，也无法验证。
误区五：HARA 一次做完就冻结。当相关项定义、整车架构或法规发生变化时，HARA 必须重新评审和更新。

HARA 不是一个人闭门造车的结果，必须由系统、硬件、软件、测试、整车集成等多角色共同评审。BMS 的 HARA 尤其需要整车层面的输入，否则容易把危害范围定得过窄，导致后续安全目标遗漏。

总结来说，HARA 是 BMS 功能安全开发的“第一块基石”。它把模糊的“电池不安全”转化为清晰的危害事件、ASIL 等级和安全目标，为后续 FSC、TSR、硬件设计和软件架构提供可追溯的输入。掌握 HARA 的输入输出、流程和 S/E/C 判定逻辑，是进入功能安全工程实践的第一步。