ISO26262系列: FSR到TSR转化

个人主页：云纳星辰怀自在

座右铭：“所谓坚持，就是觉得还有希望！”

摘要

在ISO 26262 V模型开发体系中，FSR（功能安全需求）向TSR（技术安全需求）转化，是系统级产品开发阶段（Part 4）的核心活动，也是决定功能安全能否从“纸面合规”走向“工程落地”的关键分水岭。本文从BMS实战视角，系统阐述FSR与TSR本质区别、标准化四步转化法、四大衍生维度，并以ASIL-D过充防护为完整案例，演示从安全目标到全维度TSR的落地全过程（仅供参考）。

1. 核心认知：FSR与TSR本质分界

1.1 为什么转化环节是“死亡之谷”

核心主张：FSR定义安全底线（What），TSR决定落地成败（How）。转化不是写文档，而是安全架构设计决策。

1.2 两者本质边界

转化本质：将抽象的、技术中立的安全语言，翻译成具体的、技术绑定的工程语言。这是安全架构设计的核心决策过程。

1.3 功能安全三层故障模型的映射

在转化过程中，必须始终将功能安全的三层故障模型作为框架。

• Fault是物理层的异常条件（如采样电阻焊点开裂）
• Error是信息层的数据偏离（如ADC读数偏低200mV）
• Failure是功能层的丧失（如充电提前截止）

FSR定义的是Failure的防止边界，而TSR必须覆盖从Fault到Error再到Failure的完整传播链。

既要定义正常功能如何实现，也要定义当功能实现链路自身发生Fault时，如何在Error阶段将其捕获，阻止其演变为Failure。

2. 标准化四步转化法

合规且高效的需求转化，无需凭经验摸索。遵循「解构—映射—衍生—追溯」四步流程，可实现无遗漏、可追溯的完整转化，适配所有ASIL等级。

步骤一：解构FSR — 提取四大核心要素

拿到任意一条FSR，先不急于编写TSR，先拆解其核心构成，确保信息完整：

关键提醒：如果FSR本身写得不完整（缺时间约束、安全状态模糊、动作描述歧义），必须先修正FSR，否则TSR无法正确导出。

步骤二：架构映射 — 功能精准分配到技术模块

结合BMS标准分层架构，将拆解后的安全功能精准分配到对应模块，杜绝功能悬空：

映射示例（过充FSR）：

• 传感层负责：精确采集单体电压值
• 处理层负责：判断电压是否超阈值，触发故障响应
• 执行层负责：可靠断开充电接触器，反馈执行状态
• 通信层负责：将故障状态通过E2E保护报文上报整车

步骤三：衍生TSR — 四大黄金维度全面覆盖

最核心环节。针对每个被分配了任务的模块，从以下四个维度系统生成完整的TSR：

维度一：性能与时序

时间预算设计的关键决策：

TSR中的时间预算不是简单的加法，而是安全架构的时序博弈。两条路径承担着不同的时间角色：

• 硬件比较器路径：响应时间<1ms，作为第一响应者。电压超阈值后直接拉断接触器使能，不依赖任何软件。它的存在允许主MCU路径“从容”地用20ms做更复杂的判断（如连续多次采样确认），而不用担心超过FTTI。这是ASIL-D设计中典型的“快慢组合”分层时序解耦策略。
• 软件主路径：耗时80ms，留有20ms余量应对最差工况抖动。MCU路径不仅判断是否超阈值，还承担故障确认和锁存的职责——确认过压非瞬态干扰后，锁存故障状态，禁止自动恢复。

精度的反向推导逻辑：

±5mV的精度要求不是随意选定。假设电芯不可逆损伤电压为4.55V，安全阈值为4.50V，两者之间的窗口宽度仅为50mV。如果测量精度为±50mV，那么在窗口边缘将出现严重的判决模糊——实际电压4.50V时，测量值可能在4.45V到4.55V之间，导致“该保护时未能保护”（漏报）或“不该保护时误保护”（误报）。因此精度必须显著小于窗口宽度，通常要求精度不超过窗口宽度的十分之一。这便是从安全需求反向推导技术参数的典型逻辑。

信号替代的时序处理：

当传感层的某路信号发生故障时，必须定义备用信号及替代逻辑。例如，用于判断扭矩请求的电机转速信号故障时，可以利用车速信号进行替代计算。替代信号的精度和延迟必须单独评估，确保替代后的全链路时序仍满足FTTI要求。

维度二：安全机制

设计原则：每个FSR必须追问——“如果执行这条FSR的硬件/软件本身出错该如何处理？”

双路径设计的架构决策：

两条监控路径是否共享传感器，是一个关键的架构决策。共享传感器、双路径处理的方案（同一AFE输出，分两路给MCU和比较器）成本较低，但诊断覆盖率中等——它可以检测处理链的失效，但不能检测传感器的共因失效。因此，当采用共享传感器方案时，AFE自检的覆盖范围必须足够大，必须能覆盖基准源漂移、ADC增益误差、通道间串扰等故障模式，否则诊断覆盖率不够。

独立传感器、独立路径的方案（两套独立AFE和基准源）诊断覆盖率最高，能够覆盖传感器共因失效，但成本也最高。通常仅在极高安全要求的场景中使用。

Fail-Safe处理原则：

当关键信号出现故障或信号间不一致时，必须采用Fail-Safe的保守处理方式。例如，巡航主开关仅由一路硬线接入，当L2采样到该硬线信号与CAN信号不一致时（硬线指示未按下，CAN消息却显示激活），L2应以“两者皆未激活”的保守方式处理，直接视为巡航功能关闭。这种处理方式牺牲了部分可用性，但确保了安全性。

故障分类与响应分级：

安全机制检测到的故障应按严重程度分级响应。一般性故障（如单路传感器失效）触发降级运行，系统仍可限功率工作。严重故障（如双路传感器同时失效、接触器粘连）触发紧急响应——首先清除扭矩输出或充电使能，随后通过独立于MCU的硬件路径强制断开高压继电器供电，使系统进入最终安全状态。这种分级响应在保障安全的同时，最大限度地延长了系统的可用运行时间。

维度三：硬件要求

选型红线：TSR直接锁定器件选型范围，是硬件方案评审的硬性通过准则。

硬件要求与E-GAS三层架构的对应：

在E-GAS三层架构中，Level 1功能层按QM或较低ASIL等级开发，Level 2功能监控层和Level 3控制器监控层按ASIL-D开发。硬件要求的TSR主要约束Level 2和Level 3的运行环境——Lockstep核确保Level 2监控算法的计算完整性，MPU确保Level 1（QM）与Level 2（ASIL-D）软件之间的物理隔离，独立看门狗（Level 3）确保即使Level 1和Level 2同时失效，系统仍能通过硬件路径进入安全状态。

维度四：接口与状态

降级策略的典型矩阵：

不同故障场景对应不同的降级策略，需要在TSR中明确定义：

故障响应中的梯度Bypass机制：

当检测到碰撞等需要立即切断动力的严重故障时，正常的扭矩梯度监控应当被暂时旁路。这是因为“请求扭矩瞬间降为零”这个指令在正常情况下是违反梯度限制的，但在碰撞场景下恰恰是安全所需要的。TSR必须明确定义哪些故障场景下梯度监控被Bypass，以及Bypass的持续时间和恢复条件。

四大维度汇总关系：

flowchart TD
FSR[FSR 功能安全需求]

FSR –> D1[维度一：性能与时序]
FSR –> D2[维度二：安全机制]
FSR –> D3[维度三：硬件要求]
FSR –> D4[维度四：接口与状态]

D1 –> Arch[架构层分配]
D2 –> Arch
D3 –> Arch
D4 –> Arch

Arch –> Sense[传感层]
Arch –> Process[处理层]
Arch –> Actuate[执行层]
Arch –> Comm[通信层]

Sense –> TSR_Set[完整TSR集合]
Process –> TSR_Set
Actuate –> TSR_Set
Comm –> TSR_Set

TSR_Set –> Verify[可量化验证<br>HIL / 实车 / 故障注入]

步骤四：建立双向追溯 — 确保合规闭环

• 正向追溯（FSR → TSR）：确认每条安全目标都被充分细化，无遗漏
• 反向追溯（TSR → FSR）：确认每条技术需求都服务于顶层安全目标，无冗余
• 审核要求：无FSR来源的TSR是“多余设计”，无TSR落地的FSR是“需求落空”。必须做到一一对应

3. 完整案例：ASIL-D过充防护的FSR→TSR全链路转化

以BMS最高频、最高风险的“防止电池过充”场景为例，完整演示从安全目标SG到全维度TSR的转化过程。

3.1 顶层安全基线

3.2 FSR层（功能安全需求）

3.3 TSR层（技术安全需求）— 按四大维度展开

性能与时序类TSR

全链路时序验证：采集（10ms）+ 判断（20ms）+ 执行（50ms） = 80ms < 100ms FTTI ✓

安全机制类TSR（ASIL-D核心冗余）

硬件要求类TSR

接口与状态类TSR

3.4 全链路时间预算与冗余路径

关键架构决策：

• 软件主路径耗时80ms，留有20ms余量应对最差工况抖动
• 硬件比较器路径作为并行兜底，响应时间<1ms
• 两条路径物理独立，即使主MCU完全失效，硬件路径仍能在FTTI内强制进入安全状态

3.5 安全架构的故障覆盖性验证

4. 转化中的常见错误及预防

5. 转化后的输出物与团队价值

完成FSR→TSR转化后，应产出以下文档：

对各团队的价值：

• 项目经理：TSR是需求拆解、工作量估算、项目合规的依据
• 硬件工程师：TSR-H类是芯片选型、电路冗余设计的硬性红线
• 软件工程师：TSR-P/M类是算法时序、诊断逻辑、冗余策略的开发基准
• 测试工程师：每条可量化TSR构成测试用例的核心，使验证活动可执行、可评估
• 审核/认证：完整的追溯矩阵是功能安全审核的核心加分项

​

​