HARA 危害分析怎么做：从 ISO 26262-3:2018 条款到 EPS / eBooster 完整案例
原文链接：https://mp.weixin.qq.com/s/rOMZ_DaNFeg9t5prsCw-EA
适读人群：功能安全工程师、系统工程师、Tier1 安全经理、审核员、准备 ASPICE / 26262 评估的同行
篇幅：约 7000 字 | 阅读时间：≈ 18 分钟
涉及标准：ISO 26262:2018 Part 3（对应 GB/T 34590.3-2022 第 3 部分），GB 17675-2025（汽车转向系 要求），SAE J2980，GB/T 45829（基于 HAZOP 的安全分析）
一、为什么 HARA 是整个功能安全项目的"地基"
一个很常见的 OEM 审核场景：审核员把一份安全目标表翻过来，手指停在第二行问——“这个 ASIL B 是怎么评出来的？S 多少？E 多少？C 多少？依据呢？” 项目组答不出来，或者只能说出"凭经验"。审核员抬笔写"待澄清"，轻则返工、重则重新启动 HARA。
ISO 26262 全书所有与"开发强度"挂钩的指标——硬件架构度量（SPFM/LFM/PMHF）、软件单元测试覆盖率（语句/分支/MC-DC）、设计验证深度、独立性等级——全部直接由"安全目标的 ASIL"向下传导。ASIL 评高一档，开发量翻倍；评低一档，审核被打回。 而这"一高一低"的源头，全部在 Part 3 第 6 章——危害分析与风险评估（HARA, Hazard Analysis and Risk Assessment）。
HARA 一次评错，下游所有"安全案例"都跟着错。这也是为什么 SGS、TÜV、南德、UL 这类第三方评估机构最先看的、问得最细的，都是 HARA。
那么，HARA 该怎么做、做到什么深度算够、什么算"过度"？下面把 ISO 26262-3:2018 的硬性条款和工程界的常见做法拆开讲。
注：以下内容全部以 ISO 26262:2018 第二版为依据；与 2011 版的差异会单独标注。中文对照标准为 GB/T 34590.3-2022（修改采用 2018 版）。
图 1 ISO 26262:2018 标准体系与 V 模型；HARA 位于 Part 3 第 6 章，是概念阶段的核心输出 图片来源：ISO 26262-1:2018 改绘 / 汽车软件开发流程学习基地
二、标准条款：HARA 在 ISO 26262-3:2018 里的精确位置
Part 3 概念阶段（Concept phase） 由三章组成：
第 5 章Item definition（项目定义）—— 划边界、写功能、列接口、给运行环境
第 6 章Hazard analysis and risk assessment（危害分析与风险评估）—— HARA
第 7 章Functional safety concept（功能安全概念）—— 把 HARA 的输出（安全目标）展开成 FSR
第 6 章的子条款（一定要背下来）：
| 子条款 | 标题 | 关键内容 |
|---|---|---|
| 6.2 | General | HARA 的目的、定位 |
| 6.4.1 | Initiation of the HARA | 必须基于 item 定义；不应考虑将实施或已在上一代实施的安全机制 |
| 6.4.2 | Situation analysis and hazard identification | 描述运行场景；整车层面定义危害；识别"合理可预见的误用"；考虑多个功能同时失效 |
| 6.4.3 | Classification of hazardous events（S/E/C 三参数评级） | 对每个危害事件用 S、E、C 三轴评级 |
| 6.4.4 | Determination of ASIL and safety goals | 查表得 ASIL；导出安全目标（含 FTTI 与 safe state） |
| 6.4.5 | Verification | 验证 HARA 自身的一致性、完整性 |
三张分类表 + 一张判定表（Part 3 表 1–4，必须分清）：
Table 1Severity classes S0–S3（基于 AIS 伤害量表）
Table 2Classes of probability of exposure E0–E4
Table 3Classes of controllability C0–C3
Table 4ASIL determination**（S × E × C 的查询矩阵）
下面按子条款顺序把每个参数的"标准强制要求"和"工程常见做法"分开讲。
三、核心拆解：从项目定义到 ASIL 判定的工程做法
3.1 先做项目定义（5.5.1），再做 HARA
强制要求（5.5.1）：HARA 的输入是项目定义，包括功能、边界、接口、运行环境、非功能需求。
常见做法（行业）：用 VDA 360 之类的接口推荐做参考。eBooster 这种边界清晰的项目，OEM 拿到 Tier1 的接口定义就能开工。
以博世第二代 iBooster（2016 年量产）为例——iBooster 是替代真空助力器的电控助力器，作用是在驾驶员踩下制动踏板时，由 ECU 控制永磁同步电机产生伺服力推动主缸活塞建立液压制动。
图 2 博世第二代 iBooster 整体结构与剖视图。关键组件：储液壶 / 制动主缸 / 电控单元 ECU / 永磁同步电机 / 三级减速机构（一级滚珠丝杠）/ 位移差传感器 / 助力阀体 / 输入推杆 / 耦合装置 / 回位弹簧 图片来源：汽车测试网 auto-testing.net（iBooster 二代技术资料） iBooster Item 定义的关键要素（写 HARA 之前必须先填好）：
| 项目 | 内容 |
|---|---|
| 名称 | 机电伺服制动助力器 iBooster 二代 |
| 边界 | 输入到制动主缸之前的电控助力部分（含 ECU、永磁同步电机、减速机构、位移差传感器、输入推杆） |
| 对外接口 | 踏板位移输入、CAN 信号输入（ESC/ESP、ADAS）、主缸液压输出、供电（9.8–16 V） |
| 主要功能 | 驾驶员制动时提供伺服助力；踏板信号采集；将电机扭矩经滚珠丝杠转换成主缸推力 |
| 失效模式 | 主缸压力过大/过小/无助力/助力振荡/自建压（无踏板输入却建压） |
关键边界判断：iBooster 不包含 ABS/ESC 的轮缸压力调节功能，也不包括踏板感模拟器（踏板感在 iBooster 内部由助力阀体和软件标定实现）。这影响后面"外部措施"能不能用。
3.2 整车层危害识别（6.4.2.3 强制要求）
强制要求（6.4.2.3）：“危害应当在整车层面（vehicle level）定义”；不应仅停留在部件或子系统层面；不应考虑与本 item 无关的其他系统的失效。
常见做法（行业）：用 HAZOP（Hazard and Operability Study，危害与可操作性分析）引导词法系统识别失效。GB/T 45829 给出 6 类标准引导词：
| 引导词 | 含义 | 对 iBooster 的失效表现 | 整车致命危害 |
|---|---|---|---|
| No（无） | 功能丧失 | 完全无助力 | 高速避险制动沉重，无法避让 |
| More（过量） | 助力过强 | 主缸压力过大 | 高速轻微踩踏即产生剧烈减速，后车追尾 |
| Less（不足） | 助力偏弱 | 主缸压力小于需求 | 操控负担增加，无致命风险 |
| Reverse（反向） | 助力方向相反 | 输入推杆位移方向反 | 踩刹车反而加速 |
| Early-Late（时序错） | 助力时序错 | 响应延迟/提前 | AEB 时机错失 |
| Unexpected（意外） | 非期望激活 | 无踏板输入却建压 | 高速自动制动 |
易错点：把"传感器信号漂移"这种部件层失效写进 HARA。不对。HARA 只关心"信号漂移在整车层表现成什么"——即"非期望激活/制动/转向"。
另一个 HAZOP 实战细节：HARA 阶段不要去考虑失效根因。比如"扭矩传感器单点漂移导致 H-02 反向扭矩"——根因是传感器单点漂移，这属于设计缺陷，会在硬件 FMEA 里详细分析。在 HARA 阶段，H-02 反向扭矩是 H-02 本身，至于怎么防住它，是 FSC 阶段安全机制的事。HARA 不查原因，只看后果。这条对新人极重要，新人写 HARA 很容易越界写成 FMEA。
3.3 严重度 S（Table 1）——基于 AIS 伤害量表
强制要求（Table 1 + 6.4.3）：
| S | 描述 | AIS 参考 |
|---|---|---|
| S0 | 无伤害 | AIS 0 |
| S1 | 轻到中度伤害 | > 10% 概率为 AIS 1–2 |
| S2 | 严重或危及生命（生存可能） | > 10% 概率为 AIS 3–4 |
| S3 | 危及生命或致命伤害 | > 10% 概率为 AIS 5–6 |
AIS（Abbreviated Injury Scale）是医学界定义的 0–6 级伤害量表。表 1 把伤害按概率落到 S0–S3 这 4 个工程等级上。
常见做法（行业 + SAE J2980）：把 S 跟"事故场景下的碰撞速度"绑定。比如：
| 场景 | 典型速度 | S |
|---|---|---|
| 车库内静止/极低速移动 | < 10 km/h | S0–S1 |
| 城市道路、停车 | 10–30 km/h | S1–S2 |
| 城市干道、郊区 | 30–80 km/h | S2 |
| 高速、绕弯、变道 | > 80 km/h | S2–S3 |
易错点：只看"车内乘员"伤害。不对。S 必须同时考虑车外交通参与者（行人、两轮车、对向车）。AEB 误触发导致后车追尾，是 S3。
3.4 暴露度 E（Table 2）——最容易出争议的参数
强制要求（Table 2）：
| E | 描述 | 持续时间占比 | 频次 |
|---|---|---|---|
| E0 | 不可思议 | — | 飞机坠落到公路、自然灾害 |
| E1 | 极低概率 | 未规定 | 每年不到一次 |
| E2 | 低概率 | < 1% 平均运行时间 | 每年几次 |
| E3 | 中等概率 | 1%–10% | 每月一次或更多 |
| E4 | 高概率 | > 10% | 几乎每次出行 |
关键点（强制）：E 是"运行场景"的暴露，不是"故障率"。ISO 26262 用 ASIL 等级"编码"了故障率（λ），HARA 阶段不应把 λ 算进 E。E 评高/评低一档，等于把 ASIL 推高一档或拉低一档。
常见做法（行业 + 附录 B）：根据"持续时间"或"频次"两种度量取一种。同一 E4，“高速行驶"用持续时间评（> 10% 平均运行时间），“倒车"用频次评（每次出行都至少倒一次车）。
两个最常被搞错的点：
不考虑装备率（强制要求，6.4.2 与 E 定义）。AVP 自动代客泊车只有 1% 车辆装配？不影响 E。E 评的是"装了这项功能的车，处于该场景的概率”。E 评定时假设每辆车都装。
场景切分不能过细（强制要求，6.4.2.7）。把"白天高速 + 干燥路面 + 直行 + 载重 < 500 kg"切到这么细，E 会从 E4 直接掉到 E2，ASIL 跟着降一档。标准明确禁止这种"通过切分场景不当降低 ASIL"的做法。
德系曾尝试统一 E 评级：VDA（德国汽车工业协会）推出过 VDA 702 试图给 E 评级定一个行业标准，但连参与制定的车企最后都没有完全遵守，更别说其他国家的车企了；这份标准至今只有德文版。这说明 E 评级主观性极强，是 OEM 之间分歧最大的点。
3.5 可控度 C（Table 3）——成本最高、know-how 最深的参数
强制要求（Table 3）：
| C | 描述 | 含义 |
|---|---|---|
| C0 | 通常可控 | 普遍情况下可控 |
| C1 | 简单可控 | 99% 及以上驾驶员或交通参与者能避免伤害 |
| C2 | 正常可控 | 90% 及以上能避免 |
| C3 | 难控或不可控 | 不到 90% 能避免 |
常见做法（行业）：做可控性研究（Controllability Study）。具体方法：
选 ≥ 20 名有驾照、身体健康、年龄段覆盖的驾驶员
在封闭场地或专业试验场做故障注入测试（如突然切断助力、注入反向扭矩）
用主观评价（驾驶员口头打分，1–10 分制）+ 客观数据（方向盘转速、横摆角速度、车身侧偏角）
把 90% 驾驶员能控的定 C2，< 90% 定 C3
关键成本：Controllability Study 是车企最贵的"安全活动"之一——场地、车辆改装、试车员、差旅、保险，单次 50–200 万元人民币很常见。这部分经验是车企的核心 know-how，对外保密。
想要"省钱"用 C1/C2 把 ASIL 拉低？审核员会直接说：“请提供 controllability study 的报告。“拿不出来，ASIL 立刻升回去。
可控度分级的"反直觉"细节：
C0 ≠ QM。C0 是"通常可控”，意味着大多数驾驶员能避免伤害，但不是没有伤害。C0 在表 4 中直接 QM，但注意：C0 适用于"本 item 不可用导致的失效”——例如 ABS 失效应不影响车辆安全驾驶（驾驶员靠机械制动就能停车）。如果 ABS 失效是"完全无机械制动”——那不是 C0 是 C3。
C1 的"99% 驾驶员能避免"是基于统计数据，不是凭感觉。审核员会让你给分布：年龄、驾龄、性别、当日状态、是否佩戴安全设备。C1 的实验报告里至少要 30 名驾驶员才有统计意义，20 名勉强可接受。
场景可分时，优先取难控场景。如果一个危害事件可能在白天良好光照（驾驶员反应快）发生，也可能在夜间无路灯（反应慢）发生——取夜间，E 也取夜间，所有评级保守化处理。6.4.3 明确说"if in doubt, take the higher level"。
3.6 ASIL 判定（Table 4）——查表
把 S、E、C 三个等级填进下表（S0 和 E0 直接 QM，表中省略）：
| C1 | C2 | C3 | |
|---|---|---|---|
| S1 × E1 | QM | QM | QM |
| S1 × E2 | QM | QM | QM |
| S1 × E3 | QM | QM | A |
| S1 × E4 | QM | A | B |
| S2 × E1 | QM | QM | QM |
| S2 × E2 | QM | QM | A |
| S2 × E3 | QM | A | B |
| S2 × E4 | A | B | C |
| S3 × E1 | QM | QM | A |
| S3 × E2 | QM | A | B |
| S3 × E3 | A | B | C |
| S3 × E4 | B | C | D |
规律：S、E、C 中任何一个降一档，ASIL 大致降一档。所以每一个档位的评级都必须有依据、有数据，否则就是在悄悄降低 ASIL。
E0 的特殊地位（强制要求）：E0 永远 QM，不分配 ASIL。E0 是"飞机坠落到公路上"这种不可思议的场景。
用判定表的三条工程经验：
查表结果往往是上限：实际系统还要看"独立外部措施"是否可降一档。比如装备 ESC 的车辆，eBooster 误触发导致制动过度，由于 ESC 可介入控车，C 可能从 C3 降到 C2，ASIL 跟着降一档。但这种"降档"必须基于外部措施的独立性证据——ESC 和 eBooster 不能共因失效（无共享传感器、共享 MCU、共享电源）。
多事件合并：H-01 / H-02 经常被合并为同一 SG（“防止任意方向非驾驶员指令的转向”），合并后的 SG 取最高 ASIL。这意味着 H-01 H-02 可以分别 ASIL D，但合并后仍 ASIL D，没省事。 真正能省事的是 ASIL 分解——那是 Part 9 的工作。
ASIL D 不是"末日"：很多工程师一看到 ASIL D 就想"这下完了"。其实 D 只是一个开发强度等级。D 的开发流程是标准化的、可量化的、有成熟工具链的。真正的成本在 HARA 上——评对 ASIL，下游的工作量是确定的；评错 ASIL，才是反复返工。
3.7 安全目标导出（6.4.4）——FTTI 与 safe state
强制要求（6.4.4）：每个 ASIL 等级的危害事件导出一条安全目标（Safety Goal），安全目标继承该危害事件的最高 ASIL。安全目标必须是"可验证的"——能用测试或分析证明满足。
安全目标的"三件套"：
目标陈述：用动词表达（prevent / achieve / maintain），不要用"应当是安全的"这种模糊词
FTTI（Fault Tolerant Time Interval）：从故障发生到系统必须进入安全状态的最大允许时间，典型值 50 ms–500 ms
Safe state（安全状态）：故障后系统应进入的"无不合理风险"状态
反例（常见但不符合 6.4.4）：
“EPS 系统应当总是安全的。"——不可验证。
“EPS 系统应当在故障时停止工作。"——没定义 FTTI，没说"停止"是什么状态。
正例（符合 6.4.4 + 6.4.5）：
“应防止非驾驶员指令下的转向助力施加，导致不可控的横向偏移。ASIL D，FTTI ≤ 100 ms，safe state = 切断助力电机使能并点亮警告灯。”
四、项目落地：模板 + EPS / eBooster 完整 HARA
4.1 HAZOP + ASIL 联合模板
实际项目里很少"先列危害、再评级”——大多是 HAZOP 引导词（识别失效）+ ASIL 表（评级）一气呵成。下面是工程上常用的合并模板：
图 3 HARA 工作流总览：四个里程碑分别是 Item 定义、危害分析、S/E/C 评级与 ASIL 判定、安全目标导出 图片来源：搜狐 / 微信公众号「AUTO 世代」
图 4 HAZOP + ASIL 联合分析模板（含一行示例：系统异常 #1 在高速干燥 / 120 km/h 转向下，产生危害事件 #1，S3 / E4 / C3 → ASIL D → SG#1 (ASIL D)） 图片来源：搜狐 / 微信公众号「AUTO 世代」 模板列说明（自左向右）：
系统 / 异常功能 / 危害列表—— 三大列对齐 HAZOP 引导词扫描的输出
道路场景（道路类型 / 道路状况 / 其他环境）—— 6.4.2 要求
驾驶场景（运行状态 / 速度 / 运行方向）—— 6.4.2 要求
危害事件—— HAZOP 输出
S / E / C 评级—— 6.4.3 + Table 1/2/3
ASIL—— 6.4.4 + Table 4
安全目标 SG—— 6.4.4 输出
4.2 完整案例：EPS 的 4 条 HARA 记录
下图是一台乘用车 C-EPS（Column-assist EPS，柱式电动助力转向） 的结构示意。理解结构对识别失效模式很关键。
图 5 典型 C-EPS 转向系统结构示意：1-输入轴 / 2-扭矩传感器 / 3-电机 / 4-循环球螺杆 / 5-齿条 图片来源：cntronics.com / 电动汽车工程手册 扭矩传感器是 EPS 的"感官”，主流方案是非接触式（磁电式），结构如下：
图 6 非接触式扭矩传感器结构：1-轴套 / 2-线圈 / 3-线轴套（磁性材料）/ 4-扭杆 / 5-输入轴 图片来源：cntronics.com 下表是 EPS 的 4 条典型 HARA 记录（基于 Dowway Vehicle 与公开工程资料的整理）：
| ID | 危害事件 | 运行场景 | S | E | C | ASIL | 主导因素 |
|---|---|---|---|---|---|---|---|
| H-01 | 高速行驶时 EPS 电机突然失助力（控制器烧毁） | 高速匝道 80 km/h 急转向 | S3 | E4 | C3 | D | 极端速度 + 零反应窗口 + 横向加速度 |
| H-02 | 高速行驶时 EPS 输出反向助力（软件/扭矩传感器错） | 高速超车 / 弯道 | S3 | E4 | C3 | D | 直接、主动路径偏移 |
| H-03 | 低速停车时 EPS 输出非期望转向扭矩 | < 5 km/h 停车入库 | S2 | E3 | C1 | A | 动能低，驾驶员一脚刹车即可接管 |
| H-04 | 中速车道变换时 EPS 锁死（机械卡滞） | 60 km/h 变道 | S3 | E3 | C2 | C | 中等暴露，驾驶员可刹车控路径，但路径已被锁定 |
4 条 HARA 对应的安全目标（继承各自 ASIL）：
| SG | 安全目标 | ASIL | FTTI | Safe state |
|---|---|---|---|---|
| SG-01 | 防止非驾驶员指令的转向助力施加（任意车速） | D | ≤ 100 ms | 切断电机使能，机械连接保转向 |
| SG-02 | 防止高速（> 60 km/h）下助力突然丢失 | D | ≤ 100 ms | 转入纯机械转向模式（无助力），警告灯亮 |
| SG-03 | 防止低速 EPS 输出导致非期望路径偏移 | A | ≤ 500 ms | 切断电机使能 |
| SG-04 | 防止 EPS 转向机构机械锁死 | C | ≤ 50 ms | 切换至冗余机械路径（若有）或告警 |
GB 17675-2025 新规（中国，乘用车转向系国标修订版）：正式将 EPS 的功能安全等级从原来的 ASIL B/D 统一提升到 ASIL-D 作为强制要求，并要求双通道独立校验、独立切断功率回路、独立扭矩采集。这是 HARA 输出对工程界实际影响的典型案例——HARA 评的 ASIL D，最终写进了国标。
4.3 配套案例：eBooster 的 4 条 HARA 记录
为了把上面的方法论再固化一遍，给出 eBooster（博世第二代） 的 4 条 HARA 记录。iBooster 与 EPS 是底盘最常被一起评审的两个 item——一个横向、一个纵向；一个 ASIL D、一个 ASIL D。这两套 HARA 的"做法模板"在底盘域可以反复复用。
| ID | 危害事件 | 运行场景 | S | E | C | ASIL | 主导因素 |
|---|---|---|---|---|---|---|---|
| B-01 | 驾驶员未踩踏板时 iBooster 自建压（无踏板输入却建立主缸压力） | 高速巡航 100 km/h | S3 | E4 | C3 | D | 主动建压直接致追尾 |
| B-02 | 驾驶员踩踏板时 iBooster 无助力（控制器/电机失效） | 高速避险 80 km/h | S3 | E4 | C3 | D | 转向+制动同时高负载，制动失效后果严重 |
| B-03 | 驾驶员踩轻踏板时 iBooster 输出过强主缸压力 | 城市跟车 40 km/h | S2 | E4 | C3 | C | 主缸压力过大但车速中等，撞停可控 |
| B-04 | iBooster 助力振荡（压力周期波动 > 5 Hz） | 拥堵跟车 20 km/h | S1 | E3 | C1 | QM | 低速可接管，无致命风险 |
对应的安全目标（继承 ASIL）：
| SG | 安全目标 | ASIL | FTTI | Safe state |
|---|---|---|---|---|
| SG-B1 | 防止 iBooster 在无踏板输入下自建压 | D | ≤ 120 ms | 切断电机使能，机械纯液压建压 |
| SG-B2 | 防止 iBooster 高速失助力 | D | ≤ 100 ms | 切换至冗余机械路径（与 ESC 协调建压） |
| SG-B3 | 防止 iBooster 输出过强主缸压力 | C | ≤ 200 ms | 限制最大主缸压力 8 MPa（软件限幅） |
| SG-B4 | （不分配 ASIL） | QM | — | — |
iBooster 工程细节（与 HARA 强相关）：iBooster 二代最大助力 8 kN（第一代 5.5 kN），压力建立时间 120 ms（典型 ESP 系统约 350 ms），失效模式下 ESC 可接管（200 N 踏板力提供 0.4 g 减速度）。这些参数直接进入 SG-B1/SG-B2 的 FTTI 与 safe state 设定。
ASIL 分解提示：iBooster ECU 内部分为"踏板信号采集通道"和"电机驱动通道"，单看每条通道都达不到 ASIL D 所需的诊断覆盖率，所以需要 ASIL 分解——把 SG-B1 (D) 分解为"踏板信号通道 B(D)“和"电机驱动通道 B(D)"，靠两个 B(D) 的独立性实现 D 的目标。这是 Part 9 的工作，但 HARA 必须知道这条路是通的。
五、常见坑：审核员最爱问的 8 个点
坑 1：把"故障率 λ"写进 E
典型错话：“这个故障一年才发生一次，所以 E 应该是 E1。” 真相：E 评的是"运行场景的暴露”，不是"故障发生的概率"。一年发生一次的故障可能发生在 E4 场景下，ASIL 仍可能是 D。
坑 2：在 HARA 里就考虑了"内部安全机制"
典型错话：“我们 ECU 有故障监控，所以这个失效会被检测到，危害等级降低了。” 真相：6.4.1.2 强制——“在 HARA 阶段，不应考虑将要实施或已在上一代实施的安全机制”。监控模块是功能安全概念（FSC）阶段才该引入的设计；提前考虑会造成"双重计算"——HARA 低估了危害，FSC 又高估了安全机制，审核员两边都不信。
坑 3：把场景切到过细，悄悄降低 ASIL
典型错话："‘高速 + 干燥 + 弯道 + 大客车’这种组合一年遇不到一次，所以 E2。" 真相：6.4.2.7 明确要求"所选场景粒度不应导致 ASIL 不当降低"。审核员会要求"为什么把场景切到这个粒度？"，答不上来就是审核失败。
坑 4：C 凭"直觉"评，无可控性研究数据
典型错话：“驾驶员肯定能感觉到方向盘变重，自己会用力——C1。” 真相：C 的每一档都有统计数据含义（C1：≥ 99% 驾驶员能避免；C2：≥ 90%）。审核员会问：“做了 controllability study 吗？样本量多少？驾驶员年龄分布？场地条件？“拿不出报告，C 直接升档。
坑 5：安全目标不可验证
典型错话：“系统应保持安全。” 真相：6.4.4 要求安全目标可验证。测试工程师没法对"安全"做通过/不通过判定。一定要写明"prevent 什么 / achieve 什么 / FTTI 多少 / safe state 是什么”。
坑 6：忽略"合理可预见的误用”
典型错话：“用户怎么可能会把 EPB 按钮放在水杯下面？” 真相：2018 版把 2011 版的"foreseeable misuse"（可预见的误用）改成了 “reasonably foreseeable misuse”（合理可预见的误用），加了"合理"两个字。但"合理"不等于"不"——电子手刹拉起式按钮设计就是为了防误用，标准制定者不会把"误用"全排除。
坑 7：HARA 一次性做完再不动了
典型错话：“HARA 三年前就签字了，现在改点东西不用动 HARA。” 真相：HARA 是"持续维护的工作产品"。系统边界一改，运行场景就变，危害事件就变，ASIL 就可能变。Item 定义的任何变更（功能增减、接口调整、运行环境变化）都要触发 HARA 再评估。8.5 Change management（Part 8）就是管这个的。
重要区分（必看）：ASIL 分解（ASIL Decomposition）是 Part 9 第 5 章的工作，不在 HARA 阶段做。常见错话：“我们做 ASIL 分解了，把这个传感器降到 ASIL B”——这是把 Part 9 的工作提前到 Part 3，结果：HARA 评的 ASIL 偏高，下游的工作量没减但理由说不清。先在 HARA 评出"真实 ASIL"，再在系统设计时用 ASIL 分解分配——别倒过来。
坑 8：忽略"多功能同时失效"的组合效应
典型错话：“只要单个功能不出问题就好。” 真相：6.4.2.6 强制要求识别"多个功能同时失效"的组合场景。最经典的例子是整车电源失效——当 12 V 蓄电池掉电时，电动转向助力 + 制动助力 + 前照灯 + 发动机扭矩可能同时丢失。这种多个 ASIL D 功能同时失效的场景，会把驾驶员的可控性直接打到 C3（无可控性），ASIL 不可降档，必须当作"叠加危害"分别评级并各自导出安全目标。
整车电源系统在 ISO 26262 体系里是一个特殊的"基础设施级"项目——它的安全目标必须由整车电源管理策略承载（双电源、储能电容、动态切换）。很多项目的 HARA 第一版就漏掉了"电源失效"这个组合场景——审核员必问。
六、工程师视角：把 HARA 写"对"的 5 个习惯
先 Item 定义，再 HARA。Item 定义含糊的 HARA 一定评得不准。每次 HARA 评审前先问一句：“Item 边界、接口、最近一次变更更新了吗？”
每条评级带"证据链接"。S/E/C 后面挂一个证据列：交通事故数据库（CRSS、CIDAS）、驾驶模拟报告、controllability study 报告、公开事故数据。审核时一拉就出来。
HAZOP 引导词法 + FMEA 互补。HAZOP 抓"整车层异常行为"，FMEA 抓"部件层失效模式"，两者交叉而非二选一。GB/T 45829 是 HAZOP 的国内对标。
HARA 评级表与功能安全概念（FSC）严格一一对应。每条 SG 必须能追到至少一条 HARA 记录（“trace both ways”），每条 HARA 记录也必须能派生至少一条 SG。审核员抽一条 FSC 里的 FSR 反查 HARA 找不到对应——直接不符合项。
看一遍 VDA 360。iBooster 案例的接口定义是 VDA 360 推荐的范本，做制动 / 转向 / 域控 HARA 时读一遍，比自己从零写能省两周。
HARA 不是写一份"漂亮的表格"交差，而是要建立一个可追溯的、可重复的、有证据的判断过程。评出来的 ASIL 错一档，下游的所有开发强度都错一档，错的代价是按"百万人民币 + 半年时间"算的。 把 HARA 写对，整个项目就稳了一半。
关于 HARA 的两个常被问的边界问题：
Q1：HARA 与 SOTIF（ISO 21448）怎么分？ A：HARA 处理的是"电子电气系统失效导致的风险"；SOTIF 处理的是"系统没有失效但功能性能局限导致的风险"。比如 LCC（车道居中）正常工作时遇到磨损车道线而偏离车道——HARA 没问题，这是 SOTIF。LCC 失效时无端偏离——HARA 范畴。两者不是替代关系，是互补关系。HARA 评完 SOTIF 也要评，否则只覆盖了一半风险。SOTIF 的触发条件区（known safe / known unsafe / unknown unsafe）分析是基于 HARA 输出的 SG 进一步做的。
Q2：HARA 与 TARA（ISO/SAE 21434 网络安全）怎么分？ A：HARA 看"系统自己可能怎么失效"；TARA 看"对手主动攻击可能让系统怎么失效"。比如 CAN 总线被注入恶意报文导致 iBooster 自建压——TARA 视角（攻击者利用 UDS 协议漏洞）。同样的 iBooster ECU 软件 bug 导致自建压——HARA 视角（系统自身缺陷）。两者都看"非驾驶员期望的制动"这个危害事件，但触发机制不同、分析方法不同、安全机制也不同（HARA 关注诊断覆盖率，TARA 关注加密/认证/访问控制）。
HARA 评完，FSC 该写哪些内容？——简要衔接，给下一讲铺路：
每条 SG 拆出至少一条 FSR（Functional Safety Requirement）。例如 SG-01 “防止非驾驶员指令的转向” → FSR-01 “扭矩传感器通道 1/2 必须在 50 ms 内达成一致，否则切断电机使能”。
每条 FSR 标注 ASIL 继承路径——是直接继承 SG 的 ASIL，还是通过 ASIL 分解（Part 9-5）降档分解的。
每条 FSR 必须可验证——给出验证方法（测试 / 分析 / 检查表）与接受准则。
每条 FSR 必须有故障响应时间（FTTI）和故障响应后的稳态时间。FTTI 是"从故障发生到系统必须进入 safe state 的最大允许时间"。
ASIL 分解的工程示例（承接 SG-B1 例子）：
| 分解对象 | 原始 ASIL | 分解后 ASIL | 独立性要求 |
|---|---|---|---|
| 踏板信号通道 | D | B(D) | 与电机驱动通道独立采集、独立处理 |
| 电机驱动通道 | D | B(D) | 与踏板信号通道独立供电、独立控制 |
| 监督通道（watchdog） | — | A(D) | 独立时钟、独立参考电压 |
分解成立的两个条件（Part 9-5）：
两个 B(D) 元素必须有足够的独立性（无共因失效、无级联失效、无级联违反）
一个 B(D) 失效，另一个 B(D) 必须能实现"完整 SG 行为"——也就是说单 B(D) 失效不能让 SG 失效
踩坑预警：ASIL 分解不是"把 D 拆成两个 B"——这是把 D 偷换成两个 B 的工作量。真正的分解必须有"冗余"和"独立失效"证据，否则审核员直接退回。
下一讲：HARA 之后怎么把安全目标（SG）展开到功能安全需求（FSR）？—— ISO 26262-3:2018 第 7 章 FSC 的工程做法。
参考资料
ISO 26262:2018 Road vehicles — Functional safety — Part 3: Concept phase (Concept phase)
GB/T 34590.3-2022 道路车辆 功能安全 第 3 部分：概念阶段（修改采用 ISO 26262-3:2018）
SAE J2980 Considerations for ISO 26262 ASIL Hazard Classification
VDA 360 Interface Recommendation: ESC eBooster V1.0
GB/T 45829（基于 HAZOP 的安全分析）
GB 17675-2025 汽车转向系 基本要求（修订版，强制 EPS 满足 ASIL-D）
Bosch iBooster 2nd Generation Technical Documentation（OFweek / 汽车测试网公开技术资料）
Dowway Vehicle. ISO 26262 HARA Guide: EPS Case Study（公开技术博客）
Kemmann, S. SAHARA — Safety Analysis of Risk and Hazard Analysis (Dissertation, RPTU)
ISO 26262 Academy. Hazard Analysis & Risk Assessment (HARA) 课程资料
— 本篇完 — 「汽车功能安全」公众号 · 每周一篇深度技术 · 不浮于表面