1. 课程导入
在新能源汽车与储能系统中，电池管理系统（BMS）承担着电压、电流、温度、绝缘、SOC/SOH估算、继电器控制、热管理与故障保护等关键功能。一旦BMS在危害场景下失效，可能导致热失控、起火、电击、过充过放、动力中断等严重后果。因此，BMS开发不能只停留在功能实现层面，而必须按照功能安全的方法论，从危害识别出发，逐步推导出可验证、可追溯的安全目标与安全需求。本课程围绕ISO 26262所定义的HARA（危害分析与风险评估）与安全目标开发工程，结合BMS真实工程场景，构建一条从概念到落地的完整学习路径。
一、学习目标：从“会做功能”到“会做安全”
本课程的学习目标分为四个层次。第一，理解功能安全的核心概念，包括危害、风险、ASIL、安全目标、功能安全概念、技术安全需求等，能够区分“故障”与“失效”、“危害”与“风险”的边界。第二，掌握HARA的完整方法，能够针对BMS的典型功能（如过充保护、过温保护、高压互锁、继电器粘连诊断）开展危害识别、场景分析、严重度/暴露度/可控性评估，并确定ASIL等级。第三，掌握安全目标与安全需求的推导方法，能够将安全目标分解为功能安全需求与安全机制，并映射到BMS的软硬件架构。第四，建立可追溯的安全开发思维，理解从危害到安全目标、从安全目标到技术安全需求、从需求到验证确认的双向追溯关系。
核心能力闭环：识别危害 → 评估风险 → 确定ASIL → 制定安全目标 → 分解安全需求 → 设计安全机制 → 验证与确认 → 追溯与复盘。
二、核心概念：HARA与安全目标的关系
HARA是功能安全开发的起点，其本质是回答三个问题：什么可能出错？出错后有多严重？在什么场景下发生？通过严重度（S）、暴露度（E）、可控性（C）三个维度的组合，确定汽车安全完整性等级（ASIL A至D，以及QM）。安全目标则是针对每一个危害事件所设定的顶层安全要求，例如“防止电池包在充电过程中发生不可控过充”。安全目标不是具体实现方案，而是对风险可接受程度的声明，它进一步向下分解为功能安全需求（FSR）和技术安全需求（TSR），最终落实到BMS的采样、诊断、决策与执行环节。
在BMS中，安全目标通常与以下对象强相关：电芯电压采样链路、电流采样链路、温度采样链路、主控MCU、AFE、继电器驱动、高压互锁回路、绝缘监测、通信链路等。理解这些对象在危害场景中的角色，是后续安全需求分配的基础。
三、方法流程：BMS HARA的工程化步骤
在真实BMS项目中，HARA不是一次会议就能完成的，而是需要与系统、硬件、软件、测试团队协同迭代。典型流程如下：
- 定义分析范围与边界：明确被分析对象是电池包、BMS控制器还是整车高压系统，确定功能清单与运行模式。
- 识别危害与危害事件：从功能失效出发，结合BMS的典型失效模式，如电压采样偏差、继电器粘连、绝缘监测失效、通信丢帧等。
- 场景与工况分析：区分行车、充电、驻车、碰撞、维修等场景，评估暴露度E。
- S/E/C评估与ASIL定级：按照ISO 26262的评分表确定严重度S、暴露度E、可控性C，并查表得到ASIL。
- 制定安全目标：为每个ASIL危害事件定义安全目标，明确安全状态与容错时间。
- 分解功能安全需求：将安全目标分配到系统架构，形成FSR，再细化为TSR。
- 验证与追溯：建立需求与测试用例的追溯矩阵，确保每条安全需求都有验证证据。
工程提示：HARA的输出不是一张静态表格，而是贯穿整个开发周期的“安全基线”。当系统架构、功能定义或运行场景发生变化时，必须重新评估受影响的危害事件与ASIL等级。
四、案例场景：过充保护的安全目标推导
以“BMS未能及时切断充电回路导致电芯过充”为例。危害事件可描述为：在充电过程中，BMS因电压采样失效或逻辑判断错误，未能在电芯达到截止电压时请求停止充电，导致电芯持续过充并可能引发热失控。场景为交流慢充或直流快充，暴露度较高；严重度可导致起火，属于S3；可控性方面，驾驶员通常无法直接干预，属于C3。综合评估后，该危害事件通常被定为ASIL C或ASIL D。
对应的安全目标可表述为：“防止在充电过程中因BMS失效导致电芯不可控过充。”进一步分解为功能安全需求：BMS应具备独立的过充监测与切断能力；应在检测到过充风险时进入安全状态；应在规定容错时间内断开充电回路或请求外部切断。技术安全需求则落到具体实现，例如双路电压采样冗余、独立比较器硬件保护、继电器驱动诊断、充电请求信号监控等。
危害事件：充电中BMS未切断导致电芯过充
S = S3（可能起火）
E = E4（充电场景高频）
C = C3（驾驶员难以控制）
ASIL = D
安全目标 SG：防止充电过程中电芯不可控过充
功能安全需求 FSR1：BMS应独立监测电芯过充风险
功能安全需求 FSR2：检测到过充风险后应在容错时间内进入安全状态
技术安全需求 TSR1：采用双路电压采样与交叉校验
技术安全需求 TSR2：设置独立硬件过压比较与继电器切断路径
五、常见误区与复盘要点
| 常见误区 | 问题本质 | 复盘建议 |
|---|---|---|
| 把HARA当成一次性文档 | 忽视需求变更与场景扩展 | 建立变更触发重新评估机制 |
| 只关注硬件失效，忽略软件逻辑错误 | 危害识别不完整 | 结合FMEA与STPA补充分析 |
| 安全目标写得过于具体 | 混淆目标与方案 | 安全目标应描述“防止什么”，而非“怎么实现” |
| ASIL定级凭经验拍脑袋 | 缺乏评分依据 | 严格对照S/E/C评分表并记录理由 |
| 需求与测试脱节 | 无法证明安全目标达成 | 建立双向追溯矩阵并定期审计 |
关键提醒：BMS的HARA必须覆盖“功能失效”与“功能不足”两类情况。例如，过充保护功能“该动作却没动作”属于功能失效；而“动作过早导致误切断”同样可能引入新的危害。安全目标开发需要同时考虑漏报与误报带来的风险。
六、课程路线图：从概念到落地
本课程后续将按照“概念—方法—案例—实操—复盘”的路径展开。首先建立功能安全与HARA的概念基础，然后深入BMS典型功能的危害识别与ASIL定级方法，接着通过过充、过温、绝缘、继电器粘连等真实场景完成安全目标推导，再进入安全需求分解、架构映射、安全机制设计与验证确认，最后通过排障与复盘专题，帮助你把方法真正落到项目文档与评审中。学习过程中，建议始终围绕一条主线：每一个安全目标都必须能追溯到具体危害，每一个技术安全需求都必须能追溯到安全目标，每一个测试用例都必须能证明安全需求被满足。