第三讲：危害分析与风险评估（HARA）
好，咱们进入功能安全里最核心的一步——HARA。说实话，很多工程师觉得HARA就是填表格、打分数，走个过场。但我做了这么多年项目，可以负责任地告诉你：HARA做得好不好，直接决定了你后续所有工作的质量。就像盖房子打地基，地基歪了，上面装修再漂亮也没用。
一、HARA的目的与流程
HARA的全称是Hazard Analysis and Risk Assessment，翻译过来就是危害分析与风险评估。它的目的很明确：找出系统可能出现的危害，评估这些危害的风险等级，然后制定安全目标来把风险降到可接受的水平。
我个人习惯把HARA的流程分成五步走：
- 功能定义——搞清楚系统是干什么的
- 危害识别——找出所有可能出问题的地方
- 场景分析——考虑各种运行场景和工况
- 风险评估——用S/E/C参数打分
- 制定安全目标——明确要“防什么、防到什么程度”
你想想看，这五步环环相扣。我在项目中遇到过不少团队，跳过功能定义直接做危害识别，结果漏掉了一大堆关键场景，后面返工改得叫苦连天。所以，千万别图省事。
二、危害识别方法
危害识别说白了就是“找茬”。但找茬也得有方法，不能瞎找。常用的方法有这么几种：
- 头脑风暴法：拉上系统、软件、硬件、测试、安全工程师一起开会，集思广益。嗯，这里要注意，一定要有不同背景的人参与，否则容易陷入思维盲区。
- 检查表法：基于以往项目的经验，整理出一份常见危害清单，逐条核对。这个方法效率高，但容易遗漏新系统的特有危害。
- HAZOP分析法：用引导词（如“无”、“多”、“少”、“反向”等）来系统性地分析每个功能可能出现的偏差。这个方法很严谨，但耗时较长。
危害识别时，要特别注意合理可预见的误使用。比如，用户会不会把油门当刹车踩？会不会在充电时用手去摸高压端子？这些不是用户傻，而是设计时必须考虑的场景。
三、风险评估矩阵（S/E/C参数）
找到危害之后，就要评估它的风险等级了。ISO 26262里用的是三个参数：
- S（Severity）——严重度，指危害发生时对人员造成的伤害程度
- E（Exposure）——暴露概率，指危害场景发生的可能性
- C（Controllability）——可控性，指驾驶员或其他人员能否避免伤害
每个参数都有对应的等级，咱们用表格来看：
| 参数 | 等级 | 描述 |
|---|---|---|
| S（严重度） | S0 | 无伤害 |
| S1 | 轻伤（可恢复） | |
| S2 | 重伤（可能危及生命，但可存活） | |
| S3 | 致命伤（危及生命，存活概率低） | |
| E（暴露概率） | E0 | 几乎不可能发生 |
| E1 | 很少发生（每年几次） | |
| E2 | 有时发生（每月几次） | |
| E3 | 频繁发生（几乎每次驾驶都会遇到） | |
| C（可控性） | C1 | 容易控制（驾驶员能轻松应对） |
| C2 | 一般可控（多数驾驶员能应对） | |
| C3 | 难以控制（即使专业驾驶员也难以避免） |
有了这三个参数，就可以查表得到ASIL等级（Automotive Safety Integrity Level，汽车安全完整性等级）。ASIL分为A、B、C、D四个等级，D是最严格的。举个例子：
- 如果S=3（致命）、E=3（频繁）、C=3（难控），那ASIL就是D
- 如果S=1（轻伤）、E=2（有时）、C=1（易控），那ASIL可能就是A甚至QM（质量管理）
四、安全目标（Safety Goal）的制定
安全目标，说白了就是一句话：“防止某某危害发生”。但它不是随便写写的，有严格的格式要求。
一个完整的安全目标通常包含以下要素：
- 危害描述：明确要防止什么危害
- 安全状态：系统进入什么状态才算安全
- 容错时间间隔：从危害发生到系统进入安全状态，最多能容忍多长时间
- ASIL等级：从风险评估中继承而来
举个例子，对于“刹车失灵”这个危害，安全目标可能是：
安全目标：防止车辆在行驶过程中因制动系统故障导致刹车失灵。
安全状态：车辆减速至停止，并保持驻车状态。
容错时间间隔：≤ 500ms
ASIL等级：D我在项目中见过最典型的错误，就是安全目标写得太笼统。比如“防止车辆失控”，这等于没说。失控的原因有很多种——刹车失灵、转向失灵、动力系统异常……每种都要单独制定安全目标。所以，安全目标一定要具体、可验证。
1. 这个目标能直接指导设计吗？
2. 测试时能验证这个目标是否达成吗？
3. 如果系统失效，这个目标能保护用户吗？
如果三个答案都是“是”，那这个安全目标就合格了。
另外，安全目标之间可能会有冲突。比如，既要保证制动安全，又要保证动力输出。这时候就需要做安全目标分解，把高等级的安全目标分配到不同的子系统或功能模块上。嗯，这部分内容咱们后面会详细讲。
好了，HARA这部分就讲到这里。记住一句话：HARA不是填表格，而是用系统化的方法找出风险、定义安全需求。下一讲，咱们聊聊如何把安全目标转化成具体的技术安全需求。