1. HARA基础概念：什么是HARA？它在ISO 26262中的位置与作用
各位同学好，我是老张。做功能安全这行十几年了，今天咱们聊聊HARA。
HARA，全称是Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。说白了，就是回答三个问题：
- 这辆车会不会出危险？
- 出了危险有多严重？
- 我们该怎么防？
嗯，就这么简单。但做起来，可没那么简单。
1.1 HARA到底是个啥？
我习惯把HARA理解成功能安全的“第一道安检”。你想想看，一辆车从设计到量产，中间有无数个环节。如果一开始连哪些场景会出问题都没搞清楚，后面做再多测试也是白搭。
HARA的核心输出，是安全目标（Safety Goal）。安全目标是什么？就是一句话：“系统不能干某某事，否则会出人命”。
举个例子：
ACC自适应巡航系统，如果在前车减速时，本车没减速反而加速——这叫“非预期的加速”。
HARA分析后，安全目标可能是：“ACC系统在跟车模式下，不得输出大于驾驶员设定值的正扭矩”。
我在项目中遇到过不少团队，把HARA当成“填表任务”。填完ASIL等级，往文档里一放，就完事了。结果呢？后期测试发现安全目标根本覆盖不全，返工成本高得吓人。
1.2 HARA在ISO 26262中的位置
ISO 26262把开发流程分成了几个阶段。HARA出现在概念阶段，具体位置是第3部分（Part 3）。
我画了张图，帮你理清位置关系：
从图上你能看到：HARA是概念阶段的核心产出。它把项目定义（Part 3.5）里的功能清单，转化成安全目标，然后交给系统级开发（Part 4）去实现。
我的经验：
很多新手问我：“HARA能不能跳过？”我的回答永远是：不能。ISO 26262的认证审核，第一件事就是查你的HARA文档。没有HARA，后面的安全案例全是空中楼阁。
1.3 HARA的核心三要素：S、E、C
HARA里最核心的概念，就是三个参数：
| 参数 | 全称 | 含义 | 等级范围 |
|---|---|---|---|
| S | Severity | 危害的严重度 | S0 ~ S3 |
| E | Exposure | 场景的暴露概率 | E0 ~ E4 |
| C | Controllability | 驾驶员的可控性 | C0 ~ C3 |
这三个参数组合起来，就决定了ASIL等级（Automotive Safety Integrity Level）。
ASIL有四个等级：ASIL A、B、C、D，D是最严格的。还有一个QM（Quality Management），表示不需要额外安全措施，按质量管理做就行。
ASIL等级判定逻辑：
ASIL = max(S, E, C) 的组合查表结果
举个例子：如果 S=3（致命伤）、E=4（高暴露）、C=2（一般可控），查表得到 ASIL C。
如果 S=3、E=4、C=3（不可控），那就是 ASIL D——最严格的等级。
1.4 一个完整的HARA案例
光讲理论没意思。我拿一个真实项目里的例子给你看。
系统：电动助力转向系统（EPS）
功能：根据方向盘转角，输出助力扭矩
我们做HARA时，会列出所有可能的故障模式。其中一个典型场景：
| 分析项 | 内容 |
|---|---|
| 运行场景 | 车辆以80km/h在高速公路上行驶 |
| 故障模式 | EPS控制器失效，输出最大助力扭矩 |
| 危害事件 | 方向盘突然变轻，驾驶员无法控制车辆 |
| S（严重度） | S3（可能导致多车碰撞、致命伤害） |
| E（暴露率） | E4（高速行驶是常见场景） |
| C（可控性） | C2（有经验的驾驶员可能控制，但普通驾驶员很难） |
| ASIL等级 | ASIL D |
| 安全目标 | EPS系统在检测到控制器失效时，必须在100ms内进入安全状态（降低助力至0） |
避坑指南：
我曾经见过一个团队，把EPS的HARA分析做得特别“完美”——表格填得满满当当，ASIL等级也标了。但审核时发现一个问题：他们只分析了“高速”场景，完全没考虑“低速泊车”场景。
低速泊车时，如果EPS突然失效，方向盘打不动，驾驶员可能撞到旁边的车或行人。这个场景的S等级虽然低一些（低速），但E等级很高（每次泊车都会遇到）。
所以我的建议是：场景覆盖要全面，别只盯着最危险的情况。
1.5 HARA的输出物
HARA做完后，你要交付什么？我列个清单：
- 危害清单：所有识别出的危害事件
- 场景描述：每个危害对应的运行场景
- ASIL等级：每个危害的S、E、C评估结果
- 安全目标：每个危害对应的安全目标（含ASIL等级）
- 安全状态：系统进入安全状态的条件和时限
- FTTI（Fault Tolerant Time Interval）：从故障发生到系统进入安全状态的最大允许时间
一个小技巧：
我习惯在HARA文档里加一列“验证方法”。比如某个安全目标，我打算用故障注入测试来验证，还是用形式化分析？提前想好，后面做验证计划时能省不少事。
1.6 常见误区
最后，我总结几个HARA新手容易踩的坑：
- 误区一：把HARA当成一次性工作 —— 实际上，HARA需要迭代。项目后期发现新场景，要回头更新HARA。
- 误区二：ASIL等级定得太低 —— 有些团队为了省钱，故意把S、E、C往低了评。审核时被质疑，反而要花更多时间解释。
- 误区三：安全目标写得太模糊 —— 比如“系统应保证安全”，这种话等于没说。安全目标要具体到“什么条件下，系统做什么事，多长时间内完成”。
- 误区四：忽略安全状态的定义 —— 安全目标里只写了“避免危害”，但没写“系统应该进入什么状态”。比如EPS失效后，是直接断电还是降级运行？这个必须明确。
嗯，HARA的基础概念就讲到这里。记住一句话：HARA不是填表，是思考。你花在场景分析上的每一分钟，都会在后面的开发阶段里回报给你。