4、危害分析与风险评估（HARA）：从零搭建你的安全防线
各位工程师朋友，咱们今天聊聊HARA。
说实话，我刚开始接触功能安全那会儿，觉得HARA就是个走流程的文档工作。直到有一次，我在一个ADAS项目中漏掉了一个边缘场景——嗯，就是那种“理论上几乎不可能发生”的情况。结果在实车测试时，系统在特定光照条件下误触发了紧急制动。那滋味，真不好受。
从那以后，我彻底明白了：HARA不是写给审核员看的，是写给产品安全看的。
4.1 HARA方法论概述：你到底在分析什么？
HARA，全称Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 什么东西会坏？（危害识别）
- 坏了会怎样？（风险评估）
- 我们该多认真对待？（安全等级定级）
我个人习惯把HARA比作“安全体检”。你想想看，一个人去做体检，先查有哪些指标异常（危害），再看异常有多严重（风险），最后决定要不要住院治疗（安全等级）。一个道理。
HARA的核心输出，就是一张风险矩阵表。这张表会告诉你：哪些风险必须管，哪些可以放一放。
核心要点：HARA不是一次性的工作。产品设计变了，HARA就要跟着更新。我见过太多团队把HARA做成“一次性文档”，结果后期改设计时全乱套了。
4.2 危害识别技术：HAZOP与FMEA，两把刷子
危害识别是HARA的第一步，也是最容易出纰漏的一步。我常用的工具有两个：HAZOP和FMEA。它们不是二选一的关系，而是互补的。
4.2.1 HAZOP：从“偏差”找问题
HAZOP，全称Hazard and Operability Study。它的核心思路是：用引导词+参数，找出系统可能出现的偏差。
举个例子，你分析一个刹车系统：
- 引导词“没有” + 参数“刹车力” = 刹车力缺失
- 引导词“过多” + 参数“刹车力” = 刹车力过大
- 引导词“相反” + 参数“刹车指令” = 踩刹车反而加速
我在项目中遇到过最典型的案例：一个线控转向系统，HAZOP分析时用了引导词“部分”，发现“部分转向角度丢失”这个偏差。当时团队觉得概率极低，结果后来真在低温环境下复现了——电机驱动芯片性能衰减导致转角输出只有正常的70%。
小技巧：做HAZOP时，别只盯着“正常工况”。我建议把“上电/下电”、“故障注入”、“极端环境”都过一遍。这些场景往往藏着最要命的危害。
4.2.2 FMEA：从“失效模式”找根因
FMEA，Failure Mode and Effects Analysis。它和HAZOP的区别在于：HAZOP从“系统行为偏差”出发，FMEA从“组件失效模式”出发。
你想想看，HAZOP问的是“系统会出什么幺蛾子”，FMEA问的是“哪个零件会先坏掉”。
FMEA的典型步骤：
- 列出每个组件的失效模式（比如：电阻开路、电容短路、软件跑飞）
- 分析失效后果（对系统有什么影响）
- 评估严重度、发生频度、探测度
- 计算RPN（风险优先级数），决定要不要改进
我曾经在一个项目中，FMEA分析发现“电源管理芯片输出过压”这个失效模式，RPN高达280（阈值是200）。我们加了一路硬件过压保护电路，结果在EMC测试中真的触发了保护——嗯，那次测试救了整个项目。
注意：FMEA容易陷入“过度分析”。我见过有人把每个电阻电容都列出来分析，结果文档写了300页，真正有用的信息没几个。我的建议是：聚焦在安全关键组件上，非安全相关的可以简化处理。
4.3 风险等级评估：SIL和ASIL，到底怎么定？
风险等级评估，说白了就是给每个危害“打分”。分数越高，安全要求越严格。
在功能安全领域，主要有两套体系：
| 体系 | 适用标准 | 等级范围 | 核心参数 |
|---|---|---|---|
| SIL | IEC 61508（通用工业） | SIL 1 ~ SIL 4 | HFT、SFF、PFD/PFH |
| ASIL | ISO 26262（汽车） | ASIL A ~ ASIL D | S（严重度）、E（暴露率）、C（可控性） |
我主要做汽车电子，所以重点聊聊ASIL。
ASIL的定级公式很简单：
ASIL = f(S, E, C)
- S（Severity）：危害发生时，对人员造成的伤害程度。S0（无伤害）到S3（致命伤害）。
- E（Exposure）：危害场景发生的概率。E0（几乎不可能）到E4（非常频繁）。
- C（Controllability）：驾驶员或人员能否控制住局面。C0（完全可控）到C3（几乎不可控）。
举个例子：
一个“刹车完全失效”的危害：
- S = 3（可能致命）
- E = 3（每天都会用到刹车）
- C = 3（刹车没了，驾驶员基本没法控制）
查表可得：ASIL D（最高等级）。
而“车窗升降卡死”的危害：
- S = 1（轻微伤害）
- E = 2（偶尔使用）
- C = 1（很容易控制）
查表可得：ASIL A（最低等级）。
我的经验：很多新手容易把S定得太高。记住，S评估的是“伤害程度”，不是“故障严重度”。一个故障让车抛锚了，但没人受伤，S就是S0。别把“麻烦”当成“危险”。
4.4 HARA报告编写：别写成流水账
HARA报告是HARA工作的最终交付物。我见过太多报告，就是把分析过程原封不动地贴上去，读起来像一本流水账。
一份好的HARA报告，应该包含以下内容：
- 系统定义：你分析的是什么系统？边界在哪里？
- 危害识别结果：列出了哪些危害？用了什么方法？
- 风险等级评估：每个危害的S、E、C值，以及最终的ASIL/SIL等级。
- 安全目标：针对每个危害，定义的安全目标是什么？
- 假设和限制条件：分析中做了哪些假设？哪些场景没覆盖？
我个人习惯在报告开头加一个“摘要表”，把最重要的信息浓缩在一页纸上。这样审核员一眼就能看到关键信息，不用翻遍全文。
举个例子，摘要表可以这样写：
| 危害ID | 危害描述 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|
| H-001 | 刹车力完全丧失 | 3 | 3 | 3 | D | 刹车力丧失时，应在1秒内发出报警并启用备用制动 |
| H-002 | 转向角度偏差超过10度 | 2 | 2 | 2 | B | 转向角度偏差超过阈值时，应限制车速至30km/h以下 |
避坑指南：我曾经在报告里漏写了“假设条件”，结果审核时被追问“你这个分析覆盖了低温环境吗？”——嗯，那次我花了三天补数据。所以，假设条件一定要写清楚，这是保护你自己的最好方式。
好了，关于HARA的方法论、识别技术、等级评估和报告编写，今天就聊到这儿。记住，HARA不是一次性的任务，而是贯穿整个产品开发周期的持续活动。你设计变了，HARA就要跟着变。别偷懒，安全这东西，偷懒的代价你付不起。