在第二篇文章中我们提到，FSoE 通过四道防线——CRC 校验、序列号、看门狗和地址校验——来抵御通信链路中的八种错误。在第三篇文章中我们看到，这些防线在设备端由两个冗余的安全 CPU 独立计算和交叉校验。但有一个问题始终悬而未决：这些安全机制具体是怎么"装进"报文里的？

答案就在 FSoE 安全 PDU 的帧格式设计中。每个 FSoE 报文最短仅 6 个字节，却承载了命令、安全数据、CRC 校验值和连接标识四类信息。这 6 个字节的结构设计，是 FSoE 能达到 SIL3 安全等级的微观基础。

FSoE 安全 PDU 并不独立传输，而是作为普通过程数据嵌入在 EtherCAT 数据报（Datagram）的 PDO 区域中。下图清晰地展示了这一层次关系：

           

EtherCAT 主站在每个通信周期中读取 FSoE Master 从站发出的安全 PDU，原封不动地转发给 FSoE Slave 从站，反之亦然。中间的 EtherCAT 主站和其他网络节点只看到"一段 PDO 数据"，完全不知道其中包含了安全信息。任何新 PDU 的判断标准也非常简洁：只要 PDU 中至少有一个比特发生了变化，即被视为一帧新数据。

FSoE 安全 PDU 的长度是可变的。安全数据量最小为 1 个字节，最大受限于 EtherCAT PDO 长度以及设备的内存和算力。安全数据必须为偶数个字节（1 字节是唯一例外，其后紧跟的 CRC 实际保护的是单字节数据加上一个虚拟的零字节）。

PDU 的通用结构如下：

核心设计原则是：每 2 个字节的安全数据后面紧跟一个 2 字节的 CRC 校验值。所有安全数据之后，以 2 字节的 Connection ID 收尾。

PDU 的第 0 字节是 Command 字段，它决定了这个 PDU 在 FSoE 通信状态机中的角色。ETG.5100 定义了六种命令：

同一个 Command 值在 Master PDU 和 Slave PDU 中含义相同，但携带的具体数据不同。Command 不仅是数据类型的标识符，它更是 FSoE 状态机运转的核心驱动——接收方根据收到的 Command 来判断当前所处的通信阶段，并决定下一步的行为。

SafeData 是 PDU 中长度占比最大的部分，用来承载安全应用数据。在正常数据交换（Data 状态）下，它传输的是安全过程数据——例如急停按钮的状态、安全门的开闭信号、STO 指令等。在连接建立阶段（Parameter 状态），它传输的是通信参数和与应用相关的安全配置参数。

安全数据的最小长度为 1 字节，对应 PDU 总长 6 字节的最短帧：

           

安全数据的长度在 FSoE Slave 的设备描述文件中指定，输入方向和输出方向的长度可以不同。在 Parameter 状态下，如果参数数据超出 PDU 的安全数据容量，参数会被分段传输——CRC 继承机制保证了分段传输的一致性。

如果说 Command 决定了 PDU 的"身份"，SafeData 承载了"货物"，那么 CRC 就是 PDU 的"封印"。FSoE 的 CRC 设计远不止简单的校验和计算，它包含了多层精巧的机制。

生成多项式：FSoE 使用 16 位 CRC，生成多项式为 0x139B7。该多项式经过数学证明，在 16 位安全数据长度和 10?2 比特误码率的假设条件下，残余错误概率不超过 10??/h，满足 SIL3 要求。

CRC_0 的计算：CRC_0 不仅包含了 PDU 自身的 Command 和 SafeData，还将三个关键的外部信息纳入计算——上一个接收到的 PDU 的 CRC_0、Connection ID、以及一个虚拟的序列号（Sequence Number）。此外还额外追加了三个零字节，以确保安全 CRC 多项式与底层标准 CRC 多项式之间的独立性。

           

CRC 继承：上一个接收到的 PDU 的 CRC_0 被纳入当前 PDU 的 CRC 计算——这意味着整个通信序列形成了一条密码学意义上的"链"。如果攻击者或网络故障试图插入一个伪造的 PDU，由于不知道前一个正确的 CRC_0 值，插入的 PDU 将无法通过校验。这种设计同时防止了插入错误和伪装错误。

虚拟序列号：FSoE Master 和 Slave 各自维护一个 16 位的虚拟序列号（1-65535），每个 FSoE 周期递增。序列号被纳入 CRC_0 的计算但不直接出现在 PDU 中——因此称为"虚拟"。即使安全数据连续多个周期完全相同，由于序列号在变化，CRC_0 也会不同，从而保证了每个 PDU 的物理层唯一性。如果 CRC_0 碰巧与上一周期相同，序列号会自动递增直到 CRC_0 发生变化为止。

CRC 索引：当安全数据超过 2 字节时，PDU 中会有多个 CRC（CRC_0、CRC_1...）。为了防止 PDU 内部的数据块被交换位置（例如区块 A 和区块 B 互换），每个 CRC_i 的计算都会额外纳入索引 i。这样即使两块数据完全相同，交换后也会因为索引不同而无法通过校验。

PDU 的最后两个字节是 Connection ID。这个 16 位的标识符在 Connection 状态下由 FSoE Master 下发给 Slave，在整个网络中唯一。它由安全配置工具生成，在 Connection 状态之前使用 0 填充。接收方验证 PDU 中的 ConnID 是否与自身匹配——寻址错误和伪装错误在此处被拦截。

在 FSoE 状态机的不同阶段，PDU 的形态也有所不同：

• Reset 状态：最短的 PDU，仅包含 Command（0x2A）和最少的必要字段。CRC 和 ConnID 均为 0。
• Session 状态：Master 和 Slave 各自生成随机的 16 位 Session ID 并通过 PDU 交换。Session ID 确保每次上电后的通信序列都是唯一的。
• Connection 状态：Master 将 Connection ID 写入 PDU 下发给 Slave。此后所有 PDU 中的 ConnID 字段将始终携带该值。
• Parameter 状态：PDU 中的 SafeData 承载通信参数和与应用相关的安全参数。参数可能跨多个周期分段传输。
• Data 状态：进入正常安全数据交换。PDU 中的 SafeData 承载实际的安全过程数据。这是 FSoE 运行时间最长的状态。

回顾第二篇文章中的四道防线，每一道都在 PDU 中找到了精确的编码位置：

CRC 校验通过 2 字节的 CRC_0（及后续 CRC_i）直接嵌入 PDU，利用多项式 0x139B7 和 CRC 继承机制抵御数据损坏、插入和伪装。序列号作为虚拟字段纳入 CRC 计算，在不占用 PDU 字节的前提下实现了防重复、防乱序和防丢失。FSoE 地址虽不出现在 PDU 中（地址校验在通信建立阶段完成），但其正确性是 PDU 被接受的隐含前提。看门狗则在 PDU 之外、以时间为维度，确保通信的及时性。

六个字节的最短帧承载了这全部的安全逻辑。正是在这个微观层面，FSoE 完成了从"传输数据"到"安全传输数据"的质变。

对于设备制造商而言，从零开始实现 FSoE 协议栈是一项耗时且高风险的工程——不仅需要深入理解 ETG.5100 规范的每一个细节，还必须通过 TUV 等公告机构的功能安全认证。HMS Industrial Networks 提供的 FSoE 协议栈为这一难题提供了成熟的解决方案，其核心优势包括：

可移植性（Portability）：硬件无关的独立代码，支持在有操作系统或无操作系统的环境中运行，编译器无关、应用无关的纯 C 代码实现，可轻松移植到不同硬件平台。

可扩展性（Scalability）：通过编译器开关实现功能配置，优化资源占用，支持可选功能模块的按需启用，满足从简单安全 I/O 模块到复杂安全控制器等不同产品的需求。

主从一体化（Master and Slave from one source code basis）：同一代码库同时支持 FSoE Master 和 FSoE Slave 两种角色，降低学习和维护成本。

可预认证（Pre-Certifiable）：协议栈符合 IEC 61508 SIL3 等级要求，基于经过认证的功能安全软件开发流程，提供集成规则和测试套件以简化重新认证过程。移植到新硬件平台时无需修改核心安全代码，大幅缩短产品的认证周期。

从理解 PDU 帧格式到获得 SIL3 认证，中间隔着大量的工程实现和验证工作。选择成熟的商业协议栈，能让研发团队将精力集中在产品的差异化价值上，而不是重复解决已经被人踩过的坑。

参考：ETG.5100 Safety over EtherCAT Specification V1.2.0 / IEC 61784-3 / FSoE 协议基础介绍 V1.0