第三章 危害分析与风险评估（HARA）
好，咱们进入正题。HARA，全称 Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。这玩意儿是功能安全里最核心的环节之一。说白了，就是回答三个问题：
- 系统会不会出问题？
- 出问题会多严重？
- 我们该怎么定义安全目标？
我个人习惯，做HARA之前先问自己一句：「如果这个功能失效了，车里的人会怎样？」想清楚这个，后面的分析才有方向。
3.1 HARA 方法论：从标准到实践
HARA的方法论，ISO 26262里写得挺清楚。但说实话，标准是死的，项目是活的。我见过不少团队，照着标准一步步做，结果做出来的HARA报告又厚又空，评审时被怼得哑口无言。
为什么会这样？因为HARA不是走流程，而是真正去理解系统的风险。
我个人常用的方法论，分三步走：
- 功能定义：先把系统要干什么说清楚。比如「电池管理系统要监控电芯电压」，这就是一个功能。
- 失效模式分析：这个功能如果坏了，会怎样？比如「电压监控失效，导致过充」。这里我建议用FMEA的思路，但别搞太细，先抓主要矛盾。
- 风险评估：根据严重度（S）、暴露率（E）、可控性（C），算出ASIL等级。
核心要点：HARA不是一次性工作。随着设计深入，你会发现新的场景、新的风险。所以，HARA要迭代。我一般会在系统架构冻结前做三轮HARA：概念阶段一轮，详细设计一轮，集成测试前再一轮。
3.2 运行场景与危害识别
运行场景，这个词听起来高大上，其实就是「车在什么情况下会出事」。你想想看，同样是电池过充，在高速上和在车库里，后果能一样吗？
我遇到过最典型的例子：某款新能源车，BMS的过充保护功能在「快充场景」下失效了。结果呢？电池热失控，车烧了。事后分析，HARA阶段根本没把「快充场景」单独列出来分析。
所以，运行场景的识别，一定要覆盖：
- 驾驶场景：高速、城市、乡村、停车场
- 环境场景：高温、低温、雨天、雪天
- 使用场景：快充、慢充、放电、静置
- 故障场景：传感器失效、通信中断、软件跑飞
危害识别，说白了就是找「危险事件」。我习惯用「功能失效 + 运行场景」的组合来推导。比如：
| 功能 | 失效模式 | 运行场景 | 危害事件 |
|---|---|---|---|
| 电池过充保护 | 保护功能失效 | 快充时，SOC已达100% | 电池过充，引发热失控 |
| 电机扭矩控制 | 非预期加速 | 高速公路上，驾驶员准备超车 | 车辆失控，碰撞风险 |
| 绝缘监测 | 监测功能失效 | 雨天，车辆涉水 | 高压漏电，人员触电 |
避坑指南：我曾经在某个项目里，只分析了「正常驾驶场景」，忽略了「充电场景」。结果充电桩侧的通信协议有bug，导致BMS误判。嗯，从那以后，我要求团队必须把「充电场景」单独拉出来做一轮HARA。
3.3 安全目标定义
安全目标，就是「我们要防止什么」。它是对危害事件的顶层安全要求。注意，安全目标不是技术方案，而是「要达成什么效果」。
举个例子：
- 危害事件：电池过充导致热失控
- 安全目标：防止电池过充，确保SOC不超过100%
- ASIL等级：ASIL C（根据S、E、C评估结果）
定义安全目标时，我建议遵循几个原则：
- 单一性：一个安全目标只对应一个危害事件。别把多个风险揉在一起。
- 可验证性：安全目标要能测试。比如「SOC不超过100%」就可以通过测试验证。
- 完整性：覆盖所有识别出的危害事件。漏一个，就是一颗雷。
注意：安全目标的ASIL等级，决定了后续所有安全措施的开发严格度。ASIL D的要求最高，ASIL A最低。我见过有人为了省事，故意把ASIL评低。结果呢？项目后期被安全评审打回来重做，反而更浪费时间。
最后，分享一个我自己的习惯。每定义完一个安全目标，我会问自己三个问题：
- 这个目标能防止那个危害事件吗？
- 这个目标在技术上可实现吗？
- 这个目标的ASIL等级合理吗？
三个问题都回答「是」，这个安全目标才算合格。
好了，HARA这部分就聊到这儿。下一章，咱们讲安全架构设计，看看怎么把安全目标落地成具体的技术方案。