第二章：危害分析与风险评估（HARA）
各位工程师朋友，咱们今天聊聊HARA。说实话，HARA是整个功能安全开发的起点，也是决定后续工作量的关键。我见过不少项目，前期HARA做得马虎，结果后期改得焦头烂额。嗯，咱们得把这事整明白。
2.1 HARA的目的：为什么要做这件事？
HARA的全称是Hazard Analysis and Risk Assessment，翻译过来就是危害分析与风险评估。它的核心目的就一个：找出车辆在运行过程中可能出现的危害，并评估这些危害的风险等级。
说白了，就是回答三个问题：
- 会出什么事？（危害识别）
- 在什么情况下出？（运行场景）
- 后果有多严重？（风险等级）
我个人习惯把HARA比作「体检」。你想想看，一辆车在路上跑，就像一个人活着，总得知道哪些地方容易出毛病。HARA就是给车辆系统做全面体检，找出潜在的「病灶」。
核心要点：HARA的输出是ASIL等级，它直接决定了后续开发的安全措施力度。ASIL越高，要求越严，成本也越高。
我在项目中遇到过一件事：有个团队做EPS（电动助力转向）系统，HARA时漏掉了一个场景——车辆在湿滑路面低速行驶时突然失去助力。结果呢？测试阶段才发现这个问题，ASIL等级从QM直接跳到ASIL C，整个软件架构都得重来。教训深刻啊。
2.2 运行场景定义：你得知道车在哪儿跑
运行场景，就是描述车辆在什么环境下、什么状态下运行。这可不是随便写写就行的。我建议从三个维度来定义：
| 维度 | 内容 | 举例 |
|---|---|---|
| 环境条件 | 天气、路面、光照、交通状况 | 雨天、冰雪路面、夜间、拥堵 |
| 车辆状态 | 车速、负载、系统模式 | 高速巡航、低速泊车、满载 |
| 驾驶员行为 | 操作意图、注意力状态 | 急刹车、分心驾驶、疲劳 |
为什么要这么细？因为同一个故障，在不同场景下后果完全不同。举个例子：
- 高速公路上突然刹车失灵 → 严重事故
- 停车场里刹车失灵 → 最多蹭一下
你看，同样的故障，场景不同，风险等级天差地别。所以，场景定义越细，HARA越准确。
我的经验：定义场景时，别只盯着「正常工况」。极端工况往往才是真正要命的。我曾经在ADAS项目中，漏掉了「隧道出口强光直射」这个场景，结果摄像头瞬间过曝，系统直接罢工。嗯，后来补上这个场景，ASIL等级从B升到了D。
2.3 危害识别方法：怎么找到那些「坑」？
危害识别，说白了就是找茬。但找茬也得有方法，不能瞎找。常用的方法有几种：
2.3.1 头脑风暴法
拉上系统工程师、软件工程师、硬件工程师、测试工程师，坐在一起「拍脑袋」。别笑，这方法其实很有效。关键是得有不同背景的人，才能从不同角度发现问题。
2.3.2 检查表法
基于历史项目经验，整理一份检查表。每做一个新项目，就对着表一项项过。我自己的团队就有一份积累了5年的检查表，里面记录了200多个常见危害点。
2.3.3 FMEA法
失效模式与影响分析。这个方法更系统，从每个组件的失效模式出发，分析它对系统的影响。适合用在已经有一定设计细节的阶段。
避坑指南：我曾经犯过一个错误——只关注「功能失效」，忽略了「功能误用」。比如，ACC自适应巡航在正常工作时，如果驾驶员突然踩油门，系统该怎么响应？这种「人机冲突」场景，往往是最容易出问题的。
2.4 危害事件分类：给危害「贴标签」
找到危害之后，得给它们分类。ISO 26262把危害事件分成三类：
- S（Severity）严重度：对人员伤害的严重程度
- S0：无伤害
- S1：轻伤
- S2：重伤（可能危及生命）
- S3：致命
- E（Exposure）暴露概率：危害场景发生的概率
- E0：几乎不可能
- E1：低概率
- E2：中概率
- E3：高概率
- E4：极高概率
- C（Controllability）可控性：驾驶员能否控制住局面
- C0：完全可控
- C1：简单可控
- C2：一般可控
- C3：难以控制
这三个维度组合起来，就得到了ASIL等级。具体怎么组合？看这张表：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | ASIL A |
| S2 | E2 | QM | ASIL A | ASIL B |
| S3 | E3 | ASIL A | ASIL B | ASIL C |
| S3 | E4 | ASIL B | ASIL C | ASIL D |
你可能会问：为什么S3+E4+C3就是ASIL D？因为这种情况下，伤害致命、场景常见、驾驶员还控制不住，那不得最高等级保护？
关键点：ASIL D不是随便给的。我见过有些团队为了「保险」，把所有危害都定成ASIL D。结果呢？开发成本翻倍，项目延期。记住，ASIL等级要实事求是，该高就高，该低就低。
2.5 实战案例：一个转向系统的HARA
咱们拿一个电动助力转向系统（EPS）来练练手。假设我们识别出一个危害：转向助力突然丧失。
先定义场景：
- 场景A：高速公路上，车速120km/h，驾驶员正在变道
- 场景B：停车场里，车速5km/h，驾驶员正在倒车入库
然后评估：
| 场景 | S | E | C | ASIL |
|---|---|---|---|---|
| 场景A | S3（可能致命） | E3（高速场景常见） | C2（驾驶员可尝试控制） | ASIL C |
| 场景B | S1（最多刮蹭） | E2（倒车场景中等概率） | C1（很容易控制） | QM |
看到了吗？同一个危害，不同场景，ASIL等级从QM到ASIL C。这就是为什么场景定义这么重要。
我的建议：做HARA时，别一个人闷头干。拉上测试、标定、甚至售后的人一起讨论。售后的人最清楚用户在实际使用中出了什么问题。我每次做HARA，都会请售后工程师来分享几个真实案例，那效果，比看十遍标准都管用。
2.6 常见误区与避坑
最后，分享几个我踩过的坑：
- 过度乐观：总觉得「这个故障不会发生」。记住，墨菲定律在汽车行业特别灵验。
- 场景遗漏：只考虑「正常工况」，忽略了「边界工况」。比如，电池快没电了、传感器被泥巴糊住了。
- 可控性误判：高估驾驶员的能力。你以为驾驶员能反应过来，实际上他可能正在看手机。
- 等级虚高：为了「安全」把所有危害都定成ASIL D。这其实是最不安全的做法——因为成本太高，项目可能直接黄了。
好了，关于HARA，咱们就聊到这儿。下一章，咱们聊聊怎么把ASIL等级分解到具体功能上。那又是一个有意思的话题。