1. HARA基础概念：什么是HARA？HARA在ISO 26262中的位置与作用

1.1 先聊聊HARA到底是什么

HARA，全称是Hazard Analysis and Risk Assessment，中文叫「危害分析与风险评估」。

说白了，它就是一套系统化的方法。用来干嘛呢？用来找出车辆电子电气系统中可能存在的危害，然后评估这些危害会带来多大的风险，最后确定你需要把安全做到什么等级。

我经常跟团队里的年轻人说：HARA不是做不做的问题，而是怎么做好的问题。因为ISO 26262明确要求，所有功能安全相关的开发活动，都必须从HARA开始。

1.2 HARA在ISO 26262中的位置

ISO 26262把整个开发流程分成了多个部分。HARA出现在哪里呢？

它出现在第3部分——概念阶段。具体来说，是在3-7这个章节。你想想看，整个功能安全开发的起点就在这里。

我画个简单的流程给你看：

项目定义 → 危害分析与风险评估（HARA） → 安全目标 → 功能安全概念 → 技术安全概念 → 硬件/软件开发

看到了吗？HARA是第二步。没有它，后面的安全目标、功能安全概念全都是空中楼阁。

1.3 HARA到底要做什么？三个核心步骤

HARA不是随便分析分析就完事了。它有一套标准化的流程。我个人习惯把它拆成三步：

1. 危害识别（Hazard Identification）：找出系统在故障状态下可能导致的危害
2. 情景分析（Situational Analysis）：分析这些危害会在什么驾驶场景下发生
3. 风险评估（Risk Assessment）：评估危害的严重度、暴露率和可控性，确定ASIL等级

嗯，这里要注意：危害识别不是拍脑袋想出来的。你需要基于系统的功能定义，结合车辆的实际运行场景，系统地分析。

1.4 为什么HARA这么重要？

你可能觉得，不就是做个分析嘛，能有多重要？

我跟你讲，HARA的重要性体现在三个方面：

• 它是安全活动的起点：所有安全需求都源自HARA输出的安全目标
• 它决定了安全等级：ASIL A、B、C、D，还是QM，全看HARA的评估结果
• 它是认证的敲门砖：审核员第一个看的就是你的HARA做没做、做没做好

我曾经见过一个项目，HARA做得马马虎虎，安全目标定义得模棱两可。结果到了后期，硬件团队和软件团队对安全需求的理解完全不一致，返工成本高得吓人。说白了，HARA省下来的功夫，后面都要加倍还回去。

1.5 HARA的输入和输出

搞清楚HARA需要什么、产出什么，你才能知道怎么开始做。

类别	内容
输入	项目定义、功能清单、系统边界、运行场景、已知的故障模式
输出	安全目标列表（每个安全目标含ASIL等级）、危害事件表、风险评估矩阵

这里有个容易踩的坑：输入信息不完整就开干。我曾经在项目初期，项目经理催得紧，系统边界还没完全定义清楚就开始了HARA。结果分析到一半，发现有些功能场景根本不在我们系统的控制范围内，白做了好几天的分析。

1.6 HARA与ISO 26262其他部分的关系

HARA不是孤立存在的。它跟ISO 26262的其他部分紧密相连：

• 与第2部分（安全管理）的关系：HARA的评审需要独立的安全评审员参与
• 与第4部分（系统级开发）的关系：安全目标会分解为功能安全需求，进入系统设计
• 与第8部分（支持过程）的关系：HARA的文档需要按照配置管理的要求进行版本控制
• 与第9部分（ASIL导向和安全分析）的关系：HARA中使用的分析方法（如FMEA、FTA）在第9部分有详细要求

我记得有一次审核，审核员问我：「你们HARA里的ASIL等级是怎么确定的？」我给他看了我们的风险评估矩阵和场景分析记录。他点点头说：「嗯，逻辑清晰，证据链完整。」那一刻我就知道，HARA做得扎实，后面的审核就会顺畅很多。

1.7 小结

HARA是功能安全开发的基石。它帮你回答三个问题：

1. 系统可能出什么故障？（危害识别）
2. 故障发生后会怎样？（情景分析）
3. 需要做到多安全？（风险评估）

你想想看，如果没有HARA，你怎么知道你的安全目标定得对不对？ASIL等级选得合不合理？

所以，别把HARA当成一个走过场的文档任务。它是对你系统安全性的第一次、也是最关键的一次系统思考。做好了，后面的路就好走了。