1. HARA概述：什么是HARA？为什么需要HARA？HARA在ISO 26262中的位置

各位同学，欢迎来到《自动驾驶域控制器HARA分析全流程实战课程》。我是你们的老朋友，一个在功能安全领域摸爬滚打了十几年的工程师。

咱们第一节课，先聊聊HARA。很多刚入行的朋友问我：“HARA到底是什么？听着挺唬人的。” 嗯，今天我就把这块掰开了、揉碎了讲清楚。

1.1 什么是HARA？

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

说白了，它就是一套系统化的“找茬”流程。找什么茬？找你的自动驾驶系统在出故障时，会不会对车上的人、路上的人造成伤害。

我个人的理解是：HARA就是给系统做一次“安全体检”。

举个例子，你想想看，如果一辆自动驾驶汽车在高速上行驶，突然转向系统失灵了，会发生什么？这就是一个危害事件。HARA要做的，就是把这个事件找出来，然后评估它有多危险。

具体来说，HARA包含三个核心要素：

• 危害识别：找出系统可能出现的各种故障模式，以及这些故障会引发什么后果。
• 风险评估：评估这些危害发生的概率、严重程度，以及驾驶员或系统能否及时控制住局面。
• 安全目标定义：根据风险评估的结果，给系统定一个“安全底线”。比如，“转向系统在任何情况下都不能无故失效”。

1.2 为什么需要HARA？

这个问题问得好。很多公司觉得，我只要把功能做出来，测试通过了，不就行了吗？为什么非要搞这么一套复杂的流程？

我告诉你，原因有三点，而且都很现实。

第一，为了保命。 这不是开玩笑。自动驾驶系统一旦出问题，后果可能是灾难性的。HARA能帮我们在设计阶段就发现潜在的危险，而不是等到车撞了、人伤了才去补救。我在项目中遇到过，一个看似不起眼的传感器故障，如果没有做HARA，很可能导致车辆在十字路口误判，后果不堪设想。

第二，为了合规。 ISO 26262是国际标准，你要想卖车到欧洲、日本这些市场，就必须满足这个标准。而HARA是ISO 26262的起点，是强制要求。没有HARA，你的安全档案就是一张白纸，审核根本过不了。

第三，为了省钱。 你可能会觉得，做HARA要花时间、花人力，是成本。但你想过没有，如果在设计阶段没发现问题，等到样车造出来了、甚至量产了才发现安全漏洞，那修改的成本是几何级数增长的。我曾经见过一个项目，因为前期HARA没做透，后期不得不召回几千台车进行软件升级，那个损失，啧啧，够做几十次HARA了。

1.3 HARA在ISO 26262中的位置

ISO 26262这个标准，很多人觉得它很厚、很复杂。其实它的核心逻辑很简单：从概念到产品，每一步都要考虑安全。

HARA就位于这个流程的概念阶段，具体来说，是在“项目定义”和“安全生命周期启动”之后。

我习惯把ISO 26262的流程想象成一条流水线：

1. 第一步：项目定义 – 你要造一辆什么样的车？有什么功能？
2. 第二步：HARA – 这个功能如果出故障，会有什么危险？有多危险？
3. 第三步：功能安全概念 – 根据HARA的结果，我们怎么设计系统来避免这些危险？
4. 第四步：系统、硬件、软件开发 – 把安全概念落地。
5. 第五步：测试、验证、确认 – 确保系统真的安全了。

你看，HARA是第二步，但它决定了后面所有步骤的“安全目标”。没有HARA，后面的工作就是无头苍蝇。

在ISO 26262的文档体系中，HARA对应的是第3部分（Part 3）。这个部分详细规定了如何进行危害分析、如何评估风险等级（ASIL等级）、如何定义安全目标。

ISO 26262 部分	内容	HARA的关联
Part 1	词汇	定义了HARA相关的术语
Part 2	功能安全管理	规定了HARA活动的管理要求
Part 3	概念阶段	HARA的核心执行部分
Part 4	系统级开发	基于HARA结果进行系统设计
Part 5/6	硬件/软件开发	基于HARA结果进行详细设计

所以，同学们，HARA不是可有可无的“附加题”，它是整个功能安全大厦的地基。地基不稳，楼盖得再高也是危楼。

好了，第一节课就到这里。我们搞清楚了HARA是什么、为什么需要它、以及它在ISO 26262中的位置。下一节课，我会带大家深入HARA的具体执行步骤，包括如何识别危害、如何评估ASIL等级。咱们不见不散。