3. 危害分析与风险评估（HARA）方法
各位工程师朋友，咱们今天聊聊HARA。说实话，HARA是整个功能安全开发的基石。你想想看，如果连风险都没搞清楚，后面的安全措施设计得再漂亮，那也是空中楼阁。我个人习惯把HARA比作「看病」——你得先诊断出病因，才能开药方。
HARA的核心目标就三个：识别危害、评估风险、确定安全目标。说白了，就是搞清楚「什么东西会坏」、「坏了有多严重」、「我们该怎么办」。
核心要点：HARA不是一次性工作，它需要在整个开发周期中迭代更新。我见过不少项目，前期HARA做得马马虎虎，后期改得痛不欲生。
3.1 HAZOP方法（危险与可操作性分析）
HAZOP，全称Hazard and Operability Study。这个方法最早是从化工行业来的，后来被汽车行业「借」过来用。它的核心思路是：用引导词去「拷问」系统。
常用的引导词包括：无、多、少、部分、相反、异常等。比如你分析一个刹车系统，就可以问：「如果刹车压力无了会怎样？」「如果刹车压力多了会怎样？」
我在项目中遇到过一件事：用HAZOP分析一个电池管理系统，引导词「反向」触发了我们对电流反向流动的思考，结果发现了一个之前完全没注意到的危害——充电时继电器粘连导致电池过放。嗯，这个案例让我对HAZOP刮目相看。
我的建议：HAZOP适合在系统架构设计阶段使用，最好组织一个跨职能团队（系统、硬件、软件、测试）一起做。一个人闷头分析，容易漏掉关键点。
3.2 FMEA方法（失效模式与影响分析）
FMEA，大家应该不陌生。它关注的是「某个部件坏了会怎样」。FMEA有两种常见形式：
- DFMEA（设计FMEA）：分析设计层面的失效
- PFMEA（过程FMEA）：分析制造/装配过程的失效
FMEA的典型输出是一个表格，包含：失效模式、失效原因、失效影响、严重度（S）、发生度（O）、探测度（D）、风险优先数（RPN = S × O × D）。
举个例子，一个简单的电机驱动电路：
| 失效模式 | 失效原因 | 失效影响 | S | O | D | RPN |
|---|---|---|---|---|---|---|
| MOSFET短路 | 过压击穿 | 电机失控 | 9 | 3 | 4 | 108 |
| 电流采样电阻开路 | 焊接不良 | 过流保护失效 | 7 | 2 | 5 | 70 |
注意：我曾经犯过一个错误——把RPN的阈值设得太低，结果满屏都是「高优先级」，根本分不清主次。后来我学乖了：RPN只是一个参考，真正决定优先级的是严重度S。如果S=9或10，哪怕RPN不高，也必须处理。
3.3 FTA方法（故障树分析）
FTA是自上而下的分析方法。它从一个顶事件（比如「刹车失效」）出发，逐层往下分解，直到找到最基本的失效原因。
FTA用逻辑门（与门、或门）连接事件。举个例子：
刹车失效（顶事件）
├── 或门
│ ├── 机械故障
│ │ ├── 刹车片磨损
│ │ └── 制动液泄漏
│ └── 电子故障
│ ├── 传感器失效
│ └── ECU无输出
│ └── 与门
│ ├── 电源故障
│ └── 软件死锁
FTA的好处是：能直观地看到失效路径。你想想看，如果某个顶事件需要「A失效且B失效」才会发生，那它的概率就比「A失效或B失效」低得多。这对我们分配安全要求很有帮助。
避坑指南：我曾经用FTA分析一个ADAS系统，结果树画了整整三页A3纸。后来发现，很多分支其实根本不可能同时发生。记住：FTA要聚焦在合理的最坏情况，别钻牛角尖。
3.4 STPA方法（系统理论过程分析）
STPA是相对较新的方法，它基于系统理论，关注的是「控制问题」而不是「部件失效」。说白了，STPA认为很多事故不是因为某个零件坏了，而是因为控制逻辑本身有问题。
STPA的核心步骤：
- 定义系统边界和损失
- 建立控制结构图
- 识别不安全控制行为（UCAs）
- 分析原因和场景
举个例子，自适应巡航系统：如果控制器在「前车减速」时给出了「不减速」的控制指令，这就是一个不安全控制行为。哪怕所有传感器都正常，这个行为本身也是危险的。
我个人觉得，STPA特别适合分析软件密集型系统和人机交互场景。传统FMEA在这类场景下往往力不从心。
3.5 HARA实施步骤与输出物
好了，前面讲了各种方法，现在咱们说说HARA到底怎么做。我把它总结为六个步骤：
- 定义项目范围：搞清楚你要分析什么系统，边界在哪
- 功能描述：列出系统的所有功能，包括正常功能和异常功能
- 危害识别：用HAZOP、FMEA、STPA等方法找出危害
- 危害场景分析：描述危害发生的具体场景（谁、什么时间、什么条件下）
- 风险评估：评估严重度（S）、暴露率（E）、可控性（C），计算ASIL等级
- 安全目标定义：为每个危害定义安全目标，包括ASIL等级和功能要求
输出物主要包括：
- 危害分析报告：记录所有危害、场景、风险评估结果
- 安全目标列表：每个危害对应的安全目标及ASIL等级
- HARA矩阵：一个汇总表，方便评审和追溯
关键输出物示例：
| 危害ID | 危害描述 | 场景 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|---|
| H-001 | 非预期加速 | 高速公路上，驾驶员未踩油门 | 3 | 2 | 3 | C | 防止非预期加速超过0.3g |
| H-002 | 转向助力丧失 | 低速泊车时 | 2 | 3 | 2 | A | 转向助力丧失时提供机械备份 |
3.6 知识体系总览
为了让你更直观地理解这些方法之间的关系，我画了一张图：
这张图展示了HARA的核心逻辑：从目标出发，选择合适的方法，最终产出可追溯的文档。我个人建议，在实际项目中不要拘泥于某一种方法。比如，我习惯先用HAZOP做一轮「头脑风暴」，再用FMEA做详细分析，最后用FTA验证关键路径。STPA则留给那些控制逻辑特别复杂的子系统。
最后提醒一句：HARA的输出物不是用来「交差」的，而是用来指导后续开发的。我见过太多团队，HARA报告写得漂漂亮亮，但开发过程中根本没人看。记住：安全目标是设计约束，不是文档装饰。
公众号:蓝海资料掘金营，微信deep3321