3. 危害分析与风险评估（HARA）：从识别到分类的完整实践
各位同学，今天我们进入功能安全概念阶段最核心的一步——HARA。说实话，我见过太多项目在HARA上草草了事，结果到了后期才发现遗漏了关键危害，不得不返工。那种痛苦，经历过的人都懂。
HARA的目的很简单：找出系统所有可能的危害，评估它们的风险，然后确定需要降低到什么程度。但做起来，门道可不少。
3.1 HARA到底在干什么？
我习惯把HARA比作「排雷」。你想想看，一辆车上路，可能遇到各种稀奇古怪的情况——传感器被泥巴糊住、电池在极寒下性能骤降、通信线束被老鼠咬断……这些都可能引发危害。
HARA要做的，就是把这些「雷」一个个找出来，然后判断哪个最危险，需要优先处理。
HARA的核心输出：
- 危害清单（每个危害都有唯一ID）
- 每个危害对应的运行场景
- 危害分类结果（S、E、C等级）
- ASIL等级（QM / A / B / C / D）
- 安全目标（每个危害至少对应一个安全目标）
嗯，这里要注意：HARA不是一次性工作。随着系统设计深入，你会发现新的危害，或者原来的评估需要调整。我在一个ADAS项目中就遇到过，最初认为某个危害是ASIL B，后来场景分析做细了，发现实际应该是ASIL D——还好发现得早。
3.2 危害识别：别漏掉任何一个
危害识别是HARA的第一步，也是最容易出纰漏的一步。我个人的习惯是，先做头脑风暴，再用检查表兜底。
危害从哪里来？说白了，就是功能异常。一个功能该做的时候没做，或者不该做的时候做了，或者做得不对——都可能是危害。
| 功能异常类型 | 举例（电动助力转向EPS） | 潜在危害 |
|---|---|---|
| 功能丧失 | 转向助力突然消失 | 驾驶员无法转向 |
| 功能误触发 | 非预期施加转向力矩 | 车辆偏离车道 |
| 功能输出错误 | 转向角度与实际需求偏差过大 | 车辆失控 |
| 功能时序错误 | 转向响应延迟超过500ms | 避障不及 |
我曾经在一个线控制动项目中，团队只关注了「制动失效」这个危害，却忽略了「非预期制动」——结果在高速场景下，非预期制动可能比制动失效更危险。所以，正反两面都要想。
我的小技巧： 危害识别时，拉上系统工程师、软件工程师、硬件工程师、甚至测试工程师一起开会。不同视角能帮你发现盲区。我见过最离谱的一次，是生产线的师傅指出一个装配环节可能导致的危害——我们设计团队完全没想到。
3.3 运行场景分析：危害不是孤立的
同一个危害，在不同场景下，风险天差地别。举个例子，「动力电池热失控」——在高速隧道里和在地面停车场，后果能一样吗？
运行场景分析，就是要回答三个问题：
- 什么时候会发生？（车辆状态、环境条件）
- 谁会受影响？（驾驶员、乘客、行人、其他车辆）
- 后果有多严重？（可控性如何？）
我建议用场景矩阵来系统化分析。每个危害至少覆盖3-5个典型场景，包括最坏情况场景。
避坑指南： 我曾经见过一个项目，只分析了「正常驾驶」场景，忽略了「低附着力路面」和「系统降级模式」——结果在冰雪测试中暴露了严重问题。记住：场景覆盖不全，HARA就是白做。
下面这张图展示了HARA中危害识别与场景分析的逻辑关系：
3.4 危害分类：S、E、C 三要素
ISO 26262 用三个维度来评估危害的风险等级：
- S（Severity）严重度：伤害有多重？轻伤？重伤？致命？
- E（Exposure）暴露概率：这个场景发生的频率高不高？
- C（Controllability）可控性：驾驶员或其他人员能控制住局面吗？
三个维度组合，查表得到ASIL等级。我刚开始做HARA时，总觉得这个表很死板，后来发现——真正难的不是查表，而是给S、E、C打分。
| 等级 | S（严重度） | E（暴露概率） | C（可控性） |
|---|---|---|---|
| S0 | 无伤害 | — | — |
| S1 | 轻伤（可逆） | — | — |
| S2 | 重伤（可能不可逆） | — | — |
| S3 | 致命 | — | — |
| E1 | — | 极低（<1% 驾驶时间） | — |
| E2 | — | 低（1%~10%） | — |
| E3 | — | 中（10%~50%） | — |
| E4 | — | 高（>50%） | — |
| C1 | — | — | 容易控制 |
| C2 | — | — | 一般可控 |
| C3 | — | — | 难以控制 |
ASIL等级确定规则（简化版）：
- S1 + E1 + C1 → QM（无安全要求）
- S2 + E2 + C2 → ASIL A
- S2 + E3 + C2 → ASIL B
- S3 + E2 + C2 → ASIL C
- S3 + E3 + C3 → ASIL D（最高等级）
实际查表比这个复杂，但逻辑是一样的：越严重、越常见、越难控制，等级越高。
3.5 实战中的几个坑
做了这么多年HARA，我踩过的坑不少，挑几个典型的说说：
- 「S、E、C打分太主观」——同一个危害，不同工程师打分可能差两级。我的建议是：建立团队共识，用历史数据或参考项目做校准。实在拿不准的，往高了打，安全第一。
- 「场景分析不够细」——比如只说「高速行驶」，但高速上有没有弯道？路面湿不湿？车流量大不大？这些都会影响E和C的评估。
- 「忽略组合危害」——两个危害同时发生怎么办？比如制动失效 + 转向卡死。ISO 26262要求考虑独立失效，但实际中相关失效也要留意。
我曾经踩过的坑： 在一个BMS项目中，我们把「电池过温」的E等级打成了E2（低暴露概率），理由是「正常使用很少过温」。结果忽略了快充场景——用户频繁使用快充，过温概率远高于预期。后来被审核老师指出，改成了E3。所以，场景分析一定要覆盖所有合理可预见的用法，包括滥用。
3.6 从HARA到安全目标
每个危害最终都要转化为安全目标。安全目标就是一句话：「系统要避免XXX危害」，并且带上ASIL等级。
举个例子：
- 危害：EPS非预期施加转向力矩，导致车辆偏离车道
- 安全目标：EPS系统应防止非预期的转向力矩输出 [ASIL D]
安全目标要写清楚、可验证。我见过最糟糕的安全目标：「系统要安全」——这等于没写。好的安全目标应该能直接指导后续的功能安全概念设计。
我的习惯： 每个安全目标都加上「可验证」的约束。比如「非预期转向力矩 < 1Nm，响应时间 < 100ms」——这样测试工程师拿到手就知道怎么测。
好了，HARA这部分内容不少，但核心就是三件事：找出危害、分析场景、分类定级。做扎实了，后面的功能安全概念设计才能站得住脚。