📚 课程目录第4章 BMS功能安全需求

4. BMS功能安全需求

在ISO 26262的框架下，功能安全需求并非凭空产生，而是沿着“整车安全目标 → 功能安全需求（FSR） → 技术安全需求（TSR） → 硬件/软件安全需求”的层级逐级分解、逐级细化。BMS作为动力电池系统的核心控制器，其安全需求既要承接整车层面的危害分析与风险评估结果，又要向下约束到具体的采集通道、诊断逻辑、执行动作与通信机制。理解这条分解链路，是量产确认工程中判断“需求是否被正确实现”的前提。

一、核心原理：安全目标的层级化分解

整车安全目标（Safety Goal）来自危害分析与风险评估（HARA），通常以“避免或减轻某类危害事件”的形式描述，并附带ASIL等级。例如：

SG-01：避免电池包因过充导致热失控——ASIL C。
SG-02：避免车辆在行驶中因电池异常断电造成动力丧失——ASIL B。
SG-03：避免高压系统在碰撞后仍带电危及人员——ASIL D。

安全目标本身是整车级、面向危害的，不能直接交给BMS软件工程师实现。必须经过功能安全概念（FSC）阶段，转化为功能安全需求（FSR）。FSR描述“系统应做什么来达成安全目标”，仍与具体实现无关。例如SG-01可分解为：

FSR-01-1：系统应能检测电池单体过压状态，并在达到阈值前触发充电限制。
FSR-01-2：系统应能检测充电回路异常，并在无法限制时切断充电接触器。
FSR-01-3：系统应在检测到过充风险时向整车控制器发出降功率或停机请求。

随后进入技术安全概念（TSC）阶段，FSR被分配到具体的系统架构元素上，形成技术安全需求（TSR）。TSR必须明确到可验证的层面：输入信号、判断条件、响应时间、输出动作、故障容错时间（FTTI）等。例如FSR-01-1可细化为：

TSR-BMS-OV-01：
  输入：单体电压采集值（AFE通道，采样周期 ≤ 10 ms）
  判断：任一单体电压 ≥ 4.25 V 且持续 ≥ 3 个采样周期
  响应：在 100 ms 内将充电允许标志置为禁止，并上报过压故障
  安全状态：限制充电电流至 0，若 500 ms 内未生效则断开充电接触器
  ASIL：C
  验证方法：故障注入 + 台架测试 + 整车路试

可以看到，TSR已经具备“可设计、可实现、可测试”的属性。再往下，TSR会继续分解为硬件安全需求（如AFE冗余采集、基准电压诊断）和软件安全需求（如过压判断逻辑、故障确认计数器、安全状态迁移）。

二、分解方法：从安全目标到TSR的实操路径

分解过程不是简单的文字改写，而是一个带约束的工程推理过程。推荐按以下步骤执行：

建立安全目标与危害事件的对应关系：明确每个SG覆盖哪些危害事件、涉及哪些整车工况。
识别BMS承担的功能边界：区分BMS自身可实现的安全措施与需要整车其他系统配合的措施。
分配ASIL等级：根据架构冗余、独立性、可控性进行ASIL分解或裁剪，并记录理由。
定义安全状态与FTTI：明确BMS在故障发生后必须在多长时间内进入安全状态。
编写TSR并建立追溯链接：每条TSR必须能向上追溯到FSR和SG，向下关联到具体的软硬件需求与测试用例。
评审与确认：由功能安全经理、系统工程师、软件/硬件负责人共同评审分解的完整性与一致性。

分解过程中最常见的错误是“跳级”：直接从安全目标写出软件判断逻辑，缺少FSR和TSR的中间层。这会导致需求无法追溯，也无法在架构变更时评估影响范围。

三、需求追溯：双向链路与追溯矩阵

需求追溯的核心是“双向可追溯”：向上能回答“这条需求为什么存在”，向下能回答“这条需求由谁实现、被谁验证”。在量产确认中，追溯矩阵（Traceability Matrix）是审核重点。一个简化的追溯关系如下表所示：

层级	标识	内容摘要	向上追溯	向下关联
安全目标	SG-01	避免过充导致热失控	HARA-01	FSR-01-1/2/3
功能安全需求	FSR-01-1	检测单体过压并限制充电	SG-01	TSR-BMS-OV-01
技术安全需求	TSR-BMS-OV-01	过压判断与充电禁止	FSR-01-1	SW-OV-001、HW-AFE-002
软件安全需求	SW-OV-001	过压确认计数器与故障置位	TSR-BMS-OV-01	TC-OV-001、TC-OV-002
测试用例	TC-OV-001	注入4.3 V单体电压验证响应	SW-OV-001	测试报告 RPT-OV-001

追溯矩阵不仅要覆盖正常路径，还要覆盖安全机制本身的需求。例如AFE基准电压诊断、开路检测、冗余采集通道的一致性校验，都应有独立的TSR和测试用例。否则在功能安全审核中会被判定为“安全机制未定义需求”。

四、需求管理与量产确认的衔接

需求管理不是一次性文档工作，而是贯穿概念、开发、测试、量产、运维的全生命周期活动。在量产确认阶段，重点检查以下内容：

需求基线是否冻结：量产软件对应的需求版本必须唯一、可识别，避免“代码与需求不一致”。
变更是否受控：任何需求变更都应经过影响分析，评估对安全目标、ASIL、测试用例的影响。
追溯链是否完整：从SG到测试报告，不应存在断链或孤立节点。
验证证据是否闭环：每条TSR至少有一条测试用例和一份测试报告支撑。
安全分析是否更新：FMEA、FTA、DFA的结论应与最新需求保持一致。

量产确认中常见的误区是：只检查软件功能是否“能工作”，而不检查需求追溯是否完整。功能正常不等于功能安全合规，缺少追溯链会在审核中被直接判为不符合项。

下面这张图展示了从整车安全目标到BMS技术安全需求的分解与追溯关系，同时标出了量产确认关注的验证闭环。

在实际项目中，建议使用需求管理工具（如DOORS、Polarion、Jama）维护追溯关系，并在每次需求变更后自动生成追溯矩阵报告。对于BMS这类安全相关控制器，追溯链的完整性直接决定了量产确认能否通过功能安全审核。把分解方法、追溯机制和需求管理流程固化到工程模板中，才能让功能安全从“文档合规”真正落到“产品安全”。