1. HARA基础概念：什么是HARA？为什么需要HARA？HARA在ISO 26262中的位置
1.1 什么是HARA？
HARA，全称是 Hazard Analysis and Risk Assessment，中文叫「危害分析与风险评估」。说白了，它就是一套系统化的方法，用来找出汽车电子系统中可能存在的危险，然后评估这些危险到底有多严重。
我刚开始接触功能安全时，觉得HARA就是个走流程的文档工作。后来在项目中吃过亏，才明白这玩意儿有多重要。嗯，这里要强调一下：HARA不是纸上谈兵，它是整个功能安全开发的基石。
HARA要回答三个核心问题：
- 什么东西会出问题？——识别潜在的危害事件
- 问题有多严重？——评估危害的严重度、暴露率和可控性
- 需要做到多安全？——确定ASIL等级，指导后续开发
核心要点：HARA的输出是安全目标（Safety Goals），每个安全目标都对应一个ASIL等级。这个等级直接决定了你后续要用多严格的方法来开发。
1.2 为什么需要HARA？
你想想看，一辆车上装了上百个ECU，几十万行代码。如果某个功能出了问题，比如刹车突然失灵、转向突然卡死，后果是什么？
HARA存在的意义，就是提前把这些「万一」找出来。我在一个项目中遇到过这样的情况：团队觉得某个功能很简单，没必要做HARA。结果测试时发现，在特定工况下系统会输出错误指令。幸亏是台架测试，要是上了路……
具体来说，HARA有三大作用：
- 合规要求——ISO 26262明确要求，所有相关项（Item）必须进行HARA
- 风险量化——把模糊的「不安全」变成具体的ASIL等级，让团队知道该花多大力气
- 开发指南——安全目标直接指导系统设计、硬件开发和软件开发
注意：千万不要把HARA当成一次性的文档工作。我见过有些团队做完HARA就扔一边了，结果后期设计变更时才发现安全目标对不上。HARA应该是活的，要随着设计迭代持续更新。
1.3 HARA在ISO 26262中的位置
ISO 26262把开发流程分成了多个部分。HARA出现在第3部分（Part 3）——概念阶段。具体位置是这样的：
| ISO 26262 部分 | 内容 | HARA的关联 |
|---|---|---|
| Part 1 | 术语 | 定义HARA相关概念 |
| Part 2 | 功能安全管理 | 定义HARA的流程要求 |
| Part 3 | 概念阶段 | HARA就在这里 |
| Part 4 | 系统级开发 | 基于HARA结果进行系统设计 |
| Part 5 | 硬件级开发 | 实现安全目标 |
| Part 6 | 软件级开发 | 实现安全目标 |
从这张表能看出来，HARA是承上启下的关键节点。它把「需求」变成了「技术要求」。我个人习惯把HARA比作一个漏斗——上面是各种可能的危险场景，下面是具体的安全目标和ASIL等级。
1.4 HARA的输入和输出
做HARA之前，你得先准备好几样东西：
- 相关项定义（Item Definition）——你要分析的系统到底是什么？边界在哪里？
- 功能清单——系统有哪些功能？每个功能在什么场景下使用？
- 运行场景——车辆会在什么环境下运行？高速、城市、雨天、夜间？
HARA做完之后，你会得到：
- 危害事件列表——每个危害事件对应一个潜在的危险
- ASIL等级——每个危害事件的严重度（S）、暴露率（E）、可控性（C）
- 安全目标——每个危害事件对应的安全要求
我的经验：做HARA时，场景分析一定要做细。我曾经在一个项目中，只考虑了「正常驾驶」场景，结果忽略了「维修模式」下的操作。后来发现维修人员误操作会导致系统进入不安全状态。从那以后，我要求团队必须列出所有可能的运行模式和场景。
1.5 一个简单的HARA示例
为了让你更直观地理解，我拿「电子助力转向系统（EPS）」举个例子：
危害事件：车辆行驶中，EPS意外输出反向助力
运行场景：车辆以60km/h在城市道路直行
潜在后果：驾驶员难以控制车辆方向，可能导致碰撞
评估参数：
- 严重度（S）：S3（危及生命的伤害）
- 暴露率（E）：E4（每次驾驶都可能发生）
- 可控性（C）：C2（一般驾驶员难以控制）
ASIL等级：ASIL D（S3+E4+C2 → ASIL D）
安全目标：防止EPS在行驶中输出反向助力
- ASIL等级：ASIL D
- 安全状态：切断助力，回到机械转向模式
- 故障容错时间间隔：≤100ms你看，一个简单的HARA分析，就能把模糊的「转向可能出问题」变成具体的「ASIL D，故障容错时间100ms」。这就是HARA的价值所在。
1.6 常见误区
最后，我总结几个做HARA时容易踩的坑：
- 误区一：HARA是安全工程师的事——其实需要系统工程师、软件工程师、硬件工程师一起参与
- 误区二：ASIL等级越高越好——ASIL D意味着更高的开发成本和更长的周期，合理分配才是关键
- 误区三：HARA做一次就够了——设计变更、场景变化都要重新审视HARA
避坑指南：我曾经见过一个项目，团队为了省事，把所有功能都标成了ASIL B。结果审核时被问得哑口无言——「为什么刹车和车窗是同一个安全等级？」所以，老老实实按流程做，别想着走捷径。
好了，这一章的内容就到这里。HARA是整个功能安全开发的起点，也是最重要的一步。下一章我们会深入讲HARA的具体执行步骤，包括怎么分析场景、怎么评估参数、怎么确定ASIL等级。到时候我会拿实际项目中的案例来拆解，保证让你学完就能用。