3、危害分析与风险评估(HARA)：HARA的目的、运行场景定义、危害识别、风险分类
好，咱们进入线控转向功能安全最核心的一步——HARA。
说实话，很多工程师觉得HARA就是填表格、走流程。我刚开始做功能安全时也这么想。直到有一次，我们团队漏掉了一个低速泊车场景下的危害，差点导致项目延期。从那以后，我对HARA再也不敢马虎了。
HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车子在什么情况下会出问题？出问题后会怎样？这个后果严不严重？
3.1 HARA的目的
HARA的目的很明确——找出所有与线控转向相关的危害，并给每个危害定个“危险等级”。
你想想看，线控转向没有机械连接，方向盘和车轮之间全靠电信号。一旦信号出错，后果可能很严重。HARA就是帮我们提前识别这些风险，然后决定哪些风险必须用安全机制去覆盖。
我个人习惯把HARA的目的总结为三点：
- 识别危害：找出系统在哪些场景下可能产生危险行为
- 评估风险：判断每个危害的严重程度、发生概率和可控性
- 设定安全目标：为每个危害制定对应的安全要求，比如“ASIL D”或“ASIL B”
重要提醒：HARA不是一次性工作。项目过程中如果系统设计变了，或者发现了新的运行场景，HARA需要重新做。我在一个项目中就吃过这个亏——中期改了转向执行器的供电架构，结果忘了更新HARA，后来审核时被开了严重不符合项。
3.2 运行场景定义
运行场景定义，是HARA的第一步，也是最容易被忽视的一步。
什么叫运行场景？就是车辆在什么环境、什么工况下运行。比如：
- 高速公路上以120km/h巡航
- 城市拥堵路段走走停停
- 地下车库低速泊车
- 雨雪天气湿滑路面
- 夜间照明不足的乡村道路
我建议你从三个维度去定义场景：
| 维度 | 说明 | 示例 |
|---|---|---|
| 环境条件 | 天气、光照、路面状况 | 雨天、夜间、冰雪路面 |
| 车辆状态 | 车速、载荷、系统模式 | 高速巡航、低速泊车、满载 |
| 驾驶员行为 | 操作意图、注意力状态 | 正常转向、紧急避让、分心驾驶 |
嗯，这里要注意：场景定义不能太宽泛，也不能太细。太宽泛会漏掉关键危害，太细会导致工作量爆炸。我的经验是，先列出10-15个典型场景，覆盖日常驾驶的90%情况，后续再根据项目需求补充。
3.3 危害识别
危害识别，就是找出系统在哪些情况下会“不听话”。
对于线控转向，常见的危害包括：
- 非预期转向：车辆自己打方向，比如突然左转或右转
- 转向失效：方向盘转了，但车轮没反应
- 转向反向：方向盘左转，车轮右转
- 转向卡滞：方向盘转不动，或者转到某个位置卡住
- 转向抖动：方向盘或车轮出现异常振动
我曾经在一个项目中遇到过“转向反向”的案例。原因是角度传感器的信号线被电磁干扰了，导致ECU读到的方向盘角度和实际差了180度。幸亏我们在台架上发现了这个问题，没有装车。不然的话，你想想看，驾驶员往左打方向，车子往右拐，那后果...
避坑指南：危害识别时，不要只盯着单一故障。我曾经见过一个案例——两个独立的传感器同时漂移，导致系统误判。这种“双点故障”在HARA中很容易被忽略，但实际发生的概率并不低。
3.4 风险分类
风险分类，就是给每个危害定个“级别”。ISO 26262中用的是ASIL（Automotive Safety Integrity Level）等级，从低到高分别是：
- QM：质量管理级，不需要特殊安全措施
- ASIL A：轻度风险
- ASIL B：中度风险
- ASIL C：较高风险
- ASIL D：最高风险
ASIL等级由三个参数决定：
| 参数 | 含义 | 等级 |
|---|---|---|
| S（Severity） | 危害对人员的伤害严重程度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 危害发生的概率（场景暴露度） | E0（极低）~ E4（极高） |
| C（Controllability） | 驾驶员能否控制住局面 | C0（完全可控）~ C3（不可控） |
举个例子：
- 高速公路上非预期转向，S=3（可能致命），E=2（偶尔发生），C=3（驾驶员很难控制）→ ASIL D
- 低速泊车时转向失效，S=1（轻微伤害），E=3（经常发生），C=1（驾驶员可以控制）→ ASIL A
我个人习惯在风险分类时，先做一轮“粗分类”，把明显的高风险和低风险挑出来。然后再对中间那些“模棱两可”的危害做详细分析。这样效率高，也不容易漏掉关键项。
注意：ASIL等级不是越高越好。ASIL D意味着开发成本、验证工作量都很大。如果某个危害实际上只需要ASIL B，你硬要定成ASIL D，那就是过度设计。我在一个项目中见过这种情况——一个转向辅助功能被定成了ASIL D，结果开发周期延长了3个月，最后评审时发现其实ASIL B就够了。
3.5 HARA核心逻辑框架图
下面这张图是我自己总结的HARA核心逻辑，你可以把它当作一个检查清单：
这张图展示了HARA的完整流程：从运行场景定义开始，到危害识别，再到风险分类，最后输出安全目标。而且，这个流程不是一次性的——如果设计变了，你得回到第一步重新走一遍。
好了，关于HARA的核心内容就这些。记住，HARA做得好不好，直接决定了后续安全开发的成败。我在项目中见过太多因为HARA没做透，导致后期返工甚至召回的例子。所以，花时间把HARA做扎实，绝对是值得的。