1. HARA基础概念：什么是HARA？为什么需要HARA？HARA在ISO 26262中的位置
各位工程师朋友，咱们今天聊聊HARA。说实话，我刚入行那会儿，听到HARA这个词，第一反应是「这又是什么高大上的术语？」后来做多了项目才明白，HARA其实就是功能安全里最基础、也最关键的一步。
1.1 什么是HARA？
HARA，全称是Hazard Analysis and Risk Assessment，中文叫「危害分析与风险评估」。说白了，就是回答三个问题：
- 车子会不会出危险？（识别危害）
- 这个危险有多严重？（评估风险）
- 我们该怎么应对？（确定安全目标）
举个例子。我参与过一个电动助力转向项目。当时我们做HARA，发现一个场景：高速行驶时，转向系统突然失效，方向盘打不动了。嗯，这显然是个危害。那它有多严重？车速120km/h，转向失效，后果可能是车毁人亡。所以这个危害的ASIL等级直接定到了D级。
核心定义：HARA是一种系统化的方法，用于识别车辆或系统中可能存在的危害，评估这些危害导致的风险，并确定必要的安全措施。
1.2 为什么需要HARA？
你可能会问：「不做HARA行不行？」我告诉你，真不行。
原因有三：
- 合规要求——ISO 26262明确要求，所有功能安全活动必须从HARA开始。没有HARA，你的安全档案就是空中楼阁。
- 风险控制——不做HARA，你根本不知道哪些风险是致命的。我曾经见过一个团队，花了大半年时间做冗余设计，结果HARA一分析，发现他们防范的根本不是最严重的风险。白干了。
- 成本优化——HARA能帮你把资源用在刀刃上。ASIL A级的功能，你没必要用D级的手段去实现。省下来的成本，不香吗？
个人经验：我建议在项目启动阶段就做HARA，哪怕只是初步的。越早发现问题，改起来成本越低。等硬件都定稿了再回头改，那滋味...嗯，你懂的。
1.3 HARA在ISO 26262中的位置
ISO 26262把整个功能安全生命周期分成了几个阶段。HARA出现在哪里？看这张表：
| 阶段 | 活动 | 输出 |
|---|---|---|
| 概念阶段 | 项目定义、HARA、功能安全概念 | 安全目标、功能安全需求 |
| 产品开发阶段 | 系统设计、硬件设计、软件设计 | 技术安全需求、验证报告 |
| 生产与运行阶段 | 生产、运维、报废 | 安全案例、生产安全计划 |
看到了吗？HARA在概念阶段，是功能安全活动的起点。没有它，后面的所有工作都缺乏依据。
具体来说，ISO 26262的第3部分（Part 3）专门讲概念阶段，其中第7章就是HARA。它要求你：
- 定义项目的功能范围
- 识别可能的危害事件
- 评估每个危害的严重度（S）、暴露概率（E）、可控性（C）
- 确定ASIL等级（A、B、C、D或QM）
- 制定安全目标（Safety Goal）
避坑指南：我曾经犯过一个错误——HARA做得太粗，只考虑了正常驾驶场景，忽略了维修保养时的场景。结果审核时被问住了。记住，HARA要覆盖所有合理的运行模式和故障模式，包括误操作。
1.4 一个简单的HARA示例
为了让你更直观地理解，我拿一个刹车系统举个例子：
危害事件：车辆行驶中，刹车踏板踩下后，刹车力不足
场景分析：
- 运行场景：城市道路，车速40km/h，跟车距离10米
- 故障模式：刹车助力失效，制动力下降50%
风险评估：
- 严重度（S）：S3（可能危及生命）
- 暴露概率（E）：E4（每次驾驶都会遇到刹车场景）
- 可控性（C）：C2（驾驶员可以部分控制，但需要技巧）
ASIL等级：S3 × E4 × C2 = ASIL D
安全目标：刹车系统必须保证在助力失效时，仍能提供至少70%的制动力
你看，通过HARA，我们明确了「刹车助力失效」这个危害需要ASIL D级别的安全措施。那后续的设计就要围绕这个目标来展开。
1.5 小结
HARA不是走形式，它是功能安全的基石。我做了这么多年项目，最大的体会就是：HARA做得越扎实，后面的开发越顺畅。别嫌麻烦，这一步省下来的时间，后面会加倍还给你。
下一章，咱们聊聊HARA的具体执行步骤——怎么识别危害、怎么评估风险。到时候我会拿一个真实项目的案例来拆解，保证让你听完就能上手。