这是 "深入 FSoE" 系列文章的第六篇。前面五篇文章我们分别讨论了 FSoE 的基本架构与黑色通道原理、八种通信错误与四道安全防线、设备端的多 CPU 冗余架构、安全 PDU 的帧格式设计，以及通信状态机的五步握手过程。今天我们把镜头拉远，聚焦一个看似简单但包含大量细节的过程——一个 FSoE 通讯周期到底发生了什么。
在前面的文章中，"FSoE 通讯周期"这个词反复出现，但我们一直没有把它拆开来看。ETG.5100 规范对它的定义只有一句话：**"一个 FSoE 通讯周期包含一个 Safety Master PDU 和对应的 Safety Slave PDU 的交换"**。短短一句话背后，是四个 EtherCAT 周期的精密协作和无数次 CRC 校验、序列号对比、看门狗重置。
FSoE 主站和从站之间的通讯采用 Ping-Pong 模式——Master 发一帧、Slave 回一帧、往复循环。但因为 FSoE Master 和 FSoE Slave 都是 EtherCAT 从站，两者之间的报文并不能直接互通，必须由 EtherCAT 主站进行中转。这个中转过程将一个 FSoE 通讯周期拆解为四个步骤，每一步对应至少一个 EtherCAT 周期。
图1 FSoE Ping-Pong 数据流
▲ FSoE Ping-Pong 通讯模式。FSoE Master 和 FSoE Slave 之间的安全数据交换必须经过 EtherCAT 主站中转，四个步骤分别对应 M TPDO、S RPDO、S TPDO、M RPDO 四次报文传输。
下面我们逐帧拆解这四个步骤中，每个设备在做什么、数据经过了哪些安全校验。
FSoE Master 在每个通讯周期的起点，准备并发送一个 Safety Master PDU。这个 PDU 中包含了本周期需要下发给 Slave 的 SafeOutputs（安全输出数据），以及 Command 字节、CRC_0 校验值、Connection ID 等安全字段。
Master 在构造 PDU 时完成了以下关键动作：虚拟序列号（Master Sequence Number）自增 1，上一周期 Slave 回应的 CRC_0 被纳入本轮 CRC 计算（CRC 继承链），SafeOutputs 从安全应用层读取并填充到 PDU 的 SafeData 区域。PDU 构造完成后，Master 启动 FSoE 看门狗定时器——从这一刻开始计时，如果在规定时间内收不到 Slave 的有效响应，看门狗将超时并触发进入 Reset 状态。
EtherCAT 主站在本周期内读取 FSoE Master 的 TPDO（Transmit Process Data Object），从 PDO 映射区中取出 Safety Master PDU。对于 EtherCAT 主站而言，这段数据只是普通过程数据——这正是黑色通道原理在通讯周期层面的直接体现：EtherCAT 主站不解析也不理解 PDU 内部的安全字段。
EtherCAT 主站将第一步读到的 Safety Master PDU 原封不动地写入 FSoE Slave 的 RPDO（Receive Process Data Object）。FSoE Slave 在接收到这帧数据后，立即启动一套严密的安全校验流程。
校验的第一步是 Connection ID 匹配——Slave 读取 PDU 末尾的 ConnID 字段，与自身在 Connection 状态下从 Master 接收到的 ConnID 进行比对。如果 ConnID 不匹配，Slave 直接丢弃该帧并报告寻址错误。
通过 ConnID 校验后，Slave 进入 CRC_0 验证。Slave 使用自身维护的虚拟序列号预期值（Slave Sequence Number）、上一周期收到的 CRC_0、ConnID 和 Command 字节，对接收到的 SafeData 重新计算 CRC_0。计算结果与 PDU 中的 CRC_0 字段比对——如果一致，说明数据完整无误、序列号正确且没有被插入或伪装。如果 CRC 不匹配，Slave 立即进入 Reset 状态并报告 INVALID_CRC 错误。
CRC 校验通过后，Slave 将 SafeOutputs 提取出来传递给安全应用层执行实际的安全动作（例如断开 STO 信号、闭合安全继电器等），同时读取本地的 SafeInputs（安全输入数据，例如急停按钮状态、安全门位置等），准备构造 Safety Slave PDU。
FSoE Slave 在完成 SafeOutputs 的处理和 SafeInputs 的采集后，构造 Safety Slave PDU 作为对 Master 的响应。
Slave 在构造 PDU 时执行与 Master 对称的操作：虚拟序列号（Slave Sequence Number）自增 1，第二步中收到的 Safety Master PDU 的 CRC_0 被纳入本轮 CRC 计算（延续 CRC 继承链），SafeInputs 填充到 PDU 的 SafeData 区域，Command 字节和 ConnID 也一并写入。Slave 同样启动自己的看门狗定时器——从发送响应帧开始计时，如果在规定时间内收不到 Master 的下一帧有效数据，Slave 将独立进入安全状态。
EtherCAT 主站在本周期内读取 FSoE Slave 的 TPDO，取出 Safety Slave PDU。对于 EtherCAT 主站而言，这同样只是一段普通过程数据。
EtherCAT 主站将第三步读到的 Safety Slave PDU 写入 FSoE Master 的 RPDO。FSoE Master 在接收到这帧数据后，执行与 Slave 在第二步中完全对称的校验流程。
Master 首先校验 ConnID——确认这帧 Slave 响应确实来自正确的连接。然后进行 CRC_0 验证——由于第二步中 Slave 的 CRC_0 已将 Master 上一帧的 CRC_0 纳入计算，而 Master 自己保留了该值，因此 Master 可以独立验证 Slave 响应的 CRC_0 是否正确。如果 CRC 校验通过，Master 确认 SafeInputs 有效、Slave 通信正常，一个完整的 FSoE 通讯周期就此完成。
如果 CRC 校验失败，Master 同样进入 Reset 状态，双方重新开始状态机握手——与第五篇文章中描述的五步握手过程完全一致。
从上面的四步分析中可以清晰看出：一个 FSoE 通讯周期至少需要 4 个 EtherCAT 周期才能完成。这是因为每一步都需要 EtherCAT 主站完成一次完整的 TPDO 读取或 RPDO 写入操作，而 EtherCAT 的一个周期中，主站对每个从站只能进行一次读或一次写。
在实际系统中，FSoE Cycle 可能大于 4 个 EtherCAT Cycle。原因包括：EtherCAT 主站的 PDO 映射策略（某些主站可能将不同从站的 TPDO 和 RPDO 分配到不同的 EtherCAT 周期中）、从站之间的物理距离导致的传输延迟、以及多个 FSoE Connection 共享同一个 EtherCAT 网络时的带宽竞争。但这不影响安全性的保证——看门狗时间由用户在配置工具中根据实际系统延迟合理设定，只要实际周期不超过看门狗时间，安全通信就不会中断。
将四步串联起来看，一个完整 FSoE 通讯周期中的时间线如下：
FSoE Master 的安全应用层产出 SafeOutputs → Master 协议栈构造 Safety Master PDU → EtherCAT 主站读取 M TPDO（第一步） → EtherCAT 主站写入 S RPDO（第二步） → FSoE Slave 协议栈校验 PDU、提取 SafeOutputs → Slave 安全应用层执行动作、采集 SafeInputs → Slave 协议栈构造 Safety Slave PDU → EtherCAT 主站读取 S TPDO（第三步） → EtherCAT 主站写入 M RPDO（第四步） → FSoE Master 协议栈校验 PDU、提取 SafeInputs → Master 安全应用层消费 SafeInputs。
这条时间线中的每一个环节都有对应的错误检测机制。如果任何一步的 CRC 校验失败、看门狗超时、或 ConnID 不匹配，整个周期立即中止，双方进入 Reset 状态，开始新一轮状态机握手。
看门狗定时器是 FSoE 通讯周期最重要的安全边界。ETG.5100 规定看门狗时间可在 1-65535 ms 范围内配置，具体值由安全工程师根据系统的实际延迟（EtherCAT 周期时间、从站数量、安全数据长度等）计算得出。
值得强调的是，看门狗并非只检测通信链路完全中断的情况。在 Data 状态下，只有接收到有效的 ProcessData 或 FailSafeData 帧才会重置看门狗——无效帧（CRC 错误、ConnID 不匹配）不会重置定时器。这意味着即使物理链路没有断开，持续收到损坏的报文同样会导致看门狗超时、触发进入安全状态。
FSoE Master 和 FSoE Slave 各自维护独立的看门狗定时器，且彼此不依赖对方的看门狗状态。Slave 的看门狗超时后，Slave 自主进入 Reset 状态并停止所有安全输出，不等待 Master 的任何指令——这是黑色通道原理在时序层面的核心体现。
一个 FSoE 通讯周期看似只是在两个设备之间传递几个字节的安全数据，但实际上包含了四次 EtherCAT 报文交换、两次 CRC 校验（Master 和 Slave 各一次）、两次序列号递增、两次看门狗重置。每一个步骤中，数据都在经历严格的完整性验证，任何一处异常都会触发立即进入安全状态。
将本篇与前面五篇文章串联起来，FSoE 通讯的完整图景已经清晰：黑色通道提供了"底层不可信"的前提（第一篇），四道防线在逻辑上构建了防御体系（第二篇），多 CPU 冗余在硬件上保证了计算的可靠性（第三篇），安全 PDU 在帧格式层面编码了所有的保护手段（第四篇），状态机将这些机制组织成了一套有纪律的运行规则（第五篇），而通讯周期则是这套规则在实际时间轴上的"演奏"——每一步都精确到位，每一个节拍都在校验。
在下一篇文章中，我们将介绍 FSoE 的安全反应时间模型，分析从安全事件发生（例如急停按钮按下）到执行器进入安全状态（例如电机停止）的完整时序链条，以及看门狗时间如何影响这一过程。
参考：ETG.5100 Safety over EtherCAT Specification V1.2.0 / ETG.5101 FSoE Implementation Guide V1.3.0 / IEC 61784-3 / FSoE 协议基础介绍 V1.0
