如何组织功能、系统和子系统层面的安全分析

尽管 ISO26262 通过定义 FSC 和 TSC 明确地将功能与系统分开，但日常实践往往告诉我们一个不同的故事。功能和系统规范的一致策略很少见，尽管两者都对安全分析的结构有重大影响，从而对分析结果的质量以及最终对系统的安全性有重大影响。但严格将功能与系统规范分开真的有意义吗？如果我们不这样做，风险是什么？如果我们这样做，优势又是什么？让我们先对功能和系统的含义进行简短的思考。

系统将输入信号转换为输出信号，因为其他系统需要输出信号。转换的规范称为系统的功能，而系统是实现功能的实体，即创建其他系统所需的信号。因此，系统之间的接口是功能规范的一部分。系统规范包含所有系统内部细节，解释如何实现功能。换句话说：功能规范描述要做什么，系统规范描述如何提供什么。

然而，系统间接口的规范在功能规范和系统规范之间可能有所不同。通常，当信号仅通过逻辑状态来描述时，功能级别不需要接口实现的技术细节。

示例：雨刮器电机可以处于以下状态之一（关于旋转）：OFF、SLOW、FAST 和 ERROR。电机由两个信号控制，一个用于激活慢速旋转，另一个用于激活快速旋转。因此，接口规范可以包含两个信号，如 WM_SLOW 和 WM_FAST，它们都具有三种潜在状态 OFF、ON 和 ERROR。这是 ECU 电机接口的完整且正确的规范。

对于模拟信号，这变得更加困难，有时甚至根本不可能。对于通信总线，必须考虑到信号必须与协议区分开来，协议的属性可以被视为单独的信号或资源。但只要可能，强烈建议指定一个接口，而不提供任何实现的技术细节。

为什么这与安全分析相关？

系统由系统元素组成。系统实现一项功能（或多项功能）。系统所有者负责正确实现所需功能，并定义系统架构，即系统元素和内部接口。在功能层面，系统所有者将定义和指定系统元素的功能，特别是系统元素的接口作为功能规范的一部分。在为系统元素指定任何技术细节之前，可以执行功能层面的安全分析。将识别系统元素的功能故障；将通过归纳法（例如 FMEA）评估影响。然后，将根据系统的安全相关功能故障分析系统架构。几十年来建立的一种广泛使用的方法是故障树分析（定性）。首先，任何功能故障都是由系统元素的输出信号故障引起的。与系统级分析类似，将开发系统元素功能故障的完整列表。然后，将通过演绎法（例如 FTA）分析感兴趣的系统功能故障，以找到系统内部的所有根本原因。换句话说：系统功能故障将与系统元素的相关功能故障相关联。定性故障树将表示所有系统功能故障的根本原因，这些故障树沿着内部信号路径，结构良好，与系统架构完美匹配。最后但并非最不重要的是，所有不是系统功能故障根本原因的系统元素功能故障都可以通过归纳法进行分析，以进一步了解系统对内部功能故障的反应。归纳法和演绎法提供了一套互补的工具，可以对功能故障的架构进行完整的分析。

到目前为止描述的分析完全独立于系统设计的技术细节，从而为所有后续安全分析活动提供了基本结构。功能故障被分配给每个相关系统元素，只要接口规范不变，就可以独立于任何其他系统元素的安全分析进行分析。即使没有详细定义，也可以启动安全措施的设计。

结论：系统所有者可以执行功能级故障树分析。故障树分析的范围是系统的安全相关功能故障。故障树分析的目标是找到可能导致系统功能故障的所有系统元素功能故障。所有系统元素都被视为黑匣子，实现系统所有者定义的功能。故障树独立于系统架构和设计，因此只要系统元素的功能和接口规范（在功能级别）不变，就可以重复使用。

一旦完成功能级安全分析，系统元素的所有者就可以启动系统安全分析，其范围是分配给系统元素的安全相关功能故障集。这里的“功能”=系统元素实现的功能。程序相同也就不足为奇了：

识别所有输出信号故障模式。

将输出信号故障模式（或组合）与系统元件的功能故障联系起来。

将所有其他输出信号故障模式报告给系统所有者，然后系统所有者将在功能或系统级别（归纳性）对其进行分析。

沿信号路径通过系统元件架构向后分析输出信号故障模式（演绎法）。

指定与系统元素内部故障相关的安全要求。

指定系统元素输入信号的安全要求并报告给系统所有者。

只要通过架构框图指定下一个细节级别，就可以重复此策略。最终，分析将达到组件级别（硬件或软件）。但是，在组件级别应用什么方法又是另一回事。

图 1 显示了一些泳道，对上述过程进行了高层次描述。从一个架构级别到下一个架构级别的递归结构很容易识别。从系统级别的功能故障分析开始，在系统级别架构上细化结果，在子系统级别上细化每个系统元素等。

图 1：多个架构层面的安全分析的高级描述。

作为功能级 FTA 的结果，将为系统元素分配基本事件（见图 2）。对于每个系统元素，将分析所有输出信号故障模式 (OSF) 对系统级的影响（“FMEA（OSF）”）。将在功能级分析新识别的 OSF 以闭合回路。将沿着信号路径进一步分析安全相关的 OSF，从而得到子系统级的 OSF（“FTA（安全相关 OSF）”）。

图 2：功能级 FTA 的基本事件将用于初始化系统 FMEA。将分析新发现的系统故障对功能级的影响。

系统级 FTA 的基本事件将用于初始化子系统级安全分析（图 3）。适用相同的程序。首先，将对分配了系统级 FTA 基本事件的子系统元素的所有 OSF 进行分析（“FMEA（OSF）”）。将在系统级分析新识别的 OSF。将在子系统架构级沿信号路径分析与安全相关的 OSF。此程序将应用于所有架构级别。

图 3：系统级 FTA 的基本事件将用于初始化下一级别的 FMEA。将分析新识别的 OSF 对上级的影响。

在一个层次上对 OSF 的评估可能会导致必须在下一个更高层次上进行分析的影响（见图 4）。这就是演绎方法深入研究架构设计细节的方式，而归纳方法则再次将循环闭合到更高层次（直至系统的功能层）。

图 4：对新发现的 OSF 的归纳分析可以跨越多个架构层面。

摘要：在系统架构或设计细节可用之前，明确区分功能和系统级别的安全分析可以支持安全概念的早期开发。结构良好的分析流程不仅可以明确界定责任，还可以确保安全分析活动在受影响方之间更好地协调，从而显著提高安全分析计划和安全分析结果的质量。