第一部分TSR怎么写才算规范TSR的三大核心特性一个规范的TSR必须具备以下三个核心特性特性大白话示例✅可测试性“能被验证”——能通过测试或审查来证明它实现了“响应时间300ms”可测“系统足够快”不可测✅技术具体化“明确实现方式”——不是抽象的功能描述而是具体的技术参数“用77GHz毫米波雷达” vs “用雷达”✅覆盖完整性“全部覆盖”——所有FSR都要有对应的TSR每个FSR至少有一条TSR与之关联TSR是工程师能直接干活的需求文档不是“理想”是“方案”。一个好的TSR长什么样根据ISO 26262的要求和行业实践一个完整的TSR至少应包含以下七个核心要素要素问的问题示例唯一标识符“这条需求叫什么名字”TSR-01-01需求描述“具体要做什么”“雷达应选用77GHz频段探测距离≥200m”ASIL等级“安全等级是多少”ASIL-D来源追溯“从哪条FSR来的”关联FSR-01️安全机制“出问题了怎么处理”“通信超时50ms触发报警”️分配对象“谁来负责实现”雷达硬件 / 雷达软件 / 二者共同✅验证方法“怎么证明它实现了”测试 / 审查 / 分析可追溯性是功能安全评审的必查项每个TSR都要能追溯到对应的FSR。❌ 好TSR vs 坏TSR类型写法问题在哪❌ 坏TSR“雷达要可靠”太模糊。“可靠”是什么意思没法测❌ 坏TSR“软件不能有bug”这是废话不是需求。所有软件都不想有bug✅ 好TSR“雷达应在-40℃~85℃全温度范围内满足测距精度±2mASIL-D”具体、可测、有边界条件写TSR的核心原则用**“在[条件]下[谁]应[做什么]达到[量化指标]ASIL [X]”** 的句式。第二部分TSR怎么分配FSR是“功能层面”的需求TSR是“技术层面”的需求。但TSR最终要落实到具体的硬件和软件上这就涉及到一个关键问题——分配Allocation。分配的核心原则根据ISO 26262的要求TSR分配遵循以下核心原则1️⃣每个TSR必须分配给至少一个系统架构要素硬件组件或软件组件2️⃣每个架构要素必须实现分配给它的最高ASIL等级的TSR如果一个硬件组件同时收到了ASIL-D和ASIL-B的TSR整个组件必须按照ASIL-D的等级来开发。因为“低等级”的部分出问题了一样会影响到“高等级”的部分。3️⃣不同ASIL等级的要素之间必须保证“免于干涉Freedom from Interference”大白话ASIL-D的代码和QM的代码不能互相干扰。通常通过内存分区、时间隔离、通信隔离等手段实现。️ 怎么判断TSR该分给硬件还是软件这是一个非常实际的问题。行业里常用的判断标准是分配给谁判断标准示例⚡硬件涉及物理实现、芯片选型、电路设计、电气参数“选用77GHz毫米波雷达”“工作温度-40℃~85℃”软件涉及算法逻辑、数据处理、通信协议、状态管理“实现双路冗余算法”“50ms周期发送数据”二者共同需要软硬件协同配合“雷达探测精度±2m”——硬件选型软件温度补偿算法分配原则硬件决定“能不能做到”软件决定“怎么做到位”。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怎么处理数据——两者协同工作缺一不可。第三部分ASIL等级在分配时的“坑”场景一一个组件收到不同ASIL等级的需求问题一个MCU既要跑ASIL-D的刹车控制算法又要跑QM的空调控制逻辑。怎么办答案整个MCU必须按照ASIL-D来开发。ISO 26262规定如果一个要素被分配了多个不同ASIL等级的需求该要素必须满足其中最高的ASIL等级。为什么呢因为硬件是“共享资源”——QM的代码跑在同一个CPU上如果QM的代码出问题了比如内存越界可能把ASIL-D的代码也搞崩了。解决方案硬件隔离用两个独立的MCU——一个跑ASIL-D的安全功能一个跑QM的非安全功能软件隔离在同一个MCU上通过内存保护单元MPU或Hypervisor实现分区隔离场景二ASIL分解——把“一个D”拆成“两个B”还记得第5期我们提到的ASIL分解吗ASIL-D ASIL-B(D) ASIL-B(D)什么时候用当你觉得“直接做ASIL-D太贵了、太难了”可以考虑把需求拆成两个相互独立的低等级需求由两个独立的组件分别实现。前提条件独立性两个组件必须充分独立——不能共用同一个电源、同一个时钟、同一个传感器证据必须通过相关失效分析DFA证明它们确实独立示例原始需求分解后制动系统需在100ms内响应ASIL-D① 主制动通道响应时间100msASIL-B② 备用制动通道响应时间100msASIL-B③ 两个通道相互独立通过DFA证明ASIL分解可以在安全生命周期的多个阶段进行——功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段都可以。场景三安全机制本身也可能失效这是一个容易被忽视的“坑”。安全机制本身也可能出故障。如果你针对一个ASIL-D的TSR设计了安全机制A但安全机制A本身失效了就会变成潜伏故障Latent Fault——平时看不出来一旦主功能出问题它就帮不上忙了。解决方案对安全机制A再加一层监控——这就是“安全机制的安全机制”。一般来讲考虑到成本和复杂度安全机制不超过两层。ISO 26262认为三点及以上故障就可以视为安全故障否则会出现无穷嵌套。第四部分TSR分配全景图把以上内容串起来TSR从产生到分配的完整流程是这样的关键节点TSR分配完成后HSI软硬件接口规范就可以定义了——这是硬件团队和软件团队“分头干活”的分界线。TSR编写与分配中常见的“坑”坑1TSR写得像FSR❌ “系统应能检测前方障碍物” → 这是FSR不是TSR✅ “雷达应在50ms内通过CAN-FD发送目标距离数据精度±2m” → 这才是TSRFSR是“要什么”TSR是“怎么做”。坑2TSR没有关联安全机制❌ 只写了“用77GHz雷达”没写“雷达坏了怎么办”✅ 写了“用77GHz雷达” “上电自检” “通信超时监控” “数据合理性检查”每个TSR都应该配套安全机制。坑3分配时忘了考虑ASIL兼容性❌ 把ASIL-D和QM的需求分给同一个MCU但没做隔离✅ 要么用两个独立的MCU要么通过MPU/Hypervisor做分区隔离坑4没有建立可追溯性❌ TSR和FSR之间没有关联审核员问“这个TSR从哪来的”答不上来✅ 建立SG → FSR → TSR → 测试用例的完整追溯链 汽车电子ISO 26262功能安全系列（第15期）：技术安全需求（TSR）的编写与分配
第一部分TSR怎么写才算规范TSR的三大核心特性一个规范的TSR必须具备以下三个核心特性特性大白话示例✅可测试性“能被验证”——能通过测试或审查来证明它实现了“响应时间300ms”可测“系统足够快”不可测✅技术具体化“明确实现方式”——不是抽象的功能描述而是具体的技术参数“用77GHz毫米波雷达” vs “用雷达”✅覆盖完整性“全部覆盖”——所有FSR都要有对应的TSR每个FSR至少有一条TSR与之关联TSR是工程师能直接干活的需求文档不是“理想”是“方案”。一个好的TSR长什么样根据ISO 26262的要求和行业实践一个完整的TSR至少应包含以下七个核心要素要素问的问题示例唯一标识符“这条需求叫什么名字”TSR-01-01需求描述“具体要做什么”“雷达应选用77GHz频段探测距离≥200m”ASIL等级“安全等级是多少”ASIL-D来源追溯“从哪条FSR来的”关联FSR-01️安全机制“出问题了怎么处理”“通信超时50ms触发报警”️分配对象“谁来负责实现”雷达硬件 / 雷达软件 / 二者共同✅验证方法“怎么证明它实现了”测试 / 审查 / 分析可追溯性是功能安全评审的必查项每个TSR都要能追溯到对应的FSR。❌ 好TSR vs 坏TSR类型写法问题在哪❌ 坏TSR“雷达要可靠”太模糊。“可靠”是什么意思没法测❌ 坏TSR“软件不能有bug”这是废话不是需求。所有软件都不想有bug✅ 好TSR“雷达应在-40℃~85℃全温度范围内满足测距精度±2mASIL-D”具体、可测、有边界条件写TSR的核心原则用**“在[条件]下[谁]应[做什么]达到[量化指标]ASIL [X]”** 的句式。第二部分TSR怎么分配FSR是“功能层面”的需求TSR是“技术层面”的需求。但TSR最终要落实到具体的硬件和软件上这就涉及到一个关键问题——分配Allocation。分配的核心原则根据ISO 26262的要求TSR分配遵循以下核心原则1️⃣每个TSR必须分配给至少一个系统架构要素硬件组件或软件组件2️⃣每个架构要素必须实现分配给它的最高ASIL等级的TSR如果一个硬件组件同时收到了ASIL-D和ASIL-B的TSR整个组件必须按照ASIL-D的等级来开发。因为“低等级”的部分出问题了一样会影响到“高等级”的部分。3️⃣不同ASIL等级的要素之间必须保证“免于干涉Freedom from Interference”大白话ASIL-D的代码和QM的代码不能互相干扰。通常通过内存分区、时间隔离、通信隔离等手段实现。️ 怎么判断TSR该分给硬件还是软件这是一个非常实际的问题。行业里常用的判断标准是分配给谁判断标准示例⚡硬件涉及物理实现、芯片选型、电路设计、电气参数“选用77GHz毫米波雷达”“工作温度-40℃~85℃”软件涉及算法逻辑、数据处理、通信协议、状态管理“实现双路冗余算法”“50ms周期发送数据”二者共同需要软硬件协同配合“雷达探测精度±2m”——硬件选型软件温度补偿算法分配原则硬件决定“能不能做到”软件决定“怎么做到位”。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怎么处理数据——两者协同工作缺一不可。第三部分ASIL等级在分配时的“坑”场景一一个组件收到不同ASIL等级的需求问题一个MCU既要跑ASIL-D的刹车控制算法又要跑QM的空调控制逻辑。怎么办答案整个MCU必须按照ASIL-D来开发。ISO 26262规定如果一个要素被分配了多个不同ASIL等级的需求该要素必须满足其中最高的ASIL等级。为什么呢因为硬件是“共享资源”——QM的代码跑在同一个CPU上如果QM的代码出问题了比如内存越界可能把ASIL-D的代码也搞崩了。解决方案硬件隔离用两个独立的MCU——一个跑ASIL-D的安全功能一个跑QM的非安全功能软件隔离在同一个MCU上通过内存保护单元MPU或Hypervisor实现分区隔离场景二ASIL分解——把“一个D”拆成“两个B”还记得第5期我们提到的ASIL分解吗ASIL-D ASIL-B(D) ASIL-B(D)什么时候用当你觉得“直接做ASIL-D太贵了、太难了”可以考虑把需求拆成两个相互独立的低等级需求由两个独立的组件分别实现。前提条件独立性两个组件必须充分独立——不能共用同一个电源、同一个时钟、同一个传感器证据必须通过相关失效分析DFA证明它们确实独立示例原始需求分解后制动系统需在100ms内响应ASIL-D① 主制动通道响应时间100msASIL-B② 备用制动通道响应时间100msASIL-B③ 两个通道相互独立通过DFA证明ASIL分解可以在安全生命周期的多个阶段进行——功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段都可以。场景三安全机制本身也可能失效这是一个容易被忽视的“坑”。安全机制本身也可能出故障。如果你针对一个ASIL-D的TSR设计了安全机制A但安全机制A本身失效了就会变成潜伏故障Latent Fault——平时看不出来一旦主功能出问题它就帮不上忙了。解决方案对安全机制A再加一层监控——这就是“安全机制的安全机制”。一般来讲考虑到成本和复杂度安全机制不超过两层。ISO 26262认为三点及以上故障就可以视为安全故障否则会出现无穷嵌套。第四部分TSR分配全景图把以上内容串起来TSR从产生到分配的完整流程是这样的关键节点TSR分配完成后HSI软硬件接口规范就可以定义了——这是硬件团队和软件团队“分头干活”的分界线。TSR编写与分配中常见的“坑”坑1TSR写得像FSR❌ “系统应能检测前方障碍物” → 这是FSR不是TSR✅ “雷达应在50ms内通过CAN-FD发送目标距离数据精度±2m” → 这才是TSRFSR是“要什么”TSR是“怎么做”。坑2TSR没有关联安全机制❌ 只写了“用77GHz雷达”没写“雷达坏了怎么办”✅ 写了“用77GHz雷达” “上电自检” “通信超时监控” “数据合理性检查”每个TSR都应该配套安全机制。坑3分配时忘了考虑ASIL兼容性❌ 把ASIL-D和QM的需求分给同一个MCU但没做隔离✅ 要么用两个独立的MCU要么通过MPU/Hypervisor做分区隔离坑4没有建立可追溯性❌ TSR和FSR之间没有关联审核员问“这个TSR从哪来的”答不上来✅ 建立SG → FSR → TSR → 测试用例的完整追溯链