ISO26262系列: FSR到TSR转化

个人主页云纳星辰怀自在座右铭“所谓坚持就是觉得还有希望”摘要在ISO 26262 V模型开发体系中FSR功能安全需求向TSR技术安全需求转化是系统级产品开发阶段Part 4的核心活动也是决定功能安全能否从“纸面合规”走向“工程落地”的关键分水岭。本文从BMS实战视角系统阐述FSR与TSR本质区别、标准化四步转化法、四大衍生维度并以ASIL-D过充防护为完整案例演示从安全目标到全维度TSR的落地全过程仅供参考。1. 核心认知FSR与TSR本质分界1.1 为什么转化环节是“死亡之谷”常见问题根因后果FSR写得漂亮但软件/硬件团队看不懂FSR使用“技术中立”的语言未指定具体实现方式需求无法落地编码开发停滞TSR缺少量化参数未将FTTI拆解为各环节的明确时间预算集成测试无标可对认证卡壳安全机制遗漏FSR只描述了“正常行为”未考虑功能实现链路本身故障时的行为诊断覆盖率不足SPFM/LFM不达标追溯性断裂TSR未标注来源FSR或FSR找不到对应TSR功能安全审核被驳回项目延期核心主张FSR定义安全底线WhatTSR决定落地成败How。转化不是写文档而是安全架构设计决策。1.2 两者本质边界维度FSR功能安全需求TSR技术安全需求系统层级系统级整车/整包子系统/组件级硬件、软件模块核心问题What— 系统要做什么才安全。定义功能和边界How— 技术具体怎么做才能实现FSR。定义技术和参数关键概念由SG拆解而来功能层面安全约束技术中立、只讲行为、不讲实现架构定义后将抽象的功能要求拆解为硬件、软件、时序、诊断、通信的具体量化指标技术依赖性技术中立不指定MCU型号、AFE芯片、通信总线技术绑定指定具体芯片、电路拓扑、算法、协议内容特征触发条件 核心动作 时间约束继承FTTI 安全状态采集周期、精度、响应时间、冗余方式、诊断机制、E2E配置时间属性直接继承FTTI故障容错时间间隔将FTTI拆解为各环节的时间预算采集→判断→执行验证方式功能级验证系统是否在FTTI内进入安全状态可量化核验HIL/实车/故障注入逐条验证参数指标典型表述“电芯过压时应在100ms内切断充电回路”“电压采集周期≤10ms精度±5mVMCU判断≤20ms继电器断开≤50ms”转化本质将抽象的、技术中立的安全语言翻译成具体的、技术绑定的工程语言。这是安全架构设计的核心决策过程。1.3 功能安全三层故障模型的映射在转化过程中必须始终将功能安全的三层故障模型作为框架。Fault是物理层的异常条件如采样电阻焊点开裂Error是信息层的数据偏离如ADC读数偏低200mVFailure是功能层的丧失如充电提前截止FSR定义的是Failure的防止边界而TSR必须覆盖从Fault到Error再到Failure的完整传播链。既要定义正常功能如何实现也要定义当功能实现链路自身发生Fault时如何在Error阶段将其捕获阻止其演变为Failure。2. 标准化四步转化法合规且高效的需求转化无需凭经验摸索。遵循「解构—映射—衍生—追溯」四步流程可实现无遗漏、可追溯的完整转化适配所有ASIL等级。步骤一解构FSR — 提取四大核心要素拿到任意一条FSR先不急于编写TSR先拆解其核心构成确保信息完整要素含义检查要点示例过充防护触发条件什么场景/故障会激活该安全功能是否唯一、明确、可检测“任意单体电压 4.5V”核心动作系统必须执行的核心安全操作是否单一、无歧义“切断充电回路”时间约束从触发到完成的最大允许时间是否直接继承FTTI“≤100ms”安全状态故障处置后系统的最终稳态是否明确定义锁存/恢复策略“高压断开故障锁存禁止自动恢复”关键提醒如果FSR本身写得不完整缺时间约束、安全状态模糊、动作描述歧义必须先修正FSR否则TSR无法正确导出。步骤二架构映射 — 功能精准分配到技术模块结合BMS标准分层架构将拆解后的安全功能精准分配到对应模块杜绝功能悬空架构层级负责的功能对应的TSR维度侧重传感层电压/电流/温度采集AFE、NTC、分流器性能时序、安全机制自检处理层主MCU/安全MCU执行判断逻辑、故障分类与决策安全机制冗余路径、硬件要求执行层高低边驱动、接触器/继电器控制性能时序、安全机制状态回读通信层CAN/LIN总线数据传输接口状态E2E保护映射示例过充FSR传感层负责精确采集单体电压值处理层负责判断电压是否超阈值触发故障响应执行层负责可靠断开充电接触器反馈执行状态通信层负责将故障状态通过E2E保护报文上报整车步骤三衍生TSR — 四大黄金维度全面覆盖最核心环节。针对每个被分配了任务的模块从以下四个维度系统生成完整的TSR维度一性能与时序TSR要素定义方法示例采集周期保证在FTTI内完成至少N次采样以确认故障避免瞬态误触发“电压采集周期 ≤ 10ms”100ms FTTI内可采集10次测量精度由安全阈值与电芯极限电压之间的“窗口宽度”反向推导“全温区、全生命周期误差 ±5mV”运算耗时处理层从收到数据到输出判断结果的最大时间需最差工况分析“MCU判断逻辑执行 ≤ 20ms”执行延时从输出指令到物理断开的最大时间“继电器断开时间 ≤ 50ms”全链路时序采集运算执行 ≤ FTTI且留有合理余量“102050 80ms 100ms余量20ms”时间预算设计的关键决策TSR中的时间预算不是简单的加法而是安全架构的时序博弈。两条路径承担着不同的时间角色硬件比较器路径响应时间1ms作为第一响应者。电压超阈值后直接拉断接触器使能不依赖任何软件。它的存在允许主MCU路径“从容”地用20ms做更复杂的判断如连续多次采样确认而不用担心超过FTTI。这是ASIL-D设计中典型的“快慢组合”分层时序解耦策略。软件主路径耗时80ms留有20ms余量应对最差工况抖动。MCU路径不仅判断是否超阈值还承担故障确认和锁存的职责——确认过压非瞬态干扰后锁存故障状态禁止自动恢复。精度的反向推导逻辑±5mV的精度要求不是随意选定。假设电芯不可逆损伤电压为4.55V安全阈值为4.50V两者之间的窗口宽度仅为50mV。如果测量精度为±50mV那么在窗口边缘将出现严重的判决模糊——实际电压4.50V时测量值可能在4.45V到4.55V之间导致“该保护时未能保护”漏报或“不该保护时误保护”误报。因此精度必须显著小于窗口宽度通常要求精度不超过窗口宽度的十分之一。这便是从安全需求反向推导技术参数的典型逻辑。信号替代的时序处理当传感层的某路信号发生故障时必须定义备用信号及替代逻辑。例如用于判断扭矩请求的电机转速信号故障时可以利用车速信号进行替代计算。替代信号的精度和延迟必须单独评估确保替代后的全链路时序仍满足FTTI要求。维度二安全机制TSR要素定义方法示例冗余路径是否有独立于主处理链路的监控路径“主MCU算法 独立硬件比较器双路径监控任意路径触发即切断高压”自检/诊断如何检测采集/执行链路本身的故障“AFE基准源自检周期性注入已知电压校验ADC读数通道开路/短路诊断”状态回读执行指令后是否验证执行结果“接触器辅助触点状态回读确认实际分合状态指令与状态不匹配触发高阶故障”软件校验软件层面的合理性判断拦截隐性故障“电压数据合理性区间校验2.0V~5.0V拦截ADC卡死、通信数据异常”信号冗余与交叉校验关键信号的冗余采集与多源比对“两路硬线信号采集并与CAN信号交叉校验不一致时取保守值”故障确认反跳机制避免瞬时干扰导致误判“故障确认计数器与恢复计数器信号异常持续超过设定次数后才确认故障”设计原则每个FSR必须追问——“如果执行这条FSR的硬件/软件本身出错该如何处理”双路径设计的架构决策两条监控路径是否共享传感器是一个关键的架构决策。共享传感器、双路径处理的方案同一AFE输出分两路给MCU和比较器成本较低但诊断覆盖率中等——它可以检测处理链的失效但不能检测传感器的共因失效。因此当采用共享传感器方案时AFE自检的覆盖范围必须足够大必须能覆盖基准源漂移、ADC增益误差、通道间串扰等故障模式否则诊断覆盖率不够。独立传感器、独立路径的方案两套独立AFE和基准源诊断覆盖率最高能够覆盖传感器共因失效但成本也最高。通常仅在极高安全要求的场景中使用。Fail-Safe处理原则当关键信号出现故障或信号间不一致时必须采用Fail-Safe的保守处理方式。例如巡航主开关仅由一路硬线接入当L2采样到该硬线信号与CAN信号不一致时硬线指示未按下CAN消息却显示激活L2应以“两者皆未激活”的保守方式处理直接视为巡航功能关闭。这种处理方式牺牲了部分可用性但确保了安全性。故障分类与响应分级安全机制检测到的故障应按严重程度分级响应。一般性故障如单路传感器失效触发降级运行系统仍可限功率工作。严重故障如双路传感器同时失效、接触器粘连触发紧急响应——首先清除扭矩输出或充电使能随后通过独立于MCU的硬件路径强制断开高压继电器供电使系统进入最终安全状态。这种分级响应在保障安全的同时最大限度地延长了系统的可用运行时间。维度三硬件要求TSR要素定义方法示例ASIL等级执行该TSR的硬件需满足的安全等级“安全决策MCUASIL-D”锁步核是否要求双核锁步运行“主MCU采用Lockstep架构双核同步校验”ECC/MPU内存保护要求“RAM/Flash ECCMPU实现QM与ASIL软件的物理隔离”独立看门狗程序流监控要求“外部SBC提供窗口/问答式看门狗独立于主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 1QM与Level 2ASIL-D软件之间的物理隔离独立看门狗Level 3确保即使Level 1和Level 2同时失效系统仍能通过硬件路径进入安全状态。维度四接口与状态TSR要素定义方法示例E2E保护安全相关CAN信号需端到端保护“过压故障状态报文E2E Profile 1CRCCounter防丢失/篡改/延迟”故障锁存故障消除后是否自动恢复“过压故障永久锁存需外部诊断工具解锁杜绝临界状态反复启停”降级逻辑故障后的功能降级策略“单路AFE故障→限功率运行双路AFE故障→禁止上高压”故障响应分级按严重程度定义不同响应级别“一般故障限制扭矩梯度与最大值严重故障清除输出并强制断开高压”降级策略的典型矩阵不同故障场景对应不同的降级策略需要在TSR中明确定义故障场景信号故障标记扭矩方向限制最大正向扭矩限制最大负向扭矩限制梯度限制加速踏板信号故障是允许当前方向禁止反向以固定梯度降为零以固定梯度降为零受限电机转速信号故障是允许所有方向基于替代值计算基于替代值计算受限巡航/限速信号故障是按意图不允许使用巡航/限速上限按意图无限制碰撞信号有效无故障禁止正向降为零按系统能力无限制梯度Bypass故障响应中的梯度Bypass机制当检测到碰撞等需要立即切断动力的严重故障时正常的扭矩梯度监控应当被暂时旁路。这是因为“请求扭矩瞬间降为零”这个指令在正常情况下是违反梯度限制的但在碰撞场景下恰恰是安全所需要的。TSR必须明确定义哪些故障场景下梯度监控被Bypass以及Bypass的持续时间和恢复条件。四大维度汇总关系步骤四建立双向追溯 — 确保合规闭环正向追溯FSR → TSR确认每条安全目标都被充分细化无遗漏反向追溯TSR → FSR确认每条技术需求都服务于顶层安全目标无冗余审核要求无FSR来源的TSR是“多余设计”无TSR落地的FSR是“需求落空”。必须做到一一对应3. 完整案例ASIL-D过充防护的FSR→TSR全链路转化以BMS最高频、最高风险的“防止电池过充”场景为例完整演示从安全目标SG到全维度TSR的转化过程。3.1 顶层安全基线要素内容安全目标SG防止动力电池过充导致热失控ASIL等级ASIL DFTTI100ms从故障发生到热失控的最大允许处置时长3.2 FSR层功能安全需求编号FSR内容触发条件核心动作时间约束安全状态FSR-02.01过压保护任意单体电压 4.5V切断充电回路≤100ms高压断开故障锁存禁止自动恢复FSR-02.02采集链路故障保护检测到电压采集信号异常切断充电回路≤500ms高压断开故障锁存3.3 TSR层技术安全需求— 按四大维度展开性能与时序类TSR编号TSR内容量化参数追溯FSRTSR-P1单体电压完整采集周期≤ 10msFSR-02.01/02.02TSR-P2全温区、全生命周期电压测量精度误差 ±5mVFSR-02.01TSR-P3MCU过压判断逻辑执行时间≤ 20ms需最差工况分析核验FSR-02.01TSR-P4充电接触器物理断开时间≤ 50msFSR-02.01全链路时序验证采集10ms 判断20ms 执行50ms 80ms 100ms FTTI✓安全机制类TSRASIL-D核心冗余编号TSR内容具体方案追溯FSRTSR-M1双路径独立过压监控主路径MCU算法监控备用路径硬件比较器/锁步核监控。任意路径触发即切断高压FSR-02.01/02.02TSR-M2电压数据合理性校验软件周期性校验电压区间2.0V~5.0V拦截ADC卡死、通信数据异常FSR-02.02TSR-M3AFE芯片自检基准电压自检、通道开路/短路诊断软件实时轮询自检寄存器FSR-02.02TSR-M4接触器状态回读实时采集辅助触点状态诊断粘连故障指令与状态不匹配触发高阶保护FSR-02.01硬件要求类TSR编号TSR内容具体要求追溯FSRTSR-H1安全决策MCUASIL-D等级搭载硬件锁步核、MPU内存保护、Flash/RAM ECC校验FSR-02.01/02.02接口与状态类TSR编号TSR内容具体要求追溯FSRTSR-I1停止充电CAN报文保护E2E端到端保护Profile 1规避通信干扰、数据丢失、篡改风险FSR-02.01TSR-I2过压故障锁存永久锁存安全状态禁止系统自动恢复需外部诊断工具解锁FSR-02.013.4 全链路时间预算与冗余路径关键架构决策软件主路径耗时80ms留有20ms余量应对最差工况抖动硬件比较器路径作为并行兜底响应时间1ms两条路径物理独立即使主MCU完全失效硬件路径仍能在FTTI内强制进入安全状态3.5 安全架构的故障覆盖性验证假设故障场景主检测路径冗余检测路径故障响应时间AFE通道增益误差导致电压读数系统性偏低TSR-M2合理性校验可发现部分严重偏差但若偏差仍在合理区间内则可能漏报TSR-M3 AFE自检检测到基准源漂移或通道故障≤500msFSR-02.02主MCU程序跑飞或死机TSR-P3软件路径失效TSR-M1硬件比较器路径独立触发响应时间小于1ms1ms接触器触点粘连断开指令无法物理分断TSR-P4断开指令已发出TSR-M4辅助触点状态回读检测到指令与状态不匹配触发高阶故障响应≤50ms 回读周期CAN报文在总线上丢失或损坏发送端正常发送TSR-I1接收端E2E校验失败触发通信超时故障响应≤通信超时阈值4. 转化中的常见错误及预防错误类型典型表现预防方法性能参数拍脑袋精度写“±1mV”但选定AFE根本达不到先确认芯片实际能力再写TSR参数安全机制遗漏FSR只写了正常行为TSR未考虑“如果采集链路本身坏了怎么办”每个FSR必须追问“执行这条FSR的硬件/软件自身失效时如何保证安全”时间预算超支各环节时间加起来超过FTTI先画时序图标注各环节最坏情况耗时确认总和FTTI且有合理余量追溯性断裂TSR无法追溯到FSR或FSR无对应TSR使用DOORS/Jama等工具建立需求追溯矩阵评审时逐条核对精度与可用性失衡精度要求过高导致频繁误触发或精度要求过低导致漏报风险从安全阈值与极限值之间的窗口反向推导精度需求结合AFE实际能力确定合理容差信号替代逻辑缺失未定义关键信号的备用来源及Fail-Safe处理方式对每个安全相关的输入信号明确其故障后的替代信号或保守处理策略5. 转化后的输出物与团队价值完成FSR→TSR转化后应产出以下文档TSR规格书按“四大维度”组织的TSR条目每条含量化参数和验证准则时间预算分析报告每条安全相关时序链路的预算分解及FTTI符合性论证双向追溯矩阵FSR↔TSR追溯表标注覆盖率每条FSR至少有一条TSR落地TSR验证计划每条TSR的验证方法HIL/台架/实车/故障注入及通过准则降级策略矩阵各故障场景下的信号替代方案、扭矩/功率限制、梯度Bypass条件对各团队的价值项目经理TSR是需求拆解、工作量估算、项目合规的依据硬件工程师TSR-H类是芯片选型、电路冗余设计的硬性红线软件工程师TSR-P/M类是算法时序、诊断逻辑、冗余策略的开发基准测试工程师每条可量化TSR构成测试用例的核心使验证活动可执行、可评估审核/认证完整的追溯矩阵是功能安全审核的核心加分项​​