3、危害分析与风险评估（HARA）：HARA方法论、危害识别、风险评估与ASIL确定
好，咱们进入功能安全里最核心、也最考验功力的环节——HARA。
说实话，我见过不少团队，项目都做了一半了，才发现ASIL等级定错了。结果呢？要么是安全措施过度设计，成本爆炸；要么是安全目标没覆盖到，审核直接被亮红灯。所以，HARA这步走扎实了，后面才能顺风顺水。
3.1 HARA方法论：到底在做什么？
HARA，全称是 Hazard Analysis and Risk Assessment。翻译过来就是“危害分析与风险评估”。
它的目标很明确：找出系统在功能失效时，可能对人员造成的伤害，然后评估这个伤害有多严重，最后给每个危害定一个ASIL等级。
我个人习惯把HARA比作“排雷”。你想想看，在项目初期，我们并不知道系统里藏着哪些“地雷”。HARA就是拿着探雷器，把每个可能炸的雷都找出来，然后贴上标签——这个是“严重雷”，那个是“一般雷”。
整个方法论遵循一个清晰的流程：
- 场景分析：车辆在什么情况下运行？驾驶场景、环境、车速、路况。
- 功能定义：系统要实现什么功能？比如“自动紧急制动”。
- 失效识别：功能如果失效了，会是什么样子？比如“该刹车时没刹车”。
- 危害识别：这种失效会导致什么危害？比如“追尾前车”。
- 风险评估：评估这个危害的严重度（S）、暴露率（E）、可控性（C）。
- ASIL确定：根据S、E、C查表，得出ASIL等级。
嗯，这里要注意，HARA不是一次性的工作。随着项目深入，你对系统的理解会加深，HARA可能需要迭代更新。我在一个项目中就遇到过，最初定的ASIL B，后来发现场景分析漏掉了一个高风险的工况，最后改成了ASIL D。所以，别怕改，就怕不改。
3.2 危害识别：把“鬼”都揪出来
危害识别是HARA里最需要经验的一步。说白了，就是你要想象出所有可能出问题的情况。
怎么想象？不是瞎想。我们通常从“功能失效”入手。比如一个电子助力转向系统：
- 功能：根据方向盘转角，提供助力。
- 失效1：助力突然消失（丧失功能）。
- 失效2：助力错误输出（非预期功能）。
- 失效3：助力卡滞（功能延迟或卡死）。
然后，把这些失效放到具体的驾驶场景里。比如“车辆在高速公路上以120km/h行驶，突然转向助力消失”。这时候的危害是什么？驾驶员需要施加更大的力才能转动方向盘，可能导致车辆偏离车道，引发碰撞。
我曾经在一个项目中，团队只考虑了“助力消失”这种失效。我提醒他们：“你们想过没有，如果助力系统在驾驶员没打方向盘时，自己突然输出一个转向力矩呢？” 这就是“非预期转向”。这种危害往往更危险，因为驾驶员完全没有准备。
所以，危害识别时，我建议你多问自己几个“如果”：
- 如果功能不工作了？
- 如果功能在不该工作的时候工作了？
- 如果功能工作得不对（过大、过小、反向）？
- 如果功能卡在某个状态了？
把这些“如果”都列出来，你的危害清单就基本齐了。
重要提示： 危害识别一定要结合具体的运行场景。同一个失效，在不同场景下，危害程度天差地别。比如“刹车失效”在低速泊车时可能只是轻微碰撞，但在高速公路上就是致命危险。
3.3 风险评估：S、E、C三要素
危害找到了，接下来就是评估风险。ISO 26262给了我们三个参数：
| 参数 | 全称 | 含义 | 等级范围 |
|---|---|---|---|
| S | Severity | 危害的严重度 | S0（无伤害）~ S3（致命伤害） |
| E | Exposure | 暴露于危害场景的概率 | E0（几乎不）~ E4（非常高） |
| C | Controllability | 驾驶员或其他人员对危害的可控性 | C0（完全可控）~ C3（难以控制） |
这三个参数怎么定？我个人的经验是，不要拍脑袋。一定要基于数据、基于场景分析。
关于S（严重度）：
- S0：没有伤害。比如信息娱乐系统死机，只是不方便。
- S1：轻伤。比如轻微追尾，可能造成颈部扭伤。
- S2：重伤。比如骨折、严重出血，但不会危及生命。
- S3：致命或危及生命的伤害。比如高速碰撞导致死亡。
你想想看，一个危害如果会导致S3，那这个ASIL等级基本低不了。
关于E（暴露率）：
- E0：几乎不可能暴露。比如车辆在火星上行驶（开玩笑的）。
- E1：非常低。比如每年发生一次的场景。
- E2：低。比如每月发生几次。
- E3：中等。比如每周发生几次。
- E4：高。比如每次驾驶都会遇到。
举个例子，“车辆在冰雪路面上行驶”这个场景，在哈尔滨可能E4，但在海南可能就是E1。所以，暴露率跟车辆的目标市场、使用环境强相关。
关于C（可控性）：
- C0：完全可控。比如驾驶员可以轻松应对。
- C1：简单可控。比如95%以上的驾驶员能应对。
- C2：一般可控。比如90%以上的驾驶员能应对。
- C3：难以控制。比如只有少数专业驾驶员才能应对。
这里有个坑，我踩过。有一次评估一个“制动助力失效”的危害，我们觉得驾驶员用力踩刹车也能停下来，所以给了C1。但后来我们做了实车测试，发现普通驾驶员在紧急情况下根本来不及反应，实际可控性远低于预期。最后改成了C2。所以，可控性评估一定要基于真实的人因工程数据，别想当然。
我的小技巧： 在评估C值时，可以问自己一个问题：“如果这个危害发生了，一个普通驾驶员（不是赛车手）在没有任何预警的情况下，有多大几率能避免伤害？” 如果答案是“很难”，那C值至少是C2以上。
3.4 ASIL确定：查表定级
S、E、C都定好了，接下来就是查表。ISO 26262 Part 3 里给出了ASIL等级确定表：
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL等级 |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S1 | E2 | C2 | ASIL A |
| S2 | E3 | C2 | ASIL B |
| S3 | E3 | C3 | ASIL C |
| S3 | E4 | C3 | ASIL D |
| 其他组合 | 查表确定 | ||
注意，这个表只是简化版。实际标准里有一个完整的矩阵。但核心逻辑就是：S越高、E越高、C越差，ASIL等级就越高。
ASIL等级从低到高分别是：QM（质量管理）、ASIL A、ASIL B、ASIL C、ASIL D。QM意味着不需要按功能安全流程开发，只需要做好质量管理就行。ASIL D是最严格的，要求也最高。
我记得有一次，一个同事问我：“为什么我的危害S3、E4、C3，但查表出来是ASIL D？有没有可能降级？” 我说：“理论上可以，但你要提供充分的证据，证明你的评估过于保守。比如你实际测试发现可控性其实很好，那就可以把C从3降到2。但千万别为了降级而降级，审核专家一眼就能看出来。”
避坑指南： 我曾经见过一个项目，为了降低开发成本，故意把E值或C值往低了评。结果在功能安全审核时，被审核专家当场质疑，要求提供详细的场景分析报告和测试数据。最后不仅没降级，反而因为数据不充分，被要求重新做HARA，项目延期了两个月。所以，诚实评估，数据说话，这是HARA的铁律。
好了，HARA的核心内容就这些。总结一下：
- 方法论：场景分析 → 失效识别 → 危害识别 → 风险评估 → ASIL确定。
- 危害识别：多问“如果”，别漏掉非预期功能。
- 风险评估：S、E、C三个参数，每个都要基于数据和场景。
- ASIL确定：查表定级，诚实评估，别耍小聪明。
下一章，我们会聊聊如何把HARA的结果转化成具体的安全目标（Safety Goal）。那是真正指导我们设计安全措施的关键一步。咱们到时候见。