深入 FSoE 设备架构：三核冗余如何实现 SIL3 安全等级

在上一篇文章中我们看到，FSoE 通过 CRC 校验、序列号、看门狗和地址校验等机制，可以在不可靠的通信链路上可靠地检测出各类数据传输错误。但这些机制有一个共同的前提：发送端和接收端的设备自身必须是可靠的。如果一个安全 CPU 自身发生了故障——比如寄存器翻转导致 CRC 计算逻辑出错——那么无论通信链路多么可靠，安全功能都会失效。

这就是 IEC 61508 功能安全标准对硬件架构提出额外要求的原因。对于 SIL3 等级，标准要求设备的硬件故障裕度（Hardware Fault Tolerance, HFT）不低于 1。通俗地说：任何一个硬件单点故障都不能导致安全功能丧失。这意味着安全相关的处理单元必须具备冗余设计。

IEC 61508 对 SIL3 等级有两个关键约束。一是每小时危险失效概率（PFH）必须低于 10⁻⁷；二是硬件故障裕度 HFT ≥ 1。这两个指标共同决定了设备的硬件架构方案。

HFT ≥ 1 的含义非常直接：系统中任何一个随机硬件故障（如 CPU 寄存器损坏、内存位翻转、时钟漂移等）发生时，设备必须仍然能够执行安全功能，或至少能够检测到故障并将系统带入安全状态。单纯依靠软件自检无法满足这一要求——因为如果 CPU 本身已经损坏，运行在它之上的自检程序同样可能失效。

因此，几乎所有达到 SIL3 等级的 FSoE 设备都采用多 CPU 架构。ETG.5101 FSoE 实现指南明确指出：处理 FSoE 协议通常需要冗余的微控制器架构，每个微控制器独立计算 FSoE 协议，结果进行交叉校验。

一个典型的达到 SIL3 等级的 FSoE 设备采用三 CPU 架构，如下图所示：

这个架构可以清晰地分为两个层次：通信层和安全层。

通信层由单个通信 CPU 承担，负责 EtherCAT 数据链路层协议处理。它通过标准 EtherCAT 从站控制器（ESC）与 EtherCAT 网络交互，接收和发送 EtherCAT 数据帧。当通信 CPU 从 EtherCAT 帧中提取到 FSoE 安全 PDU 后，将它同时转发给两个安全 CPU。

安全层由两个完全冗余的安全 CPU（Safety CPU 1 和 Safety CPU 2）组成。两个安全 CPU 接收到相同的 FSoE 数据后，各自独立完成全套 FSoE 协议处理——包括 CRC 校验、序列号验证、地址匹配检查、看门狗管理以及安全应用逻辑的运算。处理完毕后，两个 CPU 交换并比较各自的输出结果。只有当结果一致时，安全输出才被激活；任何不一致都意味着至少有一个 CPU 发生了故障，系统立即进入 Fail-Safe 状态。

通信 CPU 的职责集中在标准 EtherCAT 通信层面：管理 ESC 寄存器与中断、处理 EtherCAT 状态机（Init → Pre-Op → Safe-Op → Op）、解析 EtherCAT 数据报并从中提取 FSoE PDU、以及处理非安全相关的协议（如 CoE、EoE、FoE 等）。通信 CPU 不参与任何安全逻辑运算——它看 FSoE PDU 只是"一段需要转发的数据"，对其内容不做任何安全相关的判断。

这种职责分离是黑色通道原理在设备架构层面的直接体现：通信 CPU 属于"黑色通道"的一部分，其可靠性不影响安全完整性。即使通信 CPU 发生故障，两个安全 CPU 上的看门狗会因为收不到新的安全报文而超时，各自独立地将系统带入安全状态。

两个安全 CPU 承担全部的安全相关任务。它们各自独立运行 FSoE 协议栈和安全应用逻辑，从输入数据的校验到输出指令的生成，两路完全并行。两者之间唯一的交互是在每个 FSoE 周期结束时进行结果交叉校验。这种架构本质上是一种 1oo2（one-out-of-two，二选一）冗余方案：只要两个 CPU 中有一个能正确检测到故障，系统就能进入安全状态。

双安全 CPU 的冗余工作方式是整个架构的核心。两个 CPU 在每个 FSoE 周期中的工作流程完全一致：

第一步：各自从通信 CPU 接收相同的 FSoE PDU 数据。第二步：独立进行 CRC 校验，验证数据完整性。第三步：独立检查序列号连续性，判断是否发生丢包或重复。第四步：独立验证 FSoE 地址是否匹配。第五步：独立重置各自的看门狗定时器。第六步：独立执行安全应用逻辑，计算安全输出值。第七步：交换计算结果并进行比对。

第七步的交叉校验是保障安全完整性的最后一道关。如果两个 CPU 的计算结果一致，安全输出被允许驱动执行器。如果结果不一致——无论是因为哪个 CPU 的哪个部件发生了故障——系统都认定存在危险失效可能，立即切断安全输出并进入 Fail-Safe 状态。

在实际工程实现中，两个安全 CPU 可以采用同构或异构两种方案。同构方案使用相同型号的 CPU 运行相同的代码，实现简单、维护方便，但对系统性故障（如编译器 bug、设计缺陷）缺乏防御能力。异构方案使用不同型号的 CPU 甚至不同的编译器，由不同的团队编写功能相同但实现方式不同的代码——这种"多样性设计"可以同时应对随机硬件故障和系统性故障，是更高安全等级产品的常见选择。

细心的读者可能会问：既然 SIL3 要求冗余，为什么通信 CPU 只需要一个？

这正是黑色通道原理的精妙之处。ETG.5101 明确说明：通信接口（包括控制器、ASIC、链路、耦合器等）可以保持单通道，因为它们不属于安全相关部分。FSoE 协议本身是端到端的——安全数据的完整性保护在发送端的安全层完成，校验在接收端的安全层完成。中间的通信通道无论经过多少节点、使用什么介质，都被视为不可信的黑箱。

在设备架构层面，这意味着：即使通信 CPU 完全失效（例如停止转发 FSoE 数据），接收端的安全 CPU 会因为看门狗超时而检测到通信中断，并自主进入安全状态。通信 CPU 的故障不会导致安全数据被错误地当作有效数据处理——安全 CPU 上的 CRC 校验和序列号检查可以拦截任何异常。

这种设计大幅降低了硬件成本和认证复杂度。设备制造商可以使用标准的、未经安全认证的 ESC 芯片和通信处理器，而只需将安全认证的精力集中在两个安全 CPU 上。

FSoE 设备的三 CPU 架构是功能安全工程中"纵深防御"思想的又一个经典案例。它通过在安全层实施 1oo2 冗余设计来满足 SIL3 的硬件故障裕度要求，同时借助黑色通道原理使通信层可以保持简洁的单通道设计。三个 CPU 各司其职——通信 CPU 管转发，两个安全 CPU 管校验和逻辑——任何单一 CPU 的故障都不会导致安全功能丧失。

这种架构设计不仅是 FSoE 设备的典型方案，也是功能安全领域的一种通用实践：安全相关的复杂计算交给冗余的安全处理器，非安全的通信任务交给标准硬件，两者之间用可靠而简洁的接口连接。

在本系列的下一篇文章中，我们将深入拆解 FSoE 安全 PDU 的完整结构，看看 CRC、序列号、地址等安全措施如何被精确编码在几十个字节的报文之中。

参考：ETG.5100 Safety over EtherCAT Specification V1.2.0 / ETG.5101 FSoE Implementation Guide V1.3.0 / IEC 61508 / FSoE 协议基础介绍 V1.0