HARA 报告写作工程化深度 — 文档结构 + S/E/C 评级 rationale + ASIL→SG 链 + I3 评审

HARA 是 ISO 26262-3 §6 的工作产物,坐在 V-cycle 概念阶段最上游——它的输入唯一来自 Item Definition(系统边界、功能、工况),输出是 Safety Goal 列表,直接喂给 FSC/FSR。这个位置决定了 HARA 报告的两条硬边界:向上,每条 hazard 必须能追到 Item Definition 里的某个功能/工况;向下,每条 ASIL≥A 的 hazard 必须产出至少一条 SG。报告写作的所有规矩,本质都是在守这两条可追溯边界。

下图把 HARA 报告的文档骨架和它在 V-cycle 的上下游接口画在一起——这是写之前先要在脑子里立住的"报告地图"。

写作 SOP 分 5 步,每步产出报告的一个区块,严格按序——后一步的合法性依赖前一步写实:

1. 定范围:从 Item Definition 抄定系统边界与功能清单,声明 HARA 只覆盖这些功能的失效(超出边界的写明 out-of-scope),这是后面"危害识别完整性"的辩护基线。
2. 建工况库:穷举运行工况(车速/道路/载荷/环境),每个工况后面要被 Exposure 评级引用,所以工况库的颗粒度直接决定 E 评级能不能辩护。
3. 危害识别:对每个功能 × 每个工况,问"这个功能失效(漏输出/错输出/非预期输出)会引发什么整车层危害"。
4. S/E/C 评级 + rationale:对每条 hazardous event 评 S/E/C,每个评级必须附一句 rationale(见 §4)。
5. ASIL 推导 + SG 制定:S×E×C 查表得 ASIL,每条 ASIL≥A 产出 SG。

HARA 报告不是一张 S/E/C 表格了事,它是一份有固定骨架的文档,评审方按章核查。下面 7 章是车规项目通行的结构,每章解决一个"可辩护性"问题。

§2 的"假设"是新手最常漏、却被 I3 高频追的一章:Controllability 评级隐含一个"什么样的驾驶员"基准,不写明假设(如"普通持照驾驶员、非职业、反应时间 $>1\text{s}$"),C 评级就失去可复现性。

报告 §4/§5 的最小单元是一条 hazard 条目。一条写不全的条目会让整条 ASIL 推导链断在审计处。7 字段缺一不可:

下图是一条 hazard 条目从工况到 SG 的字段流转——每个字段是后一个字段的合法性前提,断一格则该条 ASIL 不可辩护。

7 字段 + 主驱"非预期扭矩"worked(摘自 HARA worked,这里聚焦怎么写):

• ① 运行工况:高速公路巡航 120 km/h(引 §3 工况库条目号,不另起)
• ② 功能失效模式:扭矩控制功能 — 非预期输出(车辆请求 0 但实际输出正扭矩)(用 漏/错/非预期 三分,别写"故障")
• ③ hazardous event:车辆非预期加速,可能追尾前车(整车层后果,非器件层)
• ④ Severity + rationale:S3 — 高速追尾,AIS 3-4 致命伤可能,引 ISO 26262-3 Annex B Table B.1
• ⑤ Exposure + rationale:E4 — 高速巡航是常态工况,LV 数据占行驶时间 >10%,引 §3 工况库
• ⑥ Controllability + rationale:C3 — 突发正扭矩,普通驾驶员难在 FTTI 内反应避险,无旁路
• ⑦ ASIL + SG:S3×E4×C3 → ASIL D;SG: 防止非预期驱动扭矩 > ±10% 额定,FTTI 100 ms,安全状态 = 扭矩关断(STO)

注意 ④⑤⑥ 的 rationale 都做了两件事:给数值 + 引依据(Annex B 表 / 工况库 / driver 假设)。这正是 I3 区分"可辩护评级"和"拍脑袋"的唯一抓手。

这是 HARA 写作的真正难点,也是 I3 评审花时间最多的地方。从第一性原理看,S/E/C 是把一团连续主观的风险压成离散等级(详见每日深讲 FS-A2),压缩必然丢信息——rationale 就是把丢掉的判断依据补回报告、让它可复现。

可辩护的 rationale 有一个固定句式:「等级 + 量化锚点 + 引用来源」。三者缺一就被追:

• 只写等级(S3)→ I3 追"凭什么"
• 写等级+量化(S3,因为高速碰撞)→ I3 追"高速是多少、伤害等级依据"
• 写全(S3 — 相对速度 >60 km/h 追尾,AIS 3-4 危及生命,依 Annex B Table B.1 S3 定义)→ 站得住

三个维度各有易错点。S 要锚到 AIS 医学伤害等级,别用"很严重"这类形容词。E 最常见的致命错误是把"故障频率"当成"工况暴露频率"——E 评的是"车多常处于这个危险工况"(如高速巡航占行驶时间比例),不是"故障多常发生";依据来源是车队/实测行驶 profile、GIDAS 等行驶统计或 SAE J2980 指引(不是 LV124 —— 那是低压电气零部件试验标准,不含工况暴露频率)。C 要写明 driver 基准(§2 假设)且用"普通驾驶员"——假设成赛车手会系统性低估 C、压低 ASIL,是 I3 重点狙击的降级手法。

光说句式不够。下面三维各举一条**「被 I3 打回 → 它会追什么 → 改成站得住」**,关键洞察是:差别往往不在评级数字对错,而在写法扛不扛得住追问——同一个 S3,写法不对照样判 NC。

Severity — 打回写法 S3,高速很危险(形容词、无锚点)。I3 追:"多高速?什么伤害?依哪条?" 站得住写法 S3 — 相对速度 >60 km/h 追尾、乘员舱侵入风险,AIS 3-4 危及生命,依 Annex B Table B.1 S3 定义。差别:后者把"危险"翻成 可查速度 + 医学等级 + 标准表条目,三个抓手都能被第三方复核。

Exposure — 打回写法 E4,这个故障很常见。这不是"写不细",是概念错:把故障频率当成了暴露度,I3 一眼判错、整条 ASIL 推导失去信任。站得住写法 E4 — 高速公路巡航属常态运行工况,依车队行驶 profile / GIDAS 行驶统计占典型行驶时间 >10% 归 E4;此处评车辆处于该工况的频率,与故障发生率无关。差别:后者锚定"工况暴露"并显式撇清"非故障率"——主动堵住评审最爱追的那个混淆。

Controllability — 打回写法 C2,有经验的驾驶员能及时反应。这是最隐蔽的降级手法:偷换驾驶员基准、抬高可控性、把 ASIL 从 D 压到 C,省下大量冗余成本——也正因如此是 I3 重点狙击区。站得住写法 C3 — 突发正扭矩无预兆,普通持照驾驶员(§2 假设:非职业、反应时间 >1 s)在 100 ms FTTI 窗口内无法反应避险,且无机械旁路。差别:后者用 §2 写定的基准 + FTTI 时间账,把"能不能控"变成可推导的对比,而非主观判断。

三组的共性,就是 rationale 写作的终极标准:把一个主观判断,降维成"换个人拿你引的依据、能复算出同一个评级"的客观链。不是"理由充分",是"可被第三方复现"。

§6 的 ASIL 推导本身是机械查表(S×E×C 三维查 ISO 26262-3:2018 Table 4,clause 6.4.3.7 的规范性矩阵;Annex B 是 S/E/C 各自的分类表 B.1/B.2-B.3/B.4,B.4 是 Controllability 不是 ASIL 矩阵),写作要点只有一个:QM 判定必须显式留痕。落到 QM 的条目不能直接删,要写明"S0 / E0 / C0 之一 → QM,理由 X",否则 I3 无法区分"评估后判 QM"和"漏识别"——后者是致命 NC。

§7 的 Safety Goal 是 HARA 向下交付的接口,每条 SG 必须含 4 要素,缺了 FSC/FSR 就接不住:① 安全意图(防止什么,如"防止非预期驱动扭矩 > ±10%")② ASIL(继承自对应 hazard)③ 安全状态(达成后系统进入的可控态,如 STO / ASC)④ FTTI(故障容错时间,如 100 ms——它会向下被 FTTI 预算分解 拆到采样率)。每条 SG 还要标一个唯一 ID(如 SG-01),供 FSR 反向 link——这是 FSR/TSR 写作 那一环能闭合 traceability 的前提。

I3 评审 HARA(M1 里程碑)有固定的查点清单。下图把 6 个查点映射到报告对应章节,自检时逐项过。

6 个查点:

1. 完整性:覆盖功能集 = Item Definition 功能集?有无功能漏识别危害?
2. 可追溯:每条 hazard 上接 Item Def 某功能/工况、每条 SG 下有 FSR 引用?
3. 工况充分:§3 工况库是否覆盖会暴露危害的所有运行场景?
4. 评级 rationale:每个 S/E/C 是否「等级+量化+引用」三件套齐全?
5. QM 留痕:落 QM 的条目是否写明判定理由(非漏识别)?
6. SG 四要素:每条 SG 是否含 意图/ASIL/安全状态/FTTI + 唯一 ID?

这 5 种写法是 HARA 报告被退回的高频原因,且都不是"评错了",而是"写不对":

第一,评级无 rationale——只填 S3/E4/C3 不写依据,占 NC 的大头。第二,hazardous event 写成器件层(如"MOSFET 短路")而非整车层("非预期加速")——HARA 评的是整车危害,器件失效是后面 FMEDA 的事。第三,Exposure 用故障频率——把"这个故障多常发生"当 E,根本性混淆(E 是工况暴露)。第四,Controllability 假设赛车手——隐性抬高可控性、压低 ASIL,降级无依据。第五,QM 条目直接删除——评估后判 QM 不留痕,I3 无法和"漏识别"区分,反而比写出来更危险。

一份可提交 I3 的 HARA 报告,落地时按此清单自检:

• 7 章骨架齐全,§2 写明评级标准 + driver 假设
• 每条 hazard 7 字段完整,S/E/C 三件套 rationale
• ASIL 查表结果 + QM 判定留痕
• SG 列表每条 4 要素 + 唯一 ID,向下有 FSR link 占位
• 向上每条 hazard 引 Item Definition 功能/工况号
• 过完 §6 的 6 个 I3 查点自检

HARA 报告被退回或被 I3 判 NC,90% 的原因集中在以下 7 条。每条给出:陷阱 → 根因 → 正确做法。

Gotcha-1:E 评引用 LV 124 而非行驶统计。LV 124(大众低压电气零部件试验规范)规定的是工作电压 / 温度 / 振动试验条件,里面没有工况暴露频率数据。把 LV 124 的试验比例当 E 评依据,一眼被 I3 识别为来源错误,整列 E 评失去可信度。正确依据是车队实测行驶 profile / GIDAS 行驶统计 / SAE J2980(《Considerations for ISO 26262 ASIL Hazard Classification》,给出 S/E/C 分类的量化指引)。

Gotcha-2:hazardous event 写到器件层。"IGBT 短路"、"CAN 报文丢失"、"栅极驱动电压跌落"——这些是零部件 / 接口失效,不是整车危害。HARA 的粒度是整车层(乘员 / 路人 / 救援人员的人身安全),器件层是 FMEDA / TSR 的事。写到器件层的直接后果:I3 无法判定 S/E/C(S 评的是对人的伤害,而非电路损坏)。正确起点:先写整车后果("车辆非预期加速"),再在 §2 写明"如何从功能失效到整车后果"的推理链。

Gotcha-3:QM 条目静默删除。把推导结果为 QM 的 hazard 直接从报告里删掉,只留 ASIL A-D 的条目。I3 无从区分"评估后判 QM"和"漏识别危害"——后者是比 QM 更严重的 NC。正确做法:QM 条目必须保留一行,写明"S0/E0/C0 哪个使其落 QM + 简述理由"。静默删除反而比留下更危险。

Gotcha-4:C 评预设专业驾驶员降级。"有经验的驾驶员能在 2 s 内制动"——这句话隐性把 C 从 C3 降到 C2,进而可能把 ASIL D 压到 ASIL C,省下大量冗余成本。I3 的标准追问:"你的驾驶员基准写在哪?"——如果 §2 没有明确写"普通持照驾驶员、非职业、反应时间 > 1 s",C 评就失去可复现基准,I3 会要求返工。一旦被追到降级意图,整份报告公信力受损。

Gotcha-5:FTTI 直接抄 100 ms 不溯源。100 ms 是汽车功能安全领域的常见参考值,但它来自对特定场景(高速驾驶员反应 + 制动建压)的系统分析。不同 Item 的 FTTI 应当从人机交互时间 + 物理过程反算,而非通用默认。"我们参考行业经验取 100 ms"无法让 I3 认可——他们会要求你展示推导。对 L3+ 自动驾驶 Item,更短的 FTTI 才合理(见 §10 Corner-1)。

Gotcha-6:多工况合并导致保守性丢失。"城区低速 + 高速公路"合并写成一个 OC,E 评取"混合平均"——表面上简化了表,实际上把高速工况的 E4 和低速工况的 E3 都降到了一个居中的 E3,导致高速场景被低估。正确做法:一个 OC = 一个具体工况场景,不同 E 评的场景必须拆行;合并行若向高值取(保守)在 ASIL 矩阵里可接受,但向低值取的合并(高低速混合取低)是 NC。

Gotcha-7:ASIL 分解在 HARA 层出现。有的 HARA 文档在 §7 SG 下面直接写"SG-01 ASIL D 分解为 SG-01a ASIL C + SG-01b ASIL C"——这不对。ASIL 分解的方法规范在 ISO 26262-9:2018 Clause 5,且分解的对象是安全需求(FSR/TSR),Safety Goal 本身的 ASIL 永不变;分解还依赖架构上"充分独立"的元素,而 HARA 阶段尚无架构。HARA 只产出 SG 及其未分解的整体 ASIL;在 HARA 里提前做 ASIL 分解,I3 会要求把分解逻辑迁移到 FSC / 开发阶段并补独立性论证。

以下三条边界情形是 worked 表覆盖不到、却在真实项目里反复出问题的角落。

Corner-1:FTTI 压缩 — 自动驾驶 / 高级 ADAS 场景。自动驾驶 L3+ 的 Item,在高速场景下驾驶员不再监视驾驶任务,人的 controllability 实质退出——C 评此时取 C3,且 FTTI 不再以"驾驶员反应时间"为基础。对 L3 系统,系统 FTTI 由感知 → 判断 → 执行链决定,典型只有几十毫秒量级(工程估计,视传感器采样与规划周期而定;规范性依据看 ISO 21448 SOTIF 对驾驶员退出回路的处理,ISO 26262-3:2018 本身不给 L3 的 FTTI 数值)。这时 HARA 的"OC-1 高速"要重新识别:E 可能更高(L3 默认巡航更多)、C 同样为 C3,但 FTTI 从 100 ms 压到几十毫秒会让向下的 FTTI 分解预算极度紧张——这是 L3 HARA 与 L2 HARA 最大的结构差异,新手往往直接抄 L2 的 100 ms。

Corner-2:OTA 软件升级后 HARA 是否需要再版。实车量产后 OTA 推送新控制算法(如扭矩策略更新),原 HARA 覆盖的功能 F1 发生变化——Item Definition 是否变更?变更了就需要对 changed functional behavior 重新跑 HARA impact analysis;如果 OTA 只改参数不改功能,则 HARA 可能 unchanged,但必须有明确的 change impact assessment 结论。变更管理的规范在 ISO 26262-8:2018 Clause 8。这个边界在量产项目中常被忽略:OTA 团队认为"软件升级不影响安全",但 I3 会查 change management 有没有正式判定 HARA unchanged。

Corner-3:E4/S1 组合"本能觉得需要措施"但落 QM。E4(常见工况)+ S1(轻微伤)+ C1(容易控制)按 ISO 26262-3:2018 Table 4 index-sum = 6 落 QM——无需 ISO 26262 安全措施。工程直觉说"这个场景很频繁,不管好像不对",但 HARA 方法的正确答案是:QM 不意味着不采取措施,只意味着 ISO 26262 不做要求。工程团队仍可基于其他法规(UNECE 法规 / 企业质量要求 / OEM 要求)为 QM 场景设计措施——区别在于这些措施不进 ISO 26262 安全案例,不受 Part 5/6 验证要求约束。在 I3 评审时,如果把 QM 场景的措施误写入 Safety Goal,反而会引出"这条 SG 有 ISO 26262 ASIL 吗"的追问。