4. 危害分析与风险评估(HARA)：从场景到ASIL的完整链路
好，咱们进入功能安全最核心的一步——HARA。说实话，很多工程师觉得HARA就是填表格、走流程。但我做了这么多年项目，可以负责任地告诉你：HARA的质量，直接决定了整个功能安全开发的成败。你想想看，如果危害没识别全，或者ASIL等级定低了，后面所有的安全机制都是白搭。
4.1 HARA方法论：不是纸上谈兵
HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 车会出什么危险？（危害识别）
- 在什么情况下出危险？（运行场景定义）
- 危险有多严重？（风险等级评定）
我个人习惯把HARA分成四个步骤，像流水线一样走下来：
- 场景定义——搞清楚车在什么环境下跑
- 危害识别——找出所有可能的危险事件
- 风险评定——评估每个危险的严重度、暴露率、可控性
- ASIL确定——根据评定结果定等级
重要提醒：HARA不是一次性的工作。我在项目中遇到过，明明前期做了完整的HARA，结果到了V模型后期，发现新场景没覆盖到。所以，HARA一定要迭代更新。
4.2 运行场景定义：别让场景坑了你
场景定义是HARA的基石。你想想看，同样的功能在不同场景下，风险等级可能天差地别。
举个例子：自动紧急制动（AEB）
- 在高速公路上，前车急刹——场景A
- 在城市道路上，行人突然横穿——场景B
- 在隧道里，光线突然变暗——场景C
这三个场景，暴露率、可控性都不一样。我建议你从这几个维度去定义场景：
| 维度 | 典型取值 | 说明 |
|---|---|---|
| 道路类型 | 高速、城市、乡村、隧道 | 不同道路的行驶速度、交通密度不同 |
| 天气条件 | 晴天、雨天、雪天、雾天 | 影响传感器性能和路面附着力 |
| 交通参与者 | 车辆、行人、自行车、动物 | 不同参与者的行为模式差异大 |
| 车辆状态 | 直行、转弯、变道、倒车 | 车辆动力学特性不同 |
我的经验：场景定义不要贪多。我曾经在一个项目里定义了200多个场景，结果评审时发现很多场景是重复的。后来我学乖了，先定义20-30个典型场景，覆盖90%以上的运行情况，剩下的在迭代中补充。
4.3 危害识别：找到所有"地雷"
危害识别，说白了就是找茬。你要找出所有可能导致人员受伤的危险事件。
我常用的方法是功能失效分析。比如，对于一个自动驾驶的"车道保持"功能，我会问自己：
- 如果功能失效了会怎样？——车辆偏离车道
- 如果功能误触发了会怎样？——车辆突然转向
- 如果功能响应延迟了会怎样？——车辆修正不及时
嗯，这里要注意：危害一定要和场景绑定。你不能只说"车辆偏离车道"，你得说"在高速公路上以120km/h行驶时，车辆偏离车道，可能导致与相邻车道车辆碰撞"。
避坑指南：我曾经犯过一个错误——只考虑了功能失效，没考虑功能降级。比如，某个传感器坏了，系统降级到"仅限低速行驶"，但驾驶员不知道。这种降级场景下的危害，往往容易被忽略。
4.4 风险等级评定：三个参数定生死
ISO 26262用三个参数来评定风险等级：
- S（Severity）——严重度：伤害有多重？
- E（Exposure）——暴露率：这种情况多常见？
- C（Controllability）——可控性：驾驶员能控制住吗？
每个参数分4个等级：
| 等级 | S（严重度） | E（暴露率） | C（可控性） |
|---|---|---|---|
| S0 | 无伤害 | — | — |
| S1 | 轻伤（可恢复） | — | — |
| S2 | 重伤（可能危及生命） | — | — |
| S3 | 致命伤 | — | — |
| E1 | — | 极低（每年几次） | — |
| E2 | — | 低（每月几次） | — |
| E3 | — | 中（每周几次） | — |
| E4 | — | 高（几乎每次驾驶） | — |
| C1 | — | — | 容易控制 |
| C2 | — | — | 一般可控 |
| C3 | — | — | 难以控制 |
举个例子：高速上AEB失效导致追尾
- S：高速追尾，大概率S3（致命伤）
- E：高速行驶很常见，E4
- C：驾驶员反应时间很短，C3
4.5 ASIL等级确定：从A到D的决策
有了S、E、C三个参数，查表就能得到ASIL等级：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | ASIL A |
| S1 | E3 | QM | ASIL A | ASIL B |
| S1 | E4 | ASIL A | ASIL B | ASIL B |
| S2 | E1 | QM | QM | ASIL A |
| S2 | E2 | QM | ASIL A | ASIL B |
| S2 | E3 | ASIL A | ASIL B | ASIL C |
| S2 | E4 | ASIL B | ASIL C | ASIL C |
| S3 | E1 | ASIL A | ASIL B | ASIL B |
| S3 | E2 | ASIL B | ASIL C | ASIL C |
| S3 | E3 | ASIL B | ASIL C | ASIL D |
| S3 | E4 | ASIL C | ASIL D | ASIL D |
回到刚才的例子：S3、E4、C3 → ASIL D。嗯，最高等级，意味着你需要最严格的安全措施。
关键点：ASIL D不是终点。我见过很多团队，一看到ASIL D就慌了，觉得成本太高。其实，你可以通过安全机制来降低风险。比如，增加冗余传感器、设计故障降级策略，把ASIL D的需求分解到子系统，变成ASIL B甚至ASIL A的要求。
4.6 实战案例：一个完整的HARA示例
咱们拿自动泊车功能来走一遍流程：
场景定义：
- 场景1：地下车库，光线暗，车位狭窄
- 场景2：路边平行停车，后方有来车
- 场景3：停车场，周围有行人走动
危害识别（以场景1为例）：
- 危害1：泊车过程中，系统误判车位边界，导致车辆刮擦相邻车辆
- 危害2：泊车过程中，系统未检测到车位内的障碍物（如消防栓），导致碰撞
- 危害3：泊车过程中，系统突然退出，车辆停在半路，阻碍交通
风险评定（以危害1为例）：
- S：刮擦导致轻微财产损失，人员无伤害 → S0（无伤害）
- E：地下车库泊车，每周几次 → E3
- C：驾驶员可以随时接管 → C1
ASIL等级：S0 → QM（质量管理级，不需要功能安全措施）
但如果是危害2（碰撞消防栓导致车辆失控撞到行人）：
- S：行人可能重伤 → S2
- E：地下车库有行人，常见 → E3
- C：驾驶员注意力分散，难以控制 → C2
- ASIL：查表 → ASIL B
我的建议：做HARA时，一定要拉上系统工程师、软件工程师、测试工程师一起评审。一个人闭门造车，很容易漏掉关键场景。我记得有一次，我们团队评审时，测试工程师提了一个"雨天夜间泊车"的场景，结果发现这个场景的暴露率被低估了，ASIL等级从B升到了C。
好了，HARA这部分就讲到这里。下一章咱们聊聊功能安全概念（FSC）——怎么把ASIL等级转化成具体的安全需求。记住一句话：HARA做得好，后面少烦恼。