3. 电驱系统概述
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：系统哪里会出问题？出问题时车在干嘛？后果有多严重？
我见过不少团队，一上来就对着功能列表猛写危害事件，结果评审时发现场景定义不全，ASIL等级也定得偏高或偏低。嗯，这章我们就把它掰开揉碎讲清楚。
3.1 HARA方法论：四步走完风险识别
我个人习惯把HARA拆成四个阶段，每一步都有明确的输入和输出：
- 项目定义与功能分析 — 搞清楚电驱系统有哪些功能，边界在哪
- 运行场景定义 — 车会在什么环境、什么工况下使用这些功能
- 危害事件识别 — 功能失效 + 运行场景 = 危害事件
- ASIL等级确定 — 用S、E、C三个参数算出风险等级
核心原则：HARA不是一次性的文档工作。每当你修改功能、增加新场景，或者发现之前遗漏的失效模式，都要回头更新HARA。我把它叫做「活文档」。
下面这张图展示了HARA的完整流程，你可以对照着看：
3.2 运行场景定义：别让场景成为你的盲区
运行场景，就是描述「车在什么情况下使用这个功能」。ISO 26262 把它分成四类：
| 场景维度 | 典型参数 | 电驱系统示例 |
|---|---|---|
| 运行工况 | 车速、加速度、转向角、负载 | 高速巡航、急加速、坡道起步 |
| 环境条件 | 温度、湿度、雨雪、路面附着 | 冰雪路面、涉水、高温暴晒 |
| 时间因素 | 白天/夜晚、持续时长、频率 | 夜间行车、长时间爬坡 |
| 人员状态 | 驾驶员经验、注意力、反应时间 | 新手司机、疲劳驾驶、分心 |
避坑指南：我曾经在一个项目中，团队只定义了「正常驾驶」场景，结果电驱系统在「低温冷启动+急加速」组合场景下出现了过流保护误触发。后来我们补了20多个组合场景，才把问题兜住。所以我的建议是——场景组合要穷举，至少覆盖正常、故障、边缘三种类型。
具体到电驱系统，我常用的场景清单模板长这样：
- 正常场景：城市道路匀速行驶、高速公路超车、倒车入库
- 故障场景：传感器信号丢失、CAN通信中断、IGBT过温
- 边缘场景：电池SOC极低时急加速、电机堵转、轮速信号跳变
3.3 危害事件识别：失效模式 × 运行场景
危害事件 = 功能失效 + 运行场景。举个例子：
- 功能：电机扭矩控制
- 失效：非预期输出最大扭矩
- 场景：车辆在高速公路上以120km/h巡航
- 危害事件：「高速巡航时电机非预期输出最大扭矩，导致车辆突然加速，驾驶员无法控制」
写危害事件时，我要求团队必须包含三个要素：什么失效、什么场景、什么后果。缺一个，评审时就会被挑战。
注意：不要混淆「危害」和「失效」。失效是功能层面的（比如扭矩输出错误），危害是车辆层面的（比如非预期加速导致碰撞）。HARA关注的是后者。
电驱系统常见的危害事件类型：
| 危害类别 | 典型事件 | 涉及功能 |
|---|---|---|
| 非预期加速 | 停车时电机突然输出扭矩 | 扭矩控制、驻车控制 |
| 非预期减速 | 高速行驶中能量回收过度 | 再生制动、扭矩控制 |
| 动力中断 | 超车时电机无响应 | 扭矩控制、逆变器驱动 |
| 转向助力异常 | EPS电机输出错误力矩 | 转向控制、电机控制 |
3.4 ASIL等级确定：S、E、C三参数定乾坤
ASIL（Automotive Safety Integrity Level）分为四个等级：A、B、C、D，D最高，QM（质量管理）最低。确定ASIL需要评估三个参数：
| 参数 | 全称 | 等级 | 电驱系统典型判断 |
|---|---|---|---|
| S | Severity（严重度） | S0~S3 | 非预期加速导致碰撞 → S3 |
| E | Exposure（暴露概率） | E0~E4 | 高速巡航场景 → E4 |
| C | Controllability（可控性） | C0~C3 | 普通驾驶员能否应对 → C2 |
三个参数组合后，查表得到ASIL等级：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | A |
| S1 | E3 | QM | A | B |
| S1 | E4 | A | B | C |
| S2 | E1 | QM | QM | A |
| S2 | E2 | QM | A | B |
| S2 | E3 | A | B | C |
| S2 | E4 | B | C | D |
| S3 | E1 | A | B | C |
| S3 | E2 | A | B | C |
| S3 | E3 | B | C | D |
| S3 | E4 | C | D | D |
实战经验：我见过有人把「非预期加速」的S定成S3，E定成E4，C定成C2，查表得到ASIL D。但仔细分析后发现，如果车辆处于停车状态（E1），且驾驶员脚踩刹车（C1），ASIL可能降到B。所以场景不同，ASIL可以差两个等级。别偷懒，每个场景单独评估。
3.5 电驱系统HARA实战案例
拿一个真实案例来说。某电驱系统项目，功能是「电机扭矩控制」。我们识别出以下危害事件：
| 编号 | 危害事件 | S | E | C | ASIL |
|---|---|---|---|---|---|
| H-01 | 高速巡航时非预期输出最大扭矩 | S3 | E4 | C2 | D |
| H-02 | 停车时非预期输出扭矩 | S2 | E2 | C1 | A |
| H-03 | 坡道起步时动力中断 | S2 | E3 | C2 | B |
| H-04 | 冰雪路面能量回收过度导致甩尾 | S3 | E2 | C3 | C |
你看，同一个「扭矩控制」功能，不同场景下ASIL从A到D都有。这就是为什么我反复强调——场景定义是HARA的基石。
我的习惯：做完HARA后，我会把每个ASIL D的危害事件单独拎出来，写一份「安全目标」草案。比如H-01的安全目标就是：「防止高速巡航时电机非预期输出超过驾驶员请求扭矩的10%」。这个目标会直接指导后续的系统设计和安全机制开发。
3.6 常见误区与避坑指南
- 误区一：把所有危害事件都定成ASIL D。结果导致开发成本爆炸，评审时被安全专家打回。记住，ASIL D是少数，QM和ASIL A/B才是常态。
- 误区二：场景定义只写「正常驾驶」。我踩过这个坑——电驱系统在「低温+低SOC+急加速」组合场景下出现了过流保护误触发，而HARA里根本没这个场景。后来我们补了组合场景矩阵，才把问题兜住。
- 误区三：忽略可控性分析。有些团队默认C=3（不可控），导致ASIL虚高。其实很多场景下驾驶员是可以干预的，比如松开油门、踩刹车。合理评估可控性，能帮你省下不少安全机制成本。
好了，HARA这部分就讲到这里。记住，HARA不是写给别人看的文档，而是你后续所有安全工作的起点。花时间把场景想全、把ASIL定准，后面会省很多事。