汽车功能安全系统阶段开发【技术安全需求TSR】4

1 技术安全需求（TSR）的定义

通过上文介绍，咱们了解了功能安全需求（FSR）和方案（FSC），但是FSR本质上属于功能层面的逻辑安全需求，属于“需要做什么”的层级，无法具体实施，所以需要将FSR进一步细化为技术层面的安全需求（TSR），即“怎么做”，为后续的软件和硬件的开发奠定技术需求基础。
TSR（Technical Safety Requirement） 是从功能安全需求（FSR）细化出的具体技术实施方案，用于指导系统/软硬件设计。它具备以下特性：

1. 可测试性：必须能被验证（e.g., 通过测试或审查）
2. 技术具体化：明确硬件/软件实现方式（e.g., 传感器类型、算法逻辑）
3. 覆盖完整性：需覆盖所有FSR要求和安全机制

示例：对于制动系统的FSR “在检测到刹车信号故障时，车辆应在X秒内降至安全速度”
对应的TSR：

• 硬件层：刹车控制器双核锁步运行，每10ms互检
• 软件层：实现信号校验算法（CRC32），错误率 - 执行层：备份液压回路激活时间≤50ms

2 安全机制（Safety Mechanism）的本质

安全机制是嵌入系统内部的防护层，核心目标是：
▶ 检测故障 → 控制风险 → 进入/维持安全状态
其本质可通过“三层防护逻辑”理解：

FTTI (Fault Tolerant Time Interval)*：系统容忍故障的最长时间

通过如下三方面来阐述安全机制的本质：
1. 安全机制属于更深层次的TSR
安全机制是为防止SG或FSR的违反，基于由FSR技术化的安全需求，提出的更深层次的事后补救技术安全措施，它包括:
由FSR技术化得到的TSR的安全机制，主要是防止系统性故障，或硬件单点故障潜伏提出的技术安全需求。
以及安全机制的安全机制。例如针某TSR提出了已经有了安全机制A，但由于该TSR的ASIL等级较高(C或D)，安全机制A本身也可能失效，此时如果原有功能正常，系统不会违反安全目标SG，但安全机制A的失效就会潜伏，变成双点故障，所以需要对安全机制A的功能安全进行监控，提出针对安全机制A的相应的技术安全需求，防止安全机制A的故障潜伏。
一般来讲，考虑到系统实现的成本和复杂度，安全机制不超过两层。根据ISO 26262，三点及以上故障就可以认为安全故障，否则就会出现无穷的安全机制嵌套。

2. 安全机制是实现相应ASIL等级的关键之一
除ISO 26262对不同开发过程的约束(包括方法，验证等)外，在系统，软件和硬件开发阶段，不同ASIL等级直接决定了应该采取哪些安全措施，以及安全措施的类型(或高级层度)。
越高的ASIL等级对应的安全措施，在数量和质量的要求越高。例如，对于ASILB的系统，可能具有单独时间Base的Watchdog可能就够了，但是对ASILD系统而言，可能需要上程序流逻辑监控才能满足。
当然不同的安全机制在实施难度和成本上都有所不同，这部分内容我会在后续的专题里一步步讲解。
3. 安全机制多和系统安全架构设计相关，一定程度上决定了系统安全架构
安全机制是保证系统功能安全的非常重要的技术手段，而这些技术手段，例如，硬件冗余，输入输出有效性检验，安全状态导入，或我们常见的控制器3层安全监控架构等等，这些都直接决定了我们系统的安全架构，会在架构设计中进行考虑，直接融入架构设计之中。这个也是为什么在功能安全在系统阶段开发过程中，花很大的篇幅来讲安全机制和架构设计的重要原因之一。

为了方便理解安全机制，我们一起来看个关于加速踏板开度采集的例子:

其中，左边属于由FSR技术化的安全需求，主要是明确加速踏板技术信息，包括采用什么样传感器，输出信号有哪些，类型，采样周期等。
在实际系统开发过程中，为实现相应的ASIL等级，控制系统一般进行分层设计，功能安全拥有独立的软件层和硬件层，开发过程相对独立，甚至独立的开发团队。
为实现后续安全监控，需要将安全相关的应用层功能在监控层进行多样化设计复现，所以这部分TSR和我们正常的系统应用层功能开发需求有点类似，但不是完全复制，而是多样化，差异化的设计实现，所以这些信息或者需求会和应用层功能实现存在一定关联。
右边是安全机制，是更深层次技术安全需求，这些都是保证系统功能安全的关键技术手段。

汽车行业典型安全机制：

3 从FSR到TSR的转化流程（ISO 26262 Part 4）

关键步骤解析：

1. 分解FSR目标 方法：安全分析（FTA、FMEA分析方法）

   • 输入：ASIL等级分配的FSR（e.g., ASIL D）
   • 输出：技术实现路径清单

     例：EPS（电动转向）的FSR “防止非预期转向” → 拆解为：扭矩传感器诊断+电机堵转检测+通信加密

2. 技术方案映射

   • 将架构组件与FSR关联，明确各模块的安全职责：

3. 生成TSR的关键属性

   属性	说明	示例值
   安全机制响应时间	从故障检测到响应的延迟	≤15ms (对应FTTI要求)
   诊断覆盖率(DC)	安全机制可检测的故障比例	≥99% (ASIL D)
   故障处理方式	复位/降级/关断等	关闭功率MOSFET并备份制动

4. 双向追溯性验证
   需建立矩阵确保：
   FSR → TSR → 测试用例 → 安全目标 的完整闭环

4 实战案例：电动汽车电池管理系统（BMS）

背景 ：
FSR: “防止电池过压导致热失控（ASIL C）”

转化过程： ：

1. 技术方案

   • 硬件TSR：电压采样电路精度±0.1%，采样频率≥100Hz
   • 软件TSR：过压诊断算法（窗口比较法），每周期执行
   • 安全机制：电压值三重冗余校验 + 继电器强制断开逻辑

2. 安全机制设计细节

5 总结要点

1. TSR是FSR的技术具现，需满足ASIL分解要求（ISO 26262-9）
2. 安全机制本质是故障控制闭环：检测→决策→执行
3. FSR→TSR成功关键：量化指标定义（DC/FTTI） + 架构合理性
4. 汽车行业最佳实践：在V模型右翼验证TSR实现（仿真→HIL测试→实车）

注：ISO 26262-4:2018 Clause 6.4.3 明确要求TSR需具备“可验证性”与“无歧义性”，避免使用“适当”“足够”等模糊表述。