个人主页云纳星辰怀自在座右铭“所谓坚持就是觉得还有希望”前言案例某BMS项目在功能安全审核时被退回审核员指出“FSR-02.01要求‘过压时切断充电回路’但对应的TSR没有规定采集精度、没有分解时间预算、没有定义信号丢失时的替代处理。”项目因此延期两个月。工程师无奈“我们明明写了安全需求为什么就是不通过”在ISO 26262功能安全开发中我们经常面临一个非常现实的问题“TSR到底怎么写才算规范有没有模板写完了之后怎么分配给硬件和软件团队”FSR向TSR的转化是功能安全开发中从“纸面合规”走向“工程落地”的关键一步。FSR是“要做什么”WhatTSR是“具体怎么做”How。两者之间的转化质量直接决定了安全机制能否真正在硬件和软件中实现。前文已经介绍FSR和TSR区别本文将从工程实战角度彻底讲透TSR的编写与分配FSR与TSR的本质边界What vs How技术中立 vs 技术绑定TSR三大核心特性可测试性、技术具体化、覆盖完整性TSR七要素编写模板从格式到内容的完整规范四大维度全景覆盖性能时序、安全机制、硬件要求、接口状态TSR分配方法硬件vs软件的判断标准、HSI接口规范ASIL等级在分配时的三大“坑”及应对策略适用读者功能安全工程师、系统架构师、硬件/软件工程师、审核准备人员适用标准ISO 26262-2018适用场景TSR编写、功能安全审核、需求评审、安全架构设计更新时间2026年8月一、先说结论TSR是功能安全从“纸面”走向“工程”的关键一步容易混淆的说法正确理解TSR就是把FSR复制一遍加些数字✅TSR需要从四大维度系统展开性能时序、安全机制、硬件要求、接口状态只要总时间小于FTTI就行✅必须明确每条路径的时间预算且考虑最差工况TSR写完了就等于安全需求做完了✅TSR需要分配到硬件/软件并通过HSI定义软硬件接口契约一个组件可以同时处理不同ASIL等级的需求✅如果接收不同ASIL等级需求该组件必须按最高ASIL等级开发ASIL分解可以在任何阶段做✅ASIL分解可以在概念阶段、系统设计、硬件设计、软件设计等多个阶段进行总结TSR核心价值在于---FSR定义安全底线WhatTSR决定落地成败How。转化是安全架构设计决策。二、FSR与TSR本质边界透彻理解两者的区别是正确编写TSR的前提维度FSR功能安全需求TSR技术安全需求系统层级系统级整车/整包子系统/组件级硬件、软件模块核心问题What— 系统要做什么才安全How— 技术具体怎么做才能实现FSR技术依赖性技术中立不指定MCU型号、AFE芯片、通信总线技术绑定指定具体芯片、电路拓扑、算法、协议内容特征触发条件 核心动作 时间约束 安全状态采集周期、精度、响应时间、冗余方式、诊断机制、E2E配置时间属性直接继承FTTI故障容错时间间隔将FTTI拆解为各环节的时间预算采集→判断→执行验证方式功能级验证系统是否在FTTI内进入安全状态可量化核验HIL/实车/故障注入逐条验证参数指标典型表述“电芯过压时应在100ms内切断充电回路”“电压采集周期≤10ms精度±5mVMCU判断≤20ms继电器断开≤50ms”转化本质将抽象的、技术中立的安全语言翻译成具体的、技术绑定的工程语言。这是安全架构设计的核心决策过程。三、TSR的三大核心特性在动笔之前先建立这三个根本认知特性大白话示例✅可测试性“能被验证”——能通过测试或审查来证明其实现“响应时间300ms”可测“系统足够快”不可测✅技术具体化“明确实现方式”——不是抽象功能描述而是具体技术参数“用77GHz毫米波雷达” vs “用雷达”✅覆盖完整性“全部覆盖”——所有FSR都要有对应的TSR每个FSR至少有一条TSR与之关联TSR是工程师能直接干活的需求文档不是“理想”是“方案”。四、TSR的七要素编写模板根据ISO26262的要求和行业实践一个完整的TSR至少应包含以下七个核心要素要素核心问题编写要求示例唯一标识符“这条需求叫什么名字”结构化编号便于追溯管理TSR-01-01需求描述“具体要做什么”标准句式“在[条件]下[谁]应[做什么]达到[量化指标]”“雷达应选用77GHz频段探测距离≥200m”ASIL等级“安全等级是多少”继承自所追溯的FSRASIL-D来源追溯“从哪条FSR来的”必填项建立FSR↔FSR链接关联FSR-01️安全机制“出问题了怎么处理”描述诊断、监控或冗余措施“通信超时50ms触发报警”️分配对象“谁来负责实现”硬件/软件/二者共同雷达硬件 / 雷达软件✅验证方法“怎么证明它实现了”测试/审查/分析HIL测试 / 代码审查可追溯性是功能安全评审的必查项每个TSR都要能追溯到对应的FSR。五、需求描述的编写精要5.1 编写五原则原则说明1. 使用主动语态和确定动词多用“应”“必须”避免“支持”“允许”2. 明确触发条件和执行主体“谁”在“什么条件”下做“什么事”3. 绑定技术方案“通过SPI接口”“使用硬件比较器”“基于CAN-FD协议”4. 关联时序约束将时间要求直接写入动作描述5. 明确边界条件全温区-40°C~85°C、全生命周期、供电电压波动范围等5.2 典型错误与正确写法对比维度❌ 错误FSR风格或模糊✅ 正确TSR风格采集“系统应采集电池电压”“BMS主板上电后AFE芯片应以10ms固定周期扫描所有单体电压通道并通过SPI总线将数据存入缓冲区”判断“软件需判断是否过压”“当MCU读取任意单体电压值4.5V时应在20ms内完成连续三次采样确认防止瞬态干扰误触发”执行“过压时应切断充电”“若过压故障被确认MCU应通过专用硬件引脚GPIO在1ms内输出低电平至充电接触器驱动芯片使其物理断开”安全机制“通信应可靠”“CAN报文采用E2E Profile 1保护CRC计数器接收端检测到连续2帧错误或超时时在50ms内触发安全状态”5.3 量化参数的反向推导法精度要求不是随意选定的必须从安全阈值反向推导推导逻辑以电压采样为例确定安全边界电芯不可逆损伤电压4.55V安全阈值4.50V →窗口宽度50mV总误差预算必须显著小于窗口宽度通常取1/3~1/5 →±10mV将总误差分配到各环节初始精度±3mV 温漂±4mV 寿命衰减±3mV ±10mV正确TSR写法TSR-P2-1AFE芯片在25°C±5°C条件下初始测量精度应≤±3mV。TSR-P2-2在全温区-40°C~85°C范围内经软件温度补偿算法校准后总测量误差应≤±10mV。六、四大维度全景覆盖为确保TSR无遗漏从以下四个维度系统生成TSR6.1 维度一性能与时序TSR-P核心任务将FTTI拆解为各环节的时间预算。环节TSR要素定义方法示例传感层采集周期保证FTTI内完成至少N次采样确认故障“电压采集周期≤10ms”传感层测量精度由安全阈值与极限值之间的“窗口宽度”反向推导“全温区误差±5mV”处理层运算耗时从收到数据到输出判断结果的最大时间“MCU判断逻辑执行≤20ms”执行层执行延时从输出指令到物理断开的最大时间“继电器断开时间≤50ms”全链路时序验证采集运算执行≤FTTI且留有余量“10205080ms100ms余量20ms”时间预算设计的关键决策TSR中的时间预算不是简单的加法而是安全架构的时序博弈。两条路径承担着不同的时间角色硬件比较器路径响应时间1ms作为第一响应者。电压超阈值后直接拉断接触器使能不依赖任何软件。它的存在允许主MCU路径“从容”地用20ms做更复杂的判断。软件主路径耗时80ms留有20ms余量应对最差工况抖动。MCU路径不仅判断是否超阈值还承担故障确认和锁存的职责。6.2 维度二安全机制TSR-M核心追问“如果执行这条FSR的硬件/软件本身出错该如何处理”四层描述法层次核心问题编写要点示例①故障检测如何发现故障检测方法、频率、检测对象“AFE基准源自检周期性注入已知电压校验ADC读数”②故障响应发现后立即做什么响应动作、时间要求“检测到故障1ms内通过INT引脚中断并上报状态字”③故障恢复/降级系统后续进入何种状态降级策略、锁存/恢复条件“故障永久锁存需诊断工具清除禁止自动恢复”④故障指示如何对外通知通信方式、报文内容“故障码通过UDS存储CAN总线100ms周期上报E2E保护报文”安全机制六种基本类型类型TSR要素示例冗余路径独立于主处理链路的监控路径“主MCU算法硬件比较器双路径监控任意路径触发即切断”自检/诊断检测采集/执行链路本身的故障“AFE基准自检、通道开路/短路诊断软件实时轮询寄存器”状态回读执行指令后验证执行结果“接触器辅助触点状态回读指令与状态不匹配触发高阶故障”软件校验软件层面合理性判断“电压数据合理性区间校验2.0V~5.0V”信号交叉校验多源信号比对“两路硬线信号与CAN信号交叉校验不一致时取保守值”故障确认反跳避免瞬时干扰误判“信号异常持续超过设定次数后才确认故障”6.3 维度三硬件要求TSR-H核心任务将安全需求转化为硬件硬性约束直接锁定器件选型范围。TSR要素定义方法示例ASIL等级执行该TSR的硬件需满足的安全等级“安全决策MCUASIL-D”锁步核是否要求双核锁步运行“主MCU采用Lockstep架构双核同步校验”ECC/MPU内存保护要求“RAM/Flash ECCMPU实现QM与ASIL软件物理隔离”独立看门狗程序流监控要求“外部SBC提供窗口/问答式看门狗独立于主MCU时钟”⚠️选型红线TSR-H类需求是硬件方案评审的硬性通过准则。6.4 维度四接口与状态TSR-I核心任务定义系统与外部的通信契约和故障后的行为策略。TSR要素定义方法示例E2E保护安全相关信号需端到端保护“E2E Profile 1CRCCounter防丢失/篡改/延迟”故障锁存故障消除后是否自动恢复“永久锁存需外部工具解锁杜绝临界状态反复启停”降级逻辑故障后的功能降级策略“单路AFE故障→限功率运行双路故障→禁止上高压”故障响应分级按严重程度定义不同响应级别“一般故障限制扭矩严重故障清除输出并强制断开”降级策略矩阵示例故障场景信号故障标记扭矩方向限制最大正向扭矩限制梯度限制加速踏板信号故障是允许当前方向禁止反向以固定梯度降为零受限电机转速信号故障是允许所有方向基于替代值计算受限碰撞信号有效无故障禁止正向降为零Bypass旁路⚠️梯度Bypass机制碰撞等需立即切断动力的严重故障场景下正常扭矩梯度监控应被暂时旁路瞬间降为零是安全所需而非违反梯度限制。TSR必须明确定义Bypass的触发场景、持续时间和恢复条件。七、TSR的分配方法7.1 分配的核心原则原则说明1️⃣ 每条TSR必须分配每个TSR必须分配给至少一个系统架构要素硬件组件或软件组件2️⃣按最高ASIL开发每个架构要素必须实现分配给它的最高ASIL等级的TSR3️⃣保证免于干涉FFI不同ASIL等级的要素之间必须保证互不干扰⚠️原则2详解如果一个硬件组件同时收到了ASIL-D和ASIL-B的TSR整个组件必须按照ASIL-D的等级来开发。因为“低等级”的部分出问题了一样会影响到“高等级”的部分。原则3大白话ASIL-D的代码和QM的代码不能互相干扰。通常通过内存分区、时间隔离、通信隔离等手段实现。7.2 硬件vs软件的分配判断标准分配给谁判断标准示例⚡硬件涉及物理实现、芯片选型、电路设计、电气参数“选用77GHz毫米波雷达”“工作温度-40°C~85°C”软件涉及算法逻辑、数据处理、通信协议、状态管理“实现双路冗余算法”“50ms周期发送数据”二者共同需要软硬件协同配合“雷达探测精度±2m”——硬件选型软件温度补偿算法分配原则硬件决定“能不能做到”软件决定“怎么做到位”。7.3 TSR分配示例ACC系统TSR ID需求描述ASIL分配给谁TSR-01-01选用77GHz毫米波雷达探测距离≥200mD雷达硬件TSR-01-02全温度范围内测距精度±2mD雷达硬件软件TSR-01-03上电时执行自检BISTD雷达固件TSR-01-04每50ms通过CAN-FD发送数据D雷达软件TSR-02-01选用ASIL-D等级的MCUD控制器硬件TSR-02-02运行在QNX安全操作系统上D控制器软件TSR-02-03使用双路冗余算法计算跟车距离D控制器软件TSR-02-04计算超时300ms触发报警D控制器软件TSR-03-01制动执行器支持减速度限制功能D执行器硬件TSR-03-02监控实际减速度超限时切断指令D执行器软件关键洞察同一个FSR比如“雷达应能正确检测前方目标”会被拆分成硬件TSR选什么雷达和软件TSR怎么处理数据——两者协同工作缺一不可。7.4 HSI软硬件接口规范当TSR分配给“共同”时必须在HSI软硬件接口规范中明确定义契约类型内容数据契约共享数据的精度、格式、更新速率、有效范围时序契约软件读取数据的最晚时间点、硬件响应指令的最大延迟错误契约硬件检测故障后如何通知软件软件如何确认并清除故障状态八、ASIL等级在分配时的三大“坑”8.1 场景一一个组件收到不同ASIL等级的需求问题一个MCU既要跑ASIL-D的刹车控制算法又要跑QM的空调控制逻辑。怎么办答案整个MCU必须按照ASIL-D来开发。⚠️ISO 26262规定如果一个要素被分配了多个不同ASIL等级的需求该要素必须满足其中最高的ASIL等级。为什么因为硬件是“共享资源”——QM的代码跑在同一个CPU上如果QM的代码出问题了比如内存越界可能把ASIL-D的代码也搞崩了。解决方案方案实现方式适用场景硬件隔离用两个独立的MCU——一个跑ASIL-D一个跑QM最高安全要求成本不敏感软件隔离通过内存保护单元MPU或Hypervisor实现分区隔离主流方案平衡成本与安全8.2 场景二ASIL分解——把“一个D”拆成“两个B”公式ASIL-D ASIL-B(D) ASIL-B(D)什么时候用当“直接做ASIL-D太贵了、太难了”可把需求拆成两个相互独立的低等级需求由两个独立组件分别实现。前提条件条件说明独立性两个组件必须充分独立——不能共用同一个电源、同一个时钟、同一个传感器证据必须通过相关失效分析DFA证明它们确实独立示例原始需求分解后制动系统需在100ms内响应ASIL-D① 主制动通道响应时间100msASIL-B② 备用制动通道响应时间100msASIL-B③ 两个通道相互独立通过DFA证明 ASIL分解可以在安全生命周期的多个阶段进行——功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段都可以。8.3 场景三安全机制本身也可能失效这是一个容易被忽视的“坑”。问题安全机制本身也可能出故障。如果针对一个ASIL-D的TSR设计了安全机制A但安全机制A本身失效了就会变成潜伏故障Latent Fault——平时看不出来一旦主功能出问题它就帮不上忙了。解决方案对安全机制A再加一层监控——这就是“安全机制的安全机制”。 一般来讲考虑到成本和复杂度安全机制不超过两层。ISO 26262认为三点及以上故障就可以视为安全故障否则会出现无穷嵌套。九、TSR编写与分配中常见的“坑”坑❌ 错误写法✅ 正确写法坑1TSR写得像FSR“系统应能检测前方障碍物”“雷达应在50ms内通过CAN-FD发送目标距离数据精度±2m”坑2TSR没有关联安全机制只写了“用77GHz雷达”“用77GHz雷达”“上电自检”“通信超时监控”“数据合理性检查”坑3ASIL兼容性把ASIL-D和QM分给同一MCU没做隔离用两个独立MCU或通过MPU/Hypervisor做分区隔离坑4没有可追溯性TSR和FSR之间没有关联建立SG→FSR→TSR→测试用例的完整追溯链十、TSR编写检查清单与输出物10.1 编写检查清单检查项说明状态□ 句式规范是否采用“在[条件]下[谁]应[做什么]达到[量化指标]”格式□ 技术绑定是否指定了具体芯片、总线、协议或算法□ 量化清晰所有时间、精度、周期、阈值是否有明确数值和单位□ 安全机制是否描述了主功能失效时的“B计划”□ ASIL一致ASIL等级是否与所追溯FSR一致或符合分解规则□ 追溯完整是否明确填写“来源追溯”链接到FSR编号□ 可验证性测试工程师能否直接根据描述编写通过/不通过准则□ 分配明确是否明确了分配给硬件、软件还是共同负责□ 边界条件是否考虑了全温区、全生命周期、供电波动等极端工况10.2 转化后的输出物输出物内容说明TSR规格书按七要素格式和四大维度组织的完整TSR条目集合时间预算分析报告每条安全相关时序链路的预算分解及FTTI符合性论证双向追溯矩阵FSR↔TSR追溯表标注覆盖率每条FSR至少有一条TSR落地TSR验证计划每条TSR的验证方法HIL/台架/实车/故障注入及通过准则降级策略矩阵各故障场景的信号替代方案、扭矩/功率限制、梯度Bypass条件HSI软硬件接口规范软硬件间的数据契约、时序契约和错误契约十一、总结11.1 核心结论表要点结论FSR vs TSR本质FSR定义“What”做什么才安全TSR定义“How”具体怎么做TSR三大特性可测试性、技术具体化、覆盖完整性TSR七个要素唯一标识符、需求描述、ASIL等级、来源追溯、安全机制、分配对象、验证方法四大衍生维度性能与时序P、安全机制M、硬件要求H、接口与状态I分配三原则每条TSR必须分配要素按最高ASIL开发保证免于干涉FFIASIL分解ASIL-DASIL-B(D)ASIL-B(D)须通过DFA证明独立性安全机制嵌套安全机制本身也可能失效需加监控层一般不超过两层审核红线双向追溯完整 每条TSR可量化验证11.2 面试高频考点问题标准回答FSR和TSR的本质区别是什么FSR是系统级的“What”技术中立TSR是子系统级的“How”技术绑定指定具体芯片、协议、参数TSR的七个要素是什么唯一标识符、需求描述、ASIL等级、来源追溯、安全机制、分配对象、验证方法TSR的四大衍生维度是什么性能与时序采集周期/精度/时序、安全机制冗余/自检/回读、硬件要求ASIL/锁步/ECC、接口与状态E2E/锁存/降级为什么一个组件收到不同ASIL等级需求要按最高级开发因为硬件是共享资源——低等级代码出问题如内存越界可能影响高等级代码ASIL分解的前提是什么两个组件必须充分独立——不能共用同一电源、时钟、传感器且须通过DFA证明HSI中需要定义什么数据契约精度/格式/更新速率、时序契约最晚读取时间/最大延迟、错误契约故障通知和清除方式11.3 工程实践提醒先确认硬件能力再写TSR参数——精度写“±1mV”但AFE只能做到±5mV审核时会被驳回每个FSR都要追问“如果执行这条FSR的硬件/软件本身出错怎么办”——这是安全机制TSR的来源时序图是时间预算的有力工具——标注各环节最坏情况耗时确认总和 FTTI用工具管理追溯矩阵——DOORS/Jama/Excel都可以但必须保证正向和反向追溯完整TSR必须可量化验证——“确保通信安全”不是有效的TSR“E2E Profile 1CRCCounter”才是十二、参考资料ISO 26262-2018. Road vehicles — Functional safety. Part 4: Product development at the system level.ISO 26262-2018. Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses.AUTOSAR. End-to-End Communication Protection Specification.Infineon. AURIX TC3xx Safety Manual. 2023.NXP. S32K3 Safety Application Note. 2024.参考文章ISO26262系列: FSR到TSR转化ISO26262系列: MISRA C与汽车软件的安全工程学ISO26262系列: 故障注入硬件注入与软件注入完整对比 ISO26262功能安全系列: 技术安全需求（TSR）编写
个人主页云纳星辰怀自在座右铭“所谓坚持就是觉得还有希望”前言案例某BMS项目在功能安全审核时被退回审核员指出“FSR-02.01要求‘过压时切断充电回路’但对应的TSR没有规定采集精度、没有分解时间预算、没有定义信号丢失时的替代处理。”项目因此延期两个月。工程师无奈“我们明明写了安全需求为什么就是不通过”在ISO 26262功能安全开发中我们经常面临一个非常现实的问题“TSR到底怎么写才算规范有没有模板写完了之后怎么分配给硬件和软件团队”FSR向TSR的转化是功能安全开发中从“纸面合规”走向“工程落地”的关键一步。FSR是“要做什么”WhatTSR是“具体怎么做”How。两者之间的转化质量直接决定了安全机制能否真正在硬件和软件中实现。前文已经介绍FSR和TSR区别本文将从工程实战角度彻底讲透TSR的编写与分配FSR与TSR的本质边界What vs How技术中立 vs 技术绑定TSR三大核心特性可测试性、技术具体化、覆盖完整性TSR七要素编写模板从格式到内容的完整规范四大维度全景覆盖性能时序、安全机制、硬件要求、接口状态TSR分配方法硬件vs软件的判断标准、HSI接口规范ASIL等级在分配时的三大“坑”及应对策略适用读者功能安全工程师、系统架构师、硬件/软件工程师、审核准备人员适用标准ISO 26262-2018适用场景TSR编写、功能安全审核、需求评审、安全架构设计更新时间2026年8月一、先说结论TSR是功能安全从“纸面”走向“工程”的关键一步容易混淆的说法正确理解TSR就是把FSR复制一遍加些数字✅TSR需要从四大维度系统展开性能时序、安全机制、硬件要求、接口状态只要总时间小于FTTI就行✅必须明确每条路径的时间预算且考虑最差工况TSR写完了就等于安全需求做完了✅TSR需要分配到硬件/软件并通过HSI定义软硬件接口契约一个组件可以同时处理不同ASIL等级的需求✅如果接收不同ASIL等级需求该组件必须按最高ASIL等级开发ASIL分解可以在任何阶段做✅ASIL分解可以在概念阶段、系统设计、硬件设计、软件设计等多个阶段进行总结TSR核心价值在于---FSR定义安全底线WhatTSR决定落地成败How。转化是安全架构设计决策。二、FSR与TSR本质边界透彻理解两者的区别是正确编写TSR的前提维度FSR功能安全需求TSR技术安全需求系统层级系统级整车/整包子系统/组件级硬件、软件模块核心问题What— 系统要做什么才安全How— 技术具体怎么做才能实现FSR技术依赖性技术中立不指定MCU型号、AFE芯片、通信总线技术绑定指定具体芯片、电路拓扑、算法、协议内容特征触发条件 核心动作 时间约束 安全状态采集周期、精度、响应时间、冗余方式、诊断机制、E2E配置时间属性直接继承FTTI故障容错时间间隔将FTTI拆解为各环节的时间预算采集→判断→执行验证方式功能级验证系统是否在FTTI内进入安全状态可量化核验HIL/实车/故障注入逐条验证参数指标典型表述“电芯过压时应在100ms内切断充电回路”“电压采集周期≤10ms精度±5mVMCU判断≤20ms继电器断开≤50ms”转化本质将抽象的、技术中立的安全语言翻译成具体的、技术绑定的工程语言。这是安全架构设计的核心决策过程。三、TSR的三大核心特性在动笔之前先建立这三个根本认知特性大白话示例✅可测试性“能被验证”——能通过测试或审查来证明其实现“响应时间300ms”可测“系统足够快”不可测✅技术具体化“明确实现方式”——不是抽象功能描述而是具体技术参数“用77GHz毫米波雷达” vs “用雷达”✅覆盖完整性“全部覆盖”——所有FSR都要有对应的TSR每个FSR至少有一条TSR与之关联TSR是工程师能直接干活的需求文档不是“理想”是“方案”。四、TSR的七要素编写模板根据ISO26262的要求和行业实践一个完整的TSR至少应包含以下七个核心要素要素核心问题编写要求示例唯一标识符“这条需求叫什么名字”结构化编号便于追溯管理TSR-01-01需求描述“具体要做什么”标准句式“在[条件]下[谁]应[做什么]达到[量化指标]”“雷达应选用77GHz频段探测距离≥200m”ASIL等级“安全等级是多少”继承自所追溯的FSRASIL-D来源追溯“从哪条FSR来的”必填项建立FSR↔FSR链接关联FSR-01️安全机制“出问题了怎么处理”描述诊断、监控或冗余措施“通信超时50ms触发报警”️分配对象“谁来负责实现”硬件/软件/二者共同雷达硬件 / 雷达软件✅验证方法“怎么证明它实现了”测试/审查/分析HIL测试 / 代码审查可追溯性是功能安全评审的必查项每个TSR都要能追溯到对应的FSR。五、需求描述的编写精要5.1 编写五原则原则说明1. 使用主动语态和确定动词多用“应”“必须”避免“支持”“允许”2. 明确触发条件和执行主体“谁”在“什么条件”下做“什么事”3. 绑定技术方案“通过SPI接口”“使用硬件比较器”“基于CAN-FD协议”4. 关联时序约束将时间要求直接写入动作描述5. 明确边界条件全温区-40°C~85°C、全生命周期、供电电压波动范围等5.2 典型错误与正确写法对比维度❌ 错误FSR风格或模糊✅ 正确TSR风格采集“系统应采集电池电压”“BMS主板上电后AFE芯片应以10ms固定周期扫描所有单体电压通道并通过SPI总线将数据存入缓冲区”判断“软件需判断是否过压”“当MCU读取任意单体电压值4.5V时应在20ms内完成连续三次采样确认防止瞬态干扰误触发”执行“过压时应切断充电”“若过压故障被确认MCU应通过专用硬件引脚GPIO在1ms内输出低电平至充电接触器驱动芯片使其物理断开”安全机制“通信应可靠”“CAN报文采用E2E Profile 1保护CRC计数器接收端检测到连续2帧错误或超时时在50ms内触发安全状态”5.3 量化参数的反向推导法精度要求不是随意选定的必须从安全阈值反向推导推导逻辑以电压采样为例确定安全边界电芯不可逆损伤电压4.55V安全阈值4.50V →窗口宽度50mV总误差预算必须显著小于窗口宽度通常取1/3~1/5 →±10mV将总误差分配到各环节初始精度±3mV 温漂±4mV 寿命衰减±3mV ±10mV正确TSR写法TSR-P2-1AFE芯片在25°C±5°C条件下初始测量精度应≤±3mV。TSR-P2-2在全温区-40°C~85°C范围内经软件温度补偿算法校准后总测量误差应≤±10mV。六、四大维度全景覆盖为确保TSR无遗漏从以下四个维度系统生成TSR6.1 维度一性能与时序TSR-P核心任务将FTTI拆解为各环节的时间预算。环节TSR要素定义方法示例传感层采集周期保证FTTI内完成至少N次采样确认故障“电压采集周期≤10ms”传感层测量精度由安全阈值与极限值之间的“窗口宽度”反向推导“全温区误差±5mV”处理层运算耗时从收到数据到输出判断结果的最大时间“MCU判断逻辑执行≤20ms”执行层执行延时从输出指令到物理断开的最大时间“继电器断开时间≤50ms”全链路时序验证采集运算执行≤FTTI且留有余量“10205080ms100ms余量20ms”时间预算设计的关键决策TSR中的时间预算不是简单的加法而是安全架构的时序博弈。两条路径承担着不同的时间角色硬件比较器路径响应时间1ms作为第一响应者。电压超阈值后直接拉断接触器使能不依赖任何软件。它的存在允许主MCU路径“从容”地用20ms做更复杂的判断。软件主路径耗时80ms留有20ms余量应对最差工况抖动。MCU路径不仅判断是否超阈值还承担故障确认和锁存的职责。6.2 维度二安全机制TSR-M核心追问“如果执行这条FSR的硬件/软件本身出错该如何处理”四层描述法层次核心问题编写要点示例①故障检测如何发现故障检测方法、频率、检测对象“AFE基准源自检周期性注入已知电压校验ADC读数”②故障响应发现后立即做什么响应动作、时间要求“检测到故障1ms内通过INT引脚中断并上报状态字”③故障恢复/降级系统后续进入何种状态降级策略、锁存/恢复条件“故障永久锁存需诊断工具清除禁止自动恢复”④故障指示如何对外通知通信方式、报文内容“故障码通过UDS存储CAN总线100ms周期上报E2E保护报文”安全机制六种基本类型类型TSR要素示例冗余路径独立于主处理链路的监控路径“主MCU算法硬件比较器双路径监控任意路径触发即切断”自检/诊断检测采集/执行链路本身的故障“AFE基准自检、通道开路/短路诊断软件实时轮询寄存器”状态回读执行指令后验证执行结果“接触器辅助触点状态回读指令与状态不匹配触发高阶故障”软件校验软件层面合理性判断“电压数据合理性区间校验2.0V~5.0V”信号交叉校验多源信号比对“两路硬线信号与CAN信号交叉校验不一致时取保守值”故障确认反跳避免瞬时干扰误判“信号异常持续超过设定次数后才确认故障”6.3 维度三硬件要求TSR-H核心任务将安全需求转化为硬件硬性约束直接锁定器件选型范围。TSR要素定义方法示例ASIL等级执行该TSR的硬件需满足的安全等级“安全决策MCUASIL-D”锁步核是否要求双核锁步运行“主MCU采用Lockstep架构双核同步校验”ECC/MPU内存保护要求“RAM/Flash ECCMPU实现QM与ASIL软件物理隔离”独立看门狗程序流监控要求“外部SBC提供窗口/问答式看门狗独立于主MCU时钟”⚠️选型红线TSR-H类需求是硬件方案评审的硬性通过准则。6.4 维度四接口与状态TSR-I核心任务定义系统与外部的通信契约和故障后的行为策略。TSR要素定义方法示例E2E保护安全相关信号需端到端保护“E2E Profile 1CRCCounter防丢失/篡改/延迟”故障锁存故障消除后是否自动恢复“永久锁存需外部工具解锁杜绝临界状态反复启停”降级逻辑故障后的功能降级策略“单路AFE故障→限功率运行双路故障→禁止上高压”故障响应分级按严重程度定义不同响应级别“一般故障限制扭矩严重故障清除输出并强制断开”降级策略矩阵示例故障场景信号故障标记扭矩方向限制最大正向扭矩限制梯度限制加速踏板信号故障是允许当前方向禁止反向以固定梯度降为零受限电机转速信号故障是允许所有方向基于替代值计算受限碰撞信号有效无故障禁止正向降为零Bypass旁路⚠️梯度Bypass机制碰撞等需立即切断动力的严重故障场景下正常扭矩梯度监控应被暂时旁路瞬间降为零是安全所需而非违反梯度限制。TSR必须明确定义Bypass的触发场景、持续时间和恢复条件。七、TSR的分配方法7.1 分配的核心原则原则说明1️⃣ 每条TSR必须分配每个TSR必须分配给至少一个系统架构要素硬件组件或软件组件2️⃣按最高ASIL开发每个架构要素必须实现分配给它的最高ASIL等级的TSR3️⃣保证免于干涉FFI不同ASIL等级的要素之间必须保证互不干扰⚠️原则2详解如果一个硬件组件同时收到了ASIL-D和ASIL-B的TSR整个组件必须按照ASIL-D的等级来开发。因为“低等级”的部分出问题了一样会影响到“高等级”的部分。原则3大白话ASIL-D的代码和QM的代码不能互相干扰。通常通过内存分区、时间隔离、通信隔离等手段实现。7.2 硬件vs软件的分配判断标准分配给谁判断标准示例⚡硬件涉及物理实现、芯片选型、电路设计、电气参数“选用77GHz毫米波雷达”“工作温度-40°C~85°C”软件涉及算法逻辑、数据处理、通信协议、状态管理“实现双路冗余算法”“50ms周期发送数据”二者共同需要软硬件协同配合“雷达探测精度±2m”——硬件选型软件温度补偿算法分配原则硬件决定“能不能做到”软件决定“怎么做到位”。7.3 TSR分配示例ACC系统TSR ID需求描述ASIL分配给谁TSR-01-01选用77GHz毫米波雷达探测距离≥200mD雷达硬件TSR-01-02全温度范围内测距精度±2mD雷达硬件软件TSR-01-03上电时执行自检BISTD雷达固件TSR-01-04每50ms通过CAN-FD发送数据D雷达软件TSR-02-01选用ASIL-D等级的MCUD控制器硬件TSR-02-02运行在QNX安全操作系统上D控制器软件TSR-02-03使用双路冗余算法计算跟车距离D控制器软件TSR-02-04计算超时300ms触发报警D控制器软件TSR-03-01制动执行器支持减速度限制功能D执行器硬件TSR-03-02监控实际减速度超限时切断指令D执行器软件关键洞察同一个FSR比如“雷达应能正确检测前方目标”会被拆分成硬件TSR选什么雷达和软件TSR怎么处理数据——两者协同工作缺一不可。7.4 HSI软硬件接口规范当TSR分配给“共同”时必须在HSI软硬件接口规范中明确定义契约类型内容数据契约共享数据的精度、格式、更新速率、有效范围时序契约软件读取数据的最晚时间点、硬件响应指令的最大延迟错误契约硬件检测故障后如何通知软件软件如何确认并清除故障状态八、ASIL等级在分配时的三大“坑”8.1 场景一一个组件收到不同ASIL等级的需求问题一个MCU既要跑ASIL-D的刹车控制算法又要跑QM的空调控制逻辑。怎么办答案整个MCU必须按照ASIL-D来开发。⚠️ISO 26262规定如果一个要素被分配了多个不同ASIL等级的需求该要素必须满足其中最高的ASIL等级。为什么因为硬件是“共享资源”——QM的代码跑在同一个CPU上如果QM的代码出问题了比如内存越界可能把ASIL-D的代码也搞崩了。解决方案方案实现方式适用场景硬件隔离用两个独立的MCU——一个跑ASIL-D一个跑QM最高安全要求成本不敏感软件隔离通过内存保护单元MPU或Hypervisor实现分区隔离主流方案平衡成本与安全8.2 场景二ASIL分解——把“一个D”拆成“两个B”公式ASIL-D ASIL-B(D) ASIL-B(D)什么时候用当“直接做ASIL-D太贵了、太难了”可把需求拆成两个相互独立的低等级需求由两个独立组件分别实现。前提条件条件说明独立性两个组件必须充分独立——不能共用同一个电源、同一个时钟、同一个传感器证据必须通过相关失效分析DFA证明它们确实独立示例原始需求分解后制动系统需在100ms内响应ASIL-D① 主制动通道响应时间100msASIL-B② 备用制动通道响应时间100msASIL-B③ 两个通道相互独立通过DFA证明 ASIL分解可以在安全生命周期的多个阶段进行——功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段都可以。8.3 场景三安全机制本身也可能失效这是一个容易被忽视的“坑”。问题安全机制本身也可能出故障。如果针对一个ASIL-D的TSR设计了安全机制A但安全机制A本身失效了就会变成潜伏故障Latent Fault——平时看不出来一旦主功能出问题它就帮不上忙了。解决方案对安全机制A再加一层监控——这就是“安全机制的安全机制”。 一般来讲考虑到成本和复杂度安全机制不超过两层。ISO 26262认为三点及以上故障就可以视为安全故障否则会出现无穷嵌套。九、TSR编写与分配中常见的“坑”坑❌ 错误写法✅ 正确写法坑1TSR写得像FSR“系统应能检测前方障碍物”“雷达应在50ms内通过CAN-FD发送目标距离数据精度±2m”坑2TSR没有关联安全机制只写了“用77GHz雷达”“用77GHz雷达”“上电自检”“通信超时监控”“数据合理性检查”坑3ASIL兼容性把ASIL-D和QM分给同一MCU没做隔离用两个独立MCU或通过MPU/Hypervisor做分区隔离坑4没有可追溯性TSR和FSR之间没有关联建立SG→FSR→TSR→测试用例的完整追溯链十、TSR编写检查清单与输出物10.1 编写检查清单检查项说明状态□ 句式规范是否采用“在[条件]下[谁]应[做什么]达到[量化指标]”格式□ 技术绑定是否指定了具体芯片、总线、协议或算法□ 量化清晰所有时间、精度、周期、阈值是否有明确数值和单位□ 安全机制是否描述了主功能失效时的“B计划”□ ASIL一致ASIL等级是否与所追溯FSR一致或符合分解规则□ 追溯完整是否明确填写“来源追溯”链接到FSR编号□ 可验证性测试工程师能否直接根据描述编写通过/不通过准则□ 分配明确是否明确了分配给硬件、软件还是共同负责□ 边界条件是否考虑了全温区、全生命周期、供电波动等极端工况10.2 转化后的输出物输出物内容说明TSR规格书按七要素格式和四大维度组织的完整TSR条目集合时间预算分析报告每条安全相关时序链路的预算分解及FTTI符合性论证双向追溯矩阵FSR↔TSR追溯表标注覆盖率每条FSR至少有一条TSR落地TSR验证计划每条TSR的验证方法HIL/台架/实车/故障注入及通过准则降级策略矩阵各故障场景的信号替代方案、扭矩/功率限制、梯度Bypass条件HSI软硬件接口规范软硬件间的数据契约、时序契约和错误契约十一、总结11.1 核心结论表要点结论FSR vs TSR本质FSR定义“What”做什么才安全TSR定义“How”具体怎么做TSR三大特性可测试性、技术具体化、覆盖完整性TSR七个要素唯一标识符、需求描述、ASIL等级、来源追溯、安全机制、分配对象、验证方法四大衍生维度性能与时序P、安全机制M、硬件要求H、接口与状态I分配三原则每条TSR必须分配要素按最高ASIL开发保证免于干涉FFIASIL分解ASIL-DASIL-B(D)ASIL-B(D)须通过DFA证明独立性安全机制嵌套安全机制本身也可能失效需加监控层一般不超过两层审核红线双向追溯完整 每条TSR可量化验证11.2 面试高频考点问题标准回答FSR和TSR的本质区别是什么FSR是系统级的“What”技术中立TSR是子系统级的“How”技术绑定指定具体芯片、协议、参数TSR的七个要素是什么唯一标识符、需求描述、ASIL等级、来源追溯、安全机制、分配对象、验证方法TSR的四大衍生维度是什么性能与时序采集周期/精度/时序、安全机制冗余/自检/回读、硬件要求ASIL/锁步/ECC、接口与状态E2E/锁存/降级为什么一个组件收到不同ASIL等级需求要按最高级开发因为硬件是共享资源——低等级代码出问题如内存越界可能影响高等级代码ASIL分解的前提是什么两个组件必须充分独立——不能共用同一电源、时钟、传感器且须通过DFA证明HSI中需要定义什么数据契约精度/格式/更新速率、时序契约最晚读取时间/最大延迟、错误契约故障通知和清除方式11.3 工程实践提醒先确认硬件能力再写TSR参数——精度写“±1mV”但AFE只能做到±5mV审核时会被驳回每个FSR都要追问“如果执行这条FSR的硬件/软件本身出错怎么办”——这是安全机制TSR的来源时序图是时间预算的有力工具——标注各环节最坏情况耗时确认总和 FTTI用工具管理追溯矩阵——DOORS/Jama/Excel都可以但必须保证正向和反向追溯完整TSR必须可量化验证——“确保通信安全”不是有效的TSR“E2E Profile 1CRCCounter”才是十二、参考资料ISO 26262-2018. Road vehicles — Functional safety. Part 4: Product development at the system level.ISO 26262-2018. Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses.AUTOSAR. End-to-End Communication Protection Specification.Infineon. AURIX TC3xx Safety Manual. 2023.NXP. S32K3 Safety Application Note. 2024.参考文章ISO26262系列: FSR到TSR转化ISO26262系列: MISRA C与汽车软件的安全工程学ISO26262系列: 故障注入硬件注入与软件注入完整对比