這是 "深入 FSoE" 系列文章的第六篇。前面五篇文章我們分別討論了 FSoE 的基本架構與黑色通道原理、八種通信錯誤與四道安全防線、設備端的多 CPU 冗余架構、安全 PDU 的幀格式設計，以及通信狀態機的五步握手過程。今天我們把鏡頭拉遠，聚焦一個看似簡單但包含大量細節的過程——一個 FSoE 通訊周期到底發生了什么。

在前面的文章中，"FSoE 通訊周期"這個詞反復出現，但我們一直沒有把它拆開來看。ETG.5100 規范對它的定義只有一句話："一個 FSoE 通訊周期包含一個 Safety Master PDU 和對應的 Safety Slave PDU 的交換"。短短一句話背后，是四個 EtherCAT 周期的精密協作和無數次 CRC 校驗、序列號對比、看門狗重置。

FSoE 通訊周期的四步模型

FSoE 主站和從站之間的通訊采用 Ping-Pong 模式——Master 發一幀、Slave 回一幀、往復循環。但因為 FSoE Master 和 FSoE Slave 都是 EtherCAT 從站，兩者之間的報文并不能直接互通，必須由 EtherCAT 主站進行中轉。這個中轉過程將一個 FSoE 通訊周期拆解為四個步驟，每一步對應至少一個 EtherCAT 周期。

FSoE Ping-Pong 通訊模式。FSoE Master 和 FSoE Slave 之間的安全數據交換必須經過 EtherCAT 主站中轉，四個步驟分別對應 M TPDO、S RPDO、S TPDO、M RPDO 四次報文傳輸。

下面我們逐幀拆解這四個步驟中，每個設備在做什么、數據經過了哪些安全校驗。

第一步：M TPDO —— Master 發出安全報文

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 內部的安全字段。

第二步：S RPDO —— Slave 接收并校驗

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。

第三步：S TPDO —— Slave 響應安全報文

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 主站而言，這同樣只是一段普通過程數據。

第四步：M RPDO —— Master 接收并校驗

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 Cycle 與 EtherCAT Cycle 的數量關系

從上面的四步分析中可以清晰看出：一個 FSoE 通訊周期至少需要 4 個 EtherCAT 周期才能完成。這是因為每一步都需要 EtherCAT 主站完成一次完整的 TPDO 讀取或 RPDO 寫入操作，而 EtherCAT 的一個周期中，主站對每個從站只能進行一次讀或一次寫。

在實際系統中，FSoE Cycle 可能大于 4 個 EtherCAT Cycle。原因包括：EtherCAT 主站的 PDO 映射策略（某些主站可能將不同從站的 TPDO 和 RPDO 分配到不同的 EtherCAT 周期中）、從站之間的物理距離導致的傳輸延遲、以及多個 FSoE Connection 共享同一個 EtherCAT 網絡時的帶寬競爭。但這不影響安全性的保證——看門狗時間由用戶在配置工具中根據實際系統延遲合理設定，只要實際周期不超過看門狗時間，安全通信就不會中斷。

一個周期內的時間線：從 SafeOutput 到 SafeInput

將四步串聯起來看，一個完整 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