2. 危害分析与风险评估（HARA）：从场景到ASIL的完整链路
HARA，全称 Hazard Analysis and Risk Assessment。说白了，它就是功能安全开发的“第一道安检门”。
我见过不少团队，上来就写安全目标，结果写到一半发现场景漏了、风险等级定错了，回头再补HARA，那叫一个痛苦。所以，咱们得把这一步走扎实。
2.1 HARA方法论：三步走，步步为营
HARA不是玄学，它有一套标准流程。我个人习惯把它拆成三个核心步骤：
- 场景定义：搞清楚“车在哪儿开？谁在开？会遇到啥？”
- 危害识别：找出“哪个功能失效了？会导致什么危险？”
- 风险分类与ASIL确定：评估“这危险有多严重？发生的概率多大？能不能控制？”
这三步是串行的，缺一不可。你想想看，场景都没定义清楚，你识别出来的危害可能就是空中楼阁。
核心原则：HARA必须基于功能，而不是基于系统。我们分析的是“转向功能失效”，而不是“转向电机坏了”。这个区别很关键。
2.2 运行场景定义：别让HARA变成空中楼阁
场景定义是HARA的基石。我刚开始做HARA时，就犯过“场景定义太笼统”的错。比如只写“车辆在高速行驶”，结果后续分析根本没法落地。
一个完整的运行场景，应该包含三个维度：
| 维度 | 描述 | 示例 |
|---|---|---|
| 车辆状态 | 车速、转向角、加速度、负载等 | 车速 120 km/h，直线行驶 |
| 环境条件 | 道路类型、天气、光照、交通密度 | 高速公路，雨天，低摩擦系数 |
| 人员行为 | 驾驶员操作、乘客状态、其他交通参与者 | 驾驶员未预判减速，前车急刹 |
我的小技巧：场景定义时，多用“组合拳”。比如“高速 + 雨天 + 前车急刹”就是一个高价值场景。别只写单一条件，那不够。
2.3 危害识别：找到那个“万一”
危害识别，就是问自己一个问题：“这个功能如果失效了，最坏的情况是什么？”
举个例子，对于“电子助力转向系统”，我们分析它的“转向助力功能”：
- 功能失效：转向助力突然丧失
- 危害事件：驾驶员需要施加更大的力才能转动方向盘，在低速泊车时可能只是“费力”，但在高速变道时，可能导致车辆偏离车道，引发碰撞。
这里要注意，危害事件必须描述到对人或车辆造成的伤害。只说“转向助力没了”不算危害事件，“导致车辆失控并碰撞”才算。
避坑指南：我曾经见过一个团队，把“刹车片磨损”当作危害。这其实是故障，不是危害。危害是“刹车性能下降导致无法在预期距离内停车”。记住，危害是后果，不是原因。
2.4 风险分类与ASIL确定：三个参数定生死
ISO 26262 给了我们三个参数来评估风险：
- S（Severity）：严重度。伤害有多重？轻伤？重伤？致命？
- E（Exposure）：暴露概率。这个场景发生的频率高不高？
- C（Controllability）：可控性。驾驶员或其他人员能控制住局面吗？
这三个参数组合起来，就得到了ASIL等级（A、B、C、D），或者QM（无需安全措施）。
我习惯用一张表来快速查等级：
| S（严重度） | E（暴露概率） | C（可控性） | ASIL |
|---|---|---|---|
| S1（轻伤） | E1（极低） | C1（可控） | QM |
| S2（重伤） | E2（低） | C2（一般） | A |
| S3（致命） | E3（中） | C3（难控） | B / C / D |
| S3（致命） | E4（高） | C3（难控） | D |
嗯，这里要注意，ASIL D 是最严格的等级，要求也最高。你想想看，如果某个危害是“致命伤害 + 经常发生 + 驾驶员完全无法控制”，那必须上ASIL D。
实战经验：我在做某个ADAS项目时，对“自动紧急制动（AEB）意外激活”这个危害进行评估。场景是“高速公路上，AEB误触发导致急刹”。S是S3（可能引发追尾，致命），E是E3（中，因为误触发概率不低），C是C2（驾驶员可以踩油门或打方向干预，但反应时间短）。最终定级为ASIL C。这个等级决定了后续所有安全措施的设计力度。
2.5 从HARA到安全目标：输出物长什么样？
HARA做完，我们要输出一份清晰的表格，作为下一阶段（功能安全概念）的输入。
我习惯的模板是这样的：
| ID | 功能 | 危害事件 | 运行场景 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|---|---|
| HARA-01 | 转向助力 | 高速行驶中助力丧失，驾驶员无法及时转向，导致车辆偏离车道并碰撞 | 高速路，120km/h，直道，驾驶员注意力分散 | S3 | E2 | C3 | ASIL C | 转向助力功能必须防止非预期的助力丧失 |
| HARA-02 | 制动助力 | 低速跟车时制动助力突然增加，导致非预期急刹，被后车追尾 | 城市道路，30km/h，跟车行驶，交通拥堵 | S2 | E3 | C2 | ASIL B | 制动助力功能必须防止非预期的助力增加 |
你看，每一行都是一个完整的逻辑链。从功能出发，到场景，到危害，再到等级和目标。这样后续做系统设计时，才能有理有据。
我的建议：HARA文档一定要让系统工程师和测试工程师一起评审。他们往往能发现你忽略的场景。我曾经就被测试同事问住：“你这个场景里，如果路面有冰呢？” 好问题，立马补上。
好了，HARA这块的核心内容就是这些。记住，它不是一个一次性的活动。随着项目深入，你可能会发现新的场景，或者原来的评估不合理。没关系，迭代更新就好。关键是，每一步都要有据可查。