一、HARA基础概念：什么是HARA？它在功能安全中的位置，与ISO 26262的关系
大家好，我是你们这堂课的讲师。咱们直接开门见山——HARA，全称是 Hazard Analysis and Risk Assessment，中文叫「危害分析与风险评估」。
说白了，它就是功能安全里最核心的那一步：找出系统可能出什么危险，然后判断这个危险有多严重，最后决定该不该管、管到什么程度。
我刚开始做功能安全那会儿，总觉得HARA就是个走流程的文档工作。后来在一个ADAS项目里，因为漏掉了一个边缘工况的 hazard，差点导致项目延期三个月……嗯，从那以后，我再也不敢小看HARA了。
1.1 什么是HARA？
HARA不是凭空拍脑袋，它是一套系统化的方法。你想想看，一辆车在路上跑，电子系统万一出故障，会怎样？
- 危害识别：先找出所有可能的危险事件。比如刹车突然失灵、转向助力丢失、电池热失控……
- 风险评估：对每个危险事件，评估它发生的概率、驾驶员能不能避开、后果有多严重。
- 风险等级判定：最后给每个危险定一个等级——ASIL等级（A、B、C、D）或者QM。
核心要点：HARA的输出，直接决定了你的系统需要多高的功能安全等级。ASIL D最高，QM最低。等级越高，开发成本越高，验证越严格。
我个人习惯把HARA比作「体检报告」。你总得先知道身体哪里有问题，才能决定要不要吃药、吃什么药、吃多少剂量。对吧？
1.2 HARA在功能安全中的位置
功能安全开发流程，ISO 26262把它分成了几个阶段。HARA出现在哪里？
我画个简单的流程给你看：
概念阶段 → 危害分析与风险评估(HARA) → 功能安全概念 → 技术安全概念 → 系统/硬件/软件开发 → 验证与确认看到了吗？HARA就在概念阶段之后，功能安全概念之前。它是整个安全开发的起点，也是决策依据。
我记得有一次评审，项目经理问我：「为什么这个模块要花这么多钱做ASIL D？」我直接甩出HARA报告给他看——「你看，这个失效模式会导致车辆失控，后果是致命伤害，你说该不该D？」
所以，HARA不是文档，它是你跟老板、跟客户、跟审核员讲道理的硬通货。
1.3 HARA与ISO 26262的关系
ISO 26262是功能安全的国际标准，专门针对道路车辆。HARA是它里面明确要求的一个活动。
具体来说，ISO 26262的第3部分（Part 3）——概念阶段，里面有一个章节专门讲HARA。标准编号是ISO 26262-3:2018，条款7。
标准里规定了HARA必须包含的内容：
| ISO 26262要求 | HARA对应活动 |
|---|---|
| 识别危害事件 | 功能失效分析、场景分析 |
| 评估风险等级 | 严重度(S)、暴露概率(E)、可控性(C) 三要素打分 |
| 确定安全目标 | 每个危害事件对应一个安全目标 |
| 分配ASIL等级 | 根据S、E、C组合查表得到ASIL |
小提示：ISO 26262并没有规定HARA必须用什么格式。你可以用Excel、用专门的工具、甚至用白板画——只要内容完整、可追溯、可评审就行。我见过最奇葩的HARA是用思维导图做的，但人家审核也过了。
1.4 避坑指南
做HARA这么多年，我踩过不少坑。分享几个最常见的：
- 场景不够全：只考虑正常驾驶，忽略了低速、倒车、坡道、雨雪天气。我曾经在一个项目中漏掉了「车辆在冰雪路面行驶时，ESC系统误触发」的场景，后来被审核员揪出来，补了三天分析。
- 严重度评估过于乐观：总觉得「驾驶员能反应过来」。但你要知道，有些场景下驾驶员根本来不及反应，比如高速爆胎。
- 可控性评估过于悲观：反过来，有些场景其实驾驶员很容易控制，你却给了C3（不可控），导致ASIL等级虚高，成本白白增加。
警告：HARA不是一次性工作。当系统设计变更、新增功能、或者发现新的失效模式时，必须重新做HARA。我见过一个项目，因为省了这一步，最后在功能安全审计时被开了严重不符合项，整个项目延期半年。
1.5 小结
好了，咱们总结一下今天的内容：
- HARA = 危害分析 + 风险评估，是功能安全的起点。
- 它在概念阶段之后、功能安全概念之前，承上启下。
- ISO 26262第3部分明确要求做HARA，并且规定了S、E、C三要素的评估方法。
- HARA的输出是安全目标 + ASIL等级，直接指导后续开发。
下一章，我会带你手把手做一个完整的HARA案例。咱们从场景分析开始，一步步走到ASIL等级判定。到时候你会发现，HARA其实没那么玄乎，就是一套逻辑清晰的思考框架。
我是你们的讲师，咱们下节课见。