📚 课程目录第2章危害分析与风险评估(HARA)

2、危害分析与风险评估（HARA）：运行场景定义、危害识别、风险评估方法、安全目标制定

HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统在什么情况下会出事？出事有多严重？我们该怎么防止它出事？

我刚开始做功能安全那会儿，总觉得 HARA 就是走个过场，填几张表格完事。直到有一次项目评审，被安全专家问住：「你这个危害场景的暴露概率是怎么估的？」——嗯，从那以后，我再也不敢轻视 HARA 了。

  核心观点：HARA 不是文档任务，而是安全设计的起点。你花在 HARA 上的每一分钟，都会在后续开发中省下十倍的时间。

2.1 运行场景定义：先搞清楚车在干什么

做 HARA 之前，必须先定义「运行场景」。什么叫运行场景？就是车辆在什么环境下、以什么模式、执行什么操作。

我个人习惯把运行场景拆成三个维度：

车辆状态：上电、下电、行驶、驻车、滑行、充电
环境条件：晴天、雨天、雪天、夜间、隧道、高海拔
驾驶员行为：正常驾驶、误操作、无操作、紧急操作

举个例子，电驱控制器的一个典型运行场景：

场景 ID: SC-001
车辆状态: 行驶中（车速 60 km/h）
环境条件: 雨天，路面湿滑
驾驶员行为: 正常加速
系统模式: 扭矩控制模式

为什么要定义这么细？因为同一个故障，在不同场景下造成的后果完全不同。我在项目中遇到过，一个过流故障在低速时只是限功率，在高速时就可能引发车辆失控。

我的经验：运行场景不要少于 10 个，也不要超过 30 个。太少会遗漏关键场景，太多会让后续分析变得臃肿。我一般先列 15 个左右，评审时再补充。

2.2 危害识别：找到那些「万一」

危害识别，就是找出系统在哪些情况下会「出问题」。这里的「问题」不是指零件坏了，而是指系统行为违背了安全预期。

电驱控制器常见的危害类型：

危害类别	具体表现	典型原因
非预期加速	驾驶员未踩油门，车辆自行加速	扭矩指令错误、传感器漂移
非预期减速	行驶中突然失去动力或制动	逆变器故障、过流保护误触发
方向失控	电机输出扭矩导致车辆偏转	左右轮扭矩不一致
高压触电	绝缘失效导致高压暴露	绝缘监测失效、连接器松动
过热起火	电机或控制器过热	冷却系统失效、过载运行

识别危害时，我建议用头脑风暴 + 检查表的组合方式。先让团队自由发散，再用检查表查漏补缺。我曾经在一个项目中，就是因为检查表里有一条「是否考虑过充电场景下的危害」，才发现了高压互锁的漏洞。

避坑指南：不要只盯着「最坏情况」。有些危害在单一故障下不严重，但加上第二个故障就致命了。我习惯在危害识别阶段就标注「单点故障」和「多点故障」的区分。

2.3 风险评估方法：量化你的担忧

风险评估，就是把每个危害的「严重度」、「暴露概率」和「可控性」打上分。ISO 26262 给了我们一套标准方法。

三个评估维度：

S（Severity）严重度：对人员伤害的严重程度，S0~S3
E（Exposure）暴露概率：运行场景发生的频率，E0~E4
C（Controllability）可控性：驾驶员或其他人控制风险的能力，C0~C3

打分不是拍脑袋，要有依据。我一般会这样做：

S 级评估：参考事故统计数据。比如非预期加速在高速场景下，S 至少给 S2。
E 级评估：看场景的日常出现频率。雨天行驶在中国南方，E 值肯定比北方高。
C 级评估：考虑驾驶员的反应时间和能力。比如突然失去动力，大多数驾驶员无法在 1 秒内做出正确反应，C 值给 C2 或 C3。

打分完成后，用公式 ASIL = f(S, E, C) 确定安全等级。ASIL 分为 A、B、C、D 四级，D 级最严格。QM（Quality Management）表示不需要额外安全措施。

关键表格：ASIL 等级判定矩阵

S	E	C1	C2	C3
S1	E1	QM	QM	QM
S1	E2	QM	QM	ASIL A
S1	E3	QM	ASIL A	ASIL B
S1	E4	ASIL A	ASIL B	ASIL C
S2	E1	QM	QM	ASIL A
S2	E2	QM	ASIL A	ASIL B
S2	E3	ASIL A	ASIL B	ASIL C
S2	E4	ASIL B	ASIL C	ASIL D
S3	E1	ASIL A	ASIL B	ASIL C
S3	E2	ASIL B	ASIL C	ASIL D
S3	E3	ASIL C	ASIL D	ASIL D
S3	E4	ASIL D	ASIL D	ASIL D

你想想看，如果一个危害的 S=3、E=3、C=2，查表得到 ASIL D。这意味着什么？意味着你需要最严格的安全措施，从硬件到软件都要冗余设计。

我的习惯：打分时不要一个人定。拉上系统工程师、硬件工程师、软件工程师一起评审。不同视角能发现你忽略的细节。有一次软件工程师指出，某个故障在特定软件版本下可控性更高，我们就把 C 值从 C3 降到了 C2。

2.4 安全目标制定：把「不要出事」变成可执行的要求

安全目标，就是把危害分析的结果，转化成系统必须满足的安全要求。每个危害至少对应一个安全目标。

安全目标的写法有讲究：

格式：系统应避免 [危害描述]，在 [运行场景] 下。
等级：继承自危害的 ASIL 等级。
可验证：目标要能通过测试或分析来确认是否达成。

举个例子：

安全目标 ID: SG-001
关联危害: 非预期加速（S2, E3, C2 → ASIL B）
目标描述: 电驱控制器应避免在驾驶员未请求的情况下输出驱动扭矩。
安全等级: ASIL B
验证方法: 故障注入测试 + 扭矩监控覆盖率分析

制定安全目标时，我有一条原则：一个目标只解决一个问题。不要把多个危害合并到一个目标里，否则后续的分解和验证会非常混乱。

避坑指南：安全目标不要写得太「虚」。比如「系统应保证安全」这种话，没法验证。要写具体，比如「系统应在 100ms 内检测到扭矩偏差超过 10% 并进入安全状态」。

2.5 HARA 全流程框架图

下面这张图，是我做 HARA 时常用的流程框架。它把整个 HARA 过程串起来了，从场景定义到安全目标输出，每一步都清晰可见。

这张图我每次做 HARA 都会贴在白板上。它帮我理清了思路，也方便跟团队对齐。你想想看，如果没有这个框架，很容易在某个环节钻牛角尖，或者遗漏关键步骤。

2.6 实战中的几个坑

最后，分享几个我在项目中踩过的坑：

坑一：场景定义太粗。只写「行驶中」，不写车速、路况、天气。结果评审时被追问「高速和低速的暴露概率一样吗？」——嗯，确实不一样。
坑二：危害识别漏了「非功能」危害。比如电磁干扰导致传感器误报，或者软件升级时的安全漏洞。这些也要纳入 HARA。
坑三：安全目标写成了「设计需求」。比如「系统应使用双核 MCU」——这不是安全目标，是设计实现。安全目标只关心「要避免什么」，不关心「怎么实现」。

我的建议：HARA 文档不是一次写完就完事了。随着项目推进，你会发现新的场景、新的危害。我习惯在每个里程碑节点（如系统需求评审、架构设计评审）都 revisit 一次 HARA，看看有没有需要更新的地方。

好了，HARA 的核心内容就这些。记住，HARA 不是文档负担，而是你安全设计的「导航仪」。花时间把 HARA 做扎实，后面的路会好走很多。