一、HARA概述：从系统架构出发的风险识别
1.1 什么是HARA？
HARA，全称是 Hazard Analysis and Risk Assessment。
翻译过来就是「危害分析与风险评估」。
说白了，这是一套系统化的方法。用来找出车辆里可能出问题的地方，然后评估这些问题有多严重。
我刚开始接触功能安全时，觉得HARA就是个填表格的活儿。后来踩过几次坑才明白——HARA是整个功能安全流程的基石。你想想看，如果连风险都没找全，后面的安全措施再严密也是白搭。
HARA要回答三个核心问题：
- 什么东西会出问题？（危害识别）
- 出问题后有多严重？（风险评估）
- 我们需要做到多安全？（安全目标定义）
核心要点：HARA不是一次性的文档工作，它是后续所有安全活动的输入。ASIL等级、安全目标、功能安全概念，全都从这里来。
1.2 HARA在功能安全中的位置
ISO 26262标准里，HARA属于「概念阶段」的核心活动。
整个功能安全流程可以分成几个大块：
| 阶段 | 主要活动 | HARA的角色 |
|---|---|---|
| 概念阶段 | 项目定义、HARA、功能安全概念 | 核心产出 |
| 系统开发 | 技术安全概念、系统设计 | 输入来源 |
| 硬件/软件开发 | 详细设计、测试验证 | 约束条件 |
| 生产与运行 | 生产、维护、报废 | 持续参考 |
我个人的习惯是，在项目启动的第一周就把HARA的初步框架搭起来。为什么？因为HARA的结果会直接影响架构设计。你等到架构都定好了再做HARA，发现某个功能需要ASIL D，但架构只支持ASIL B——那就尴尬了。
避坑提醒：我曾经见过一个项目，团队花三个月把系统架构做完了，然后才开始做HARA。结果发现转向系统的一个关键功能需要ASIL D，但选用的MCU只支持ASIL B。最后只能推倒重来，白白浪费两个月。
1.3 HARA与系统架构的关系
这个问题我问过很多工程师：「你觉得HARA和系统架构，谁先谁后？」
大部分人会回答「HARA先，架构后」。
嗯，这个答案对了一半。
实际上，HARA和系统架构是相互迭代的关系：
- 架构为HARA提供输入：你需要知道系统有哪些功能、功能之间怎么交互、传感器和执行器怎么分布，才能做完整的危害分析。
- HARA为架构提供约束：分析出来的ASIL等级、安全目标，会直接决定架构层面的安全机制设计。
举个例子。我在做某个ADAS项目时，先画了一个初步的系统架构图。然后基于这个架构做HARA，发现「自动紧急制动误触发」这个危害的严重度很高。这个发现反过来要求架构上增加「制动请求的合理性校验」和「驾驶员 override 机制」。
你看，架构和HARA就是这样来回迭代的。
我的建议：不要等架构完全定稿再做HARA。先画一个粗粒度的架构草图，跑一遍HARA，用结果去优化架构。这样迭代两三轮，架构和HARA就都能落地了。
1.4 HARA的核心目标与价值
HARA的核心目标，我总结成三句话：
- 找出所有合理的危害场景——不是天马行空，而是基于实际使用场景。
- 给每个危害定一个安全等级——也就是ASIL等级，从QM到ASIL D。
- 定义清晰的安全目标——每个危害都要对应一个可验证的安全目标。
那HARA的价值在哪里？
我做了这么多年功能安全，觉得最大的价值是——让安全变得可量化、可管理。
没有HARA之前，大家说「这个系统要做得安全一点」，但「安全一点」是多少？没人说得清。
有了HARA，我们可以说：
- 这个功能需要ASIL B
- 那个功能需要ASIL D
- 这个故障的容忍时间窗口是100ms
这些都是具体的、可执行的指标。
另外，HARA还有一个隐藏价值——沟通工具。
我经常用HARA的结果跟项目经理、客户、供应商沟通。你拿出一张HARA表格，指着某个危害说：「这个场景如果不处理，可能导致严重伤害，所以我们需要投入资源做ASIL D的开发。」
这时候，没人能反驳你。因为这是基于系统化分析得出的结论，不是拍脑袋。
总结一下：HARA不是文档负担，它是功能安全的地基。地基打不好，上面盖的房子再漂亮也是危房。我建议每个做功能安全的工程师，都把HARA当作自己的核心技能来打磨。
好，这一章就到这里。下一章我们聊聊HARA的具体执行步骤——怎么从零开始做一次完整的HARA分析。