3. 危害分析与风险评估（HARA）：目的、场景与识别方法
好，我们进入第三讲。HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？在什么情况下出问题？出问题后果有多严重？
我刚开始做功能安全那会儿，总觉得HARA就是走个过场，填几张表完事。直到有一次，一个转向系统的项目，我们漏掉了一个“高速变道时EPS失效”的场景。结果评审时被客户怼得哑口无言。嗯，从那以后，我再也不敢小看HARA了。
3.1 HARA到底要干什么？
HARA的目的，用一句话概括：为每一个可能的危害事件，定出它的ASIL等级。ASIL是后续所有安全活动的“指挥棒”。
具体来说，HARA要完成三件事：
- 识别危害：系统或功能失效后，会引发什么危险？
- 评估风险：这个危险发生的概率高不高？驾驶员有没有机会避免？
- 确定目标：给每个危害定一个ASIL等级，作为安全目标的输入。
核心原则：HARA不是一次性的活动。随着设计深入，你可能会发现新的场景，或者原来的假设不成立。所以，HARA需要迭代更新。
3.2 运行场景定义——别让HARA变成空中楼阁
很多新手容易犯一个错：脱离场景谈危害。比如“制动失效会导致碰撞”。这话没错，但太笼统了。你得问：在什么场景下失效？
我个人习惯，把运行场景拆成三个维度：
| 维度 | 描述 | 举例 |
|---|---|---|
| 车辆状态 | 车速、转向角、负载、是否在巡航 | 车速120km/h，直线行驶 |
| 环境条件 | 天气、路面、光照、交通密度 | 雨天、湿滑路面、夜间 |
| 人为因素 | 驾驶员注意力、操作意图、反应时间 | 驾驶员正在分心看手机 |
你想想看，同样是“制动助力失效”：
- 在市区低速跟车（30km/h），驾驶员一脚踩死，可能只是吓一跳。
- 在高速上（120km/h），同样的情况，后果可能就是追尾甚至更严重。
所以，场景定义越具体，后续的ASIL评估就越准确。我建议你在项目初期，就拉上系统工程师、测试工程师一起，把典型的运行场景列出来。别一个人闷头想，容易漏。
3.3 危害识别方法——怎么把“雷”都挖出来？
危害识别，说白了就是“找茬”。但找茬也得有方法，不能瞎找。常用的方法有几种：
3.3.1 头脑风暴与检查表
最直接的方法。拉一屋子人，对着功能清单，一个一个过。我建议配合检查表使用，比如：
- 这个功能失效了会怎样？
- 输出信号丢失、错误、延迟，分别有什么影响？
- 有没有共因失效的可能？
我的经验：检查表要持续更新。每次项目做完，把踩过的坑加进去。久而久之，这就是团队的宝贵资产。
3.3.2 结构化分析方法
对于复杂系统，光靠头脑风暴不够。我常用的是HAZOP（ Hazard and Operability Study）。它通过引导词（如：无、多、少、相反、早、晚）来系统性地分析偏差。
举个例子，分析“油门踏板信号”：
- 无信号：踏板踩下，但ECU没收到信号 → 车辆无响应。
- 信号过大：踏板轻踩，但ECU收到100%开度 → 车辆突然加速。
- 信号相反：踩下踏板，信号反而减小 → 车辆减速。
你看，通过引导词，能覆盖很多意想不到的失效模式。
3.3.3 基于功能失效的分析
这个方法更贴近ISO 26262的思路。它从功能出发，分析功能失效后，对车辆行为的影响。比如：
- 功能：自动紧急制动（AEB）
- 失效模式：误触发（不该刹车时刹车）
- 危害：高速行驶时突然制动，导致后车追尾
我个人比较喜欢这种方法，因为它直接关联到功能安全目标，后续推导安全措施也更顺畅。
3.4 知识体系总览
下面这张图，把HARA的核心逻辑串起来了。你可以把它当作一个检查清单，做HARA时对照着看。
3.5 避坑指南
最后，分享几个我踩过的坑：
我曾经犯过的错：
- 场景定义太粗：只写“高速行驶”，没写具体车速和路况。结果评估出来的ASIL要么偏高，要么偏低，都不准。
- 忽略组合失效：只分析单一失效，没考虑“传感器失效 + 驾驶员分心”同时发生的情况。这种组合场景往往更危险。
- 把危害和失效混为一谈：失效是“EPS无助力”，危害是“车辆无法转向导致碰撞”。记住，危害是对人的伤害，不是技术故障本身。
嗯，HARA这部分内容比较多，但它是整个功能安全流程的基石。你花多少功夫在上面，后面的工作就有多顺畅。别急着赶进度，把场景想全，把危害挖透，后面推导ASIL就是水到渠成的事。