功能安全要求（FSR）与技术安全要求（TSR）的区别

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

功能安全要求 (FSR) 源自项目定义、HARA 和安全目标，并可追溯至安全目标。每个安全目标应至少有一个与之关联的 FSR。

技术安全要求 (TSR) 主要源自 FSR。每个 FSR 应至少有一个与之关联的 TSR。

下图提供了从 ISO26262 第 3 部分 - 项目定义到第 5 部分硬件安全要求 (HSR) 和第 6 部分软件安全要求的要求/活动流程的层次视图。

该表给出了 FSR 和 TSR 之间的高级差异。

让我们以巡航控制功能为例，以更好地理解 FSR 和 TSR 之间的界限。在下图中，巡航控制功能表示为一个项目，并具有多个相互交互的模块，例如巡航控制模块、用户交互、制动模块和发动机模块。项目定义讨论了车辆级别功能的行为期望。当我们定义 FSR 时，必须将整个项目定义的范围视为边界。这在图中以绿色虚线突出显示。每个 FSR 都应在车辆级别指定要求，并应分配给实现它的模块。

TSR 指定系统级的要求。因此，TSR 的边界位于模块或系统级。这在图中以橙色虚线突出显示。

指定功能行为而不涉及“如何”实现功能的需求是与实现无关的需求。指定“如何”实现功能的需求是与实现相关的需求。

让我们回到我们的巡航控制示例，更好地理解这方面的需求。

这些是安全实现安全目标所需的预期功能要求。

应使用以下 FSR 格式来定义故障监控要求。

FSR 1：“ECU 应能够在 YYYY 时间范围内检测到 XXXX 故障”

FSR 2：“确认故障后，ECU 应在 ZZZZ 时间范围内转换到安全状态（项目级安全状态）” 

这里的“XXXX”表示影响车辆级功能的任何故障（例如数据或通信故障）。YYYY 是故障检测时间，ZZZZ 是故障反应时间。YYYY + ZZZZ 应小于 FTTI（容错时间间隔）。

FSR 必须指定通用要求以避免或检测和缓解故障，而不是直接指定解决方案。例如，

• 如果检测到故障，巡航控制模块应向用户发出指示

• 巡航控制应采取措施在 YYYY 时间范围内检测内部故障（而不是提供电源监控、外部看门狗等解决方案）

我们将“巡航控制模块在检测到故障时应向用户指示”作为 FSR，并为其推导出 TSR 框架。

• TSR 要求应指定准确的 CAN 接口细节

• TSR 要求应指定启用/禁用该功能的确切标准

• TSR 要求应指定监控数据的正确性和活跃性

• TSR 要求应指定系统级操作模式（例如，操作模式应基于点火状态）

• TSR 要求应指定硬件相关输入的去抖动时间

TSR 应指定系统级可用的故障监控方面的解决方案。例如，

• 巡航控制应实施安全机制，以检测保存巡航控制数据的 RAM 中的故障

• 巡航控制应实施安全机制来检测巡航控制算法的时序和执行故障

例如，如果内存保护单元被视为系统级概念的一部分，则 TSR 应指定相同的内容。否则，TSR 应允许自由决定软件设计级别的解决方案。

通过本文的讨论和实例分析，我们详细阐明了功能安全要求（FSR）和技术安全要求（TSR）之间的区别及其各自的细节要求。理解FSR和TSR的边界和差异对于安全工程师在实施和设计安全系统时至关重要。FSR侧重于项目定义和车辆级功能的要求，而TSR则聚焦于系统级的实现细节。希望通过本文的讲解，能够帮助安全工程师更清晰地把握FSR和TSR的定义和应用，从而在实际工作中更加高效准确地制定和实施安全策略。