3. 危害分析与风险评估（HARA）
HARA，全称 Hazard Analysis and Risk Assessment。说白了，它就是功能安全开发的“第一道安检门”。
很多刚入行的朋友问我：“我代码写得挺好，为什么非要搞这个？”我的回答是：没有HARA，你连安全目标是什么都不知道，后续所有工作都是在瞎忙活。
3.1 HARA的目的与时机
目的很明确：找出系统在运行过程中可能出现的危害，评估这些危害的风险等级，然后为每个危害制定安全目标。
举个例子。你设计一个电动助力转向系统。如果转向突然失效，车会怎样？如果转向意外反向助力，又会怎样？HARA就是要把这些“如果”都挖出来，然后告诉开发团队：“这个风险太高，必须降到可接受水平。”
时机呢？我个人习惯是在系统需求定义完成之后、系统架构设计开始之前做HARA。太早做，你对系统行为理解不够，分析会漏项；太晚做，架构都定死了，改起来成本巨大。
核心原则：HARA必须在系统设计冻结之前完成，且结果要作为后续所有安全活动的输入。
3.2 危害识别方法
危害识别是HARA的第一步，也是最考验经验的一步。我见过不少项目，因为危害识别不完整，导致后期频繁变更安全目标，整个开发节奏全乱了。
常用的方法有三种：
| 方法 | 适用场景 | 我的评价 |
|---|---|---|
| 头脑风暴 | 新系统、创新功能 | 灵活，但依赖团队经验 |
| 检查表 | 成熟系统、变型项目 | 高效，但容易僵化 |
| HAZOP | 复杂系统、安全关键系统 | 系统性强，但耗时 |
3.2.1 头脑风暴
这是最直接的方法。把系统工程师、软件工程师、硬件工程师、测试工程师、甚至项目经理叫到一起，关起门来想：“这玩意儿可能会出什么毛病？”
我曾经参与过一个ADAS项目的HARA。我们团队 brainstorm 了整整两天，列出了200多个潜在危害。虽然最后真正需要处理的只有30多个，但这个过程让我们对系统有了极其深刻的理解。
小技巧：头脑风暴时，不要急着否定任何想法。哪怕听起来很荒谬的“如果”，也可能引出真正的风险。
3.2.2 检查表
检查表是基于历史项目经验总结出来的“常见危害清单”。比如针对制动系统，检查表里可能就有“制动力不足”、“制动延迟”、“意外制动”等条目。
它的好处是快。对于变型项目，用检查表过一遍，基本不会漏掉已知风险。但坏处也很明显——它发现不了新风险。
3.2.3 HAZOP
HAZOP（Hazard and Operability Study）是化工行业传过来的方法，在功能安全领域用得越来越多。它通过“引导词 + 参数”的组合来系统性地挖掘危害。
比如，针对“车速”这个参数，引导词有“无”、“更多”、“更少”、“相反”等。组合起来就是：
- 无车速：车速信号丢失
- 更多车速：车速信号异常偏高
- 更少车速：车速信号异常偏低
- 相反车速：车速信号反向
这样一组合，几乎不会漏掉任何异常情况。
注意：HAZOP虽然系统性强，但非常耗时。一个中等复杂的系统，完整的HAZOP分析可能需要2-3周。建议只在安全关键度高的子系统上使用。
3.3 风险参数与ASIL等级确定
识别出危害之后，就要评估它的风险等级了。ISO 26262定义了三个风险参数：
- S（Severity，严重度）：危害发生时，对人员造成的伤害程度
- E（Exposure，暴露率）：人员在危害场景中的暴露概率
- C（Controllability，可控性）：驾驶员或其他人员控制危害的能力
这三个参数组合起来，就得到了ASIL等级（Automotive Safety Integrity Level）。
3.3.1 严重度 S
S分为S0、S1、S2、S3四个等级：
| 等级 | 描述 | 示例 |
|---|---|---|
| S0 | 无伤害 | 信息娱乐系统死机 |
| S1 | 轻伤 | 车窗夹手（轻微） |
| S2 | 重伤（可存活） | 安全气囊误爆 |
| S3 | 致命伤 | 制动完全失效 |
3.3.2 暴露率 E
E分为E0到E4五个等级：
| 等级 | 描述 | 示例 |
|---|---|---|
| E0 | 几乎不可能 | 车辆被陨石击中 |
| E1 | 非常低 | 每年一次 |
| E2 | 低 | 每月一次 |
| E3 | 中等 | 每周一次 |
| E4 | 高 | 每次驾驶 |
3.3.3 可控性 C
C分为C0、C1、C2、C3四个等级：
| 等级 | 描述 | 示例 |
|---|---|---|
| C0 | 完全可控 | 空调温度异常 |
| C1 | 简单可控 | 转向助力减弱 |
| C2 | 一般可控 | 制动距离增加 |
| C3 | 难以控制 | 转向完全锁死 |
3.3.4 ASIL等级确定
有了S、E、C三个参数，就可以查表确定ASIL等级了：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| E2 | QM | QM | ASIL A | |
| E3/E4 | QM | ASIL A | ASIL B | |
| S2 | E1 | QM | QM | ASIL A |
| E2 | QM | ASIL A | ASIL B | |
| E3/E4 | ASIL A | ASIL B | ASIL C | |
| S3 | E1 | QM | ASIL A | ASIL B |
| E2 | ASIL A | ASIL B | ASIL C | |
| E3/E4 | ASIL B | ASIL C | ASIL D |
QM表示“质量管理”，不需要额外安全措施。ASIL A到D，安全要求逐级递增。
关键点：ASIL等级不是越高越好。ASIL D的开发成本是ASIL B的3-5倍。合理评估，避免过度设计。
3.4 HARA核心流程
下面这张图是我自己总结的HARA核心流程，每次做新项目我都会拿出来对照一遍：
3.5 避坑指南
做了这么多年HARA，我踩过不少坑。分享几个最常见的：
- 危害识别不完整：我曾经在一个项目中只识别了“功能失效”类危害，完全忽略了“功能异常”类危害（比如信号反向、值超限）。结果后期测试时发现了一大堆问题。
- S/E/C评分过于乐观：有些团队为了降低ASIL等级，故意把参数往低了评。这是非常危险的。记住，HARA的结果是用来保护人的，不是用来讨好项目经理的。
- 忽略组合危害：两个低风险危害同时发生，可能产生高风险。比如“制动轻微衰减”+“路面湿滑”=“制动距离严重增加”。
我的建议：HARA文档一定要经过独立评审。找一位没有参与该项目的资深工程师来审，往往能发现很多盲点。
好了，HARA的核心内容就这些。记住，HARA不是一次性的工作。当系统需求变更、架构调整、或者发现新的危害场景时，都需要重新审视HARA结果。安全，永远是一个持续改进的过程。