這是 "深入 FSoE" 系列文章的第五篇。在上一篇文章中，我們逐字節拆解了 FSoE 安全 PDU 的幀格式——Command、SafeData、CRC 和 ConnID 分別承載了什么安全機制。但這些字段如何協同工作、在什么時機被賦值？答案就藏在 FSoE 通信狀態機之中。本文將深入分析 FSoE 的五個通信狀態，逐一說明每個狀態中 Master 和 Slave 在做什么，以及為什么會這樣設計。

在工業通信協議中，狀態機承擔著"協調者"的角色——它規定了設備在什么條件下可以發送什么數據、如何響應不同類型的報文、以及異常情況下的行為準則。對于功能安全協議來說，狀態機的設計還多了一層額外的約束：在任何狀態下、面對任何異常，系統都必須能夠可靠地進入安全狀態。

FSoE 的通信狀態機由 ETG.5100 規范嚴格定義，無論 Master 還是 Slave，都必須實現完全相同的一組狀態和轉換規則。TUV 等公告機構在進行協議棧認證時，狀態機實現的正確性是重點審查內容之一——一個狀態轉換的邏輯漏洞可能導致安全功能在特定場景下失效。

五個狀態，一條目標

FSoE 定義了五個通信狀態：Reset、Session、Connection、Parameter 和 Data。這五個狀態構成了一條從"完全不可信"到"建立安全通信"的漸進式握手路徑。

▲ ETG.5100 Figure 8 – FSoE Slave 狀態機。五個狀態（Reset → Session → Connection → Parameter → Data）構成一條嚴格的漸進式握手路徑，Master 狀態機與之高度對稱。

前四個狀態中，安全輸出始終處于安全值（Fail-Safe Data = 0）。只有當狀態機成功推進到 Data 狀態后，安全輸出才被允許激活。這一設計保證了安全功能永遠不會在通信未建立的情況下被誤激活。

ETG.5100 規范不僅定義了每個狀態的含義，還以精確的狀態表（State Table）形式規定了每個狀態下的所有可能事件、轉換條件和相應的動作。下面我們逐一深入每個狀態。

Reset 狀態：一切從零開始

Reset 是上電后的初始狀態，也是任何通信錯誤發生后系統回歸的"安全原點"。

進入 Reset 狀態時，Master 和 Slave 執行完全相同的初始化動作：清零所有 CRC 歷史值（LastCrc = 0, OldMasterCrc = 0, OldSlaveCrc = 0）、重置序列號計數器（MasterSeqNo = 1, SlaveSeqNo = 1）、安全數據初始化為全零（Fail-Safe Data）、以及通信錯誤原因碼清零。看門狗定時器在此時啟動，確保整個初始化過程不會無限期卡住。

Master 在 Reset 狀態主動發送 Reset 命令幀，等待 Slave 的回應。規范對此有一個有趣的細節：如果 Master 收到的 Slave 回應中 Command 不是 Reset（意味著對方處于錯誤的狀態），Master 并不會立即報錯——它會再次發送 Reset 幀并重置內部變量，給對方一個"校正"的機會。只有當對方發送了合法的 Reset 響應后，Master 才會生成一個隨機的 Session ID 并主動發起向 Session 狀態的躍遷。

Slave 在 Reset 狀態下則處于被動等待模式。它監聽 Master 發來的命令，一旦收到合法的 Reset 幀，就回應 Reset 幀并準備好接收 Session 幀。如果 Slave 收到的不是 Reset 命令（例如收到了 Session 或 Data 命令——意味著 Master 認為連接已經建立），Slave 會回應 Reset 幀并報告"非預期命令"錯誤。

Reset 狀態下不存在 Connection ID（ConnID = 0），CRC 校驗使用簡化的計算方式，因為此時還沒有建立 CRC 繼承鏈。看門狗在 Reset 狀態下同樣有效——如果規定時間內收不到有效報文，Master 和 Slave 各自獨立超時，重新初始化并再次嘗試發起連接。

Session 狀態：用隨機數確保"這次通信是新的"

Session 狀態的核心目標是建立一次通信會話的唯一性標識——Session ID。

Master 在進入 Session 狀態之前，調用 CREATE_SESSION_ID() 生成一個隨機的 16 位 Session ID，然后通過 Session 命令幀發送給 Slave。Slave 收到后，并非簡單回傳——它同樣調用 CREATE_SESSION_ID() 獨立生成自己的隨機 Session ID，然后通過 Session 幀發回給 Master。這樣雙方各自貢獻了隨機性，兩個 Session ID 隨后都被納入 CRC 計算，確保了雙向的會話唯一性。

這個設計解決了一個微妙的安全問題：假設設備在運行中經歷了短暫的斷電（例如電源抖動），Master 和 Slave 的序列號恰好回到了相近的值。如果沒有 Session ID 的變化，重新上電后的通信可能與斷電前的通信在 CRC 層面"混淆"——上一次通信殘留在內存中的 CRC_0 值可能恰好匹配新通信的 CRC 值。Session ID 的重新隨機化徹底消除了這種跨上電周期的混淆可能。

Session 狀態下的數據交換采用分段傳輸。Session ID 是一個 16 位的值，占用 2 個字節，剛好對應一個最短安全數據長度。如果 Session ID 被完整接收且 CRC 校驗通過（BytesToBeSent = 0），Master 轉入 Connection 狀態。如果 CRC 校驗失敗，Master 會重試一次（SecondSessionFrameSent 標志），再次失敗則回到 Reset 狀態并報告 CRC 錯誤。

一個值得注意的細節：在 Session 狀態中，如果 Master 收到了 Connection、Parameter、ProcessData 或 FailSafeData 命令——即對方跳過了 Session 狀態——Master 會立即回到 Reset 并報告"非預期命令"錯誤。這種嚴格的狀態檢查確保通信握手不會被跳過或繞開。

Connection 狀態：綁定身份，建立歸屬

Connection 狀態完成兩項關鍵任務：下發 Connection ID 和 綁定 FSoE Slave Address。

ConnData 是一個由安全配置工具（Safety Configurator）預先配置的數據結構，包含 Connection ID 和 FSoE Slave Address 兩個字段。Connection 狀態中，Master 將 ConnData 通過 Connection 命令幀發送給 Slave，Slave 收到后存儲這兩個值。

Connection ID 是一個 16 位的唯一標識符，在整個 FSoE 網絡中必須唯一。此后所有數據交換階段的 PDU 都將攜帶這個 ConnID，接收方通過校驗 ConnID 來確認"這個報文確實是發給我的"。FSoE Slave Address 則是在 Connection 狀態中被 Slave 接受并存儲——后續 Slave 會持續校驗收到的 ConnID 是否與自身存儲的一致。

Connection 狀態的分段傳輸最復雜：ConnData 共 4 個字節（2 字節 ConnID + 2 字節 Slave Address），如果安全數據長度不足以一次傳輸完，需要分多幀發送。每幀發送后 BytesToBeSent 遞減，直到全部 4 字節發送完畢。只有當所有 4 個字節都被正確接收、安全數據回顯校驗通過（IS_SAFEDATA_CORRECT）、CRC 校驗通過，且 Frame.ConnId 與配置的 ConnData.ConnId 一致時，Master 才轉入 Parameter 狀態。

Slave 在 Connection 狀態中的行為有一個關鍵的安全設計：它會將收到的 ConnData 中的 Slave Address 與自身的撥碼開關或配置值進行比對。如果地址不匹配，Slave 回應 Reset 并報告 INVALID_ADDRESS 錯誤——這攔截了組態配置中的尋址錯誤。

Parameter 狀態：協商安全參數，確認能力匹配

Parameter 狀態是進入正常數據交換前的最后一道關卡，負責協商通信雙方的安全運行參數。

SafePara 包含兩類參數。第一類是安全通信參數，核心是 FSoE 看門狗時間（Watchdog Time）——它決定了通信丟失后多長時間進入安全狀態。看門狗時間在 1-65535 ms 范圍內可配，必須同時在 Master 和 Slave 側匹配。第二類是安全應用參數，與應用相關，例如安全數據的長度、安全功能的具體配置等。

Parameter 狀態的傳輸有一個顯著特點：參數數據可能非常大。與 Session ID 僅 2 字節、ConnData 僅 4 字節不同，SafePara 可能包含數十甚至上百字節的安全應用參數。因此 Parameter 狀態的分段傳輸可能跨越多個 FSoE 周期。規范使用 BytesToBeSent 變量和 UPDATE_BYTES_TO_BE_SENT 宏來精確跟蹤剩余待傳輸的字節數。

每收到一個 Parameter 幀，Slave 不僅校驗 CRC 和 ConnID，還會調用 IS_SAFE_PARA_CORRECT 宏逐條檢查參數的有效性——通信參數長度是否正確、參數值是否在合法范圍內、應用參數是否與設備能力匹配。任何一條檢查失敗，Slave 都會報告 INVALID_DATA 或 FAULTY_SAFE_PARA 錯誤并回到 Reset 狀態。

參數協商成功后（PARA_OK），Master 發送第一個 Data 命令幀。初始的 DataCommand 為 FailSafeData——意味著即使進入了 Data 狀態，安全輸出最初仍然是關閉的，需要應用層通過 Set Data Command 事件主動切換為 ProcessData 才能真正激活安全輸出。這種"進入 Data 但仍先保持安全輸出關閉"的設計確保應用層有足夠的初始化時間。

Data 狀態：安全數據的"生命線"

Data 狀態是 FSoE 運行時間最長的狀態——一旦建立，Stay 在這里，直到通信出錯或主動復位。

Data 狀態的核心循環非常簡潔：Master 發送攜帶 SafeOutputs 的 ProcessData（或 FailSafeData）命令幀，Slave 接收到后提取安全輸出數據、執行本地安全動作、將 SafeInputs 打包進 ProcessData（或 FailSafeData）命令幀回傳給 Master。每個周期中，CRC 繼承鏈、序列號遞增和看門狗重置同步進行。

Data 狀態有兩個子模式：ProcessData（正常模式）和 FailSafeData（故障安全模式）。兩者在 PDU 格式上完全一致，區別僅在于 Command 字節——0x36 對 0x08——以及 SafeData 的值。在 FailSafeData 模式下，安全數據被強制設為全零（FS_VALUE），無論應用層請求是什么。Master 和 Slave 都可以通過 Set Data Command 事件在兩種模式之間切換，且對方的回應模式不影響己方的發送模式——Slave 發送 FailSafeData 并不意味著 Slave 要求 Master 也發送 FailSafeData，反之亦然。

ETG.5100 規范對 Data 狀態下的 CRC 校驗有額外的嚴格約束。如果 CRC 校驗失敗，即使 ConnID 匹配，接收方也立即進入 Reset 狀態并報告 INVALID_CRC。序列號（虛擬的，不出現在 PDU 中但納入了 CRC 計算）的不連續同樣會被 CRC 校驗捕獲——因為接收方維護自己的 MasterSeqNo/SlaveSeqNo 預期值，任何跳變都會導致 CRC 不匹配。

看門狗在 Data 狀態下的角色尤為關鍵。每一個接收到的有效 ProcessData 或 FailSafeData 幀都會重置看門狗定時器——但無效幀（CRC 錯誤、ConnID 不匹配）不會。這意味著即使通信鏈路沒有完全中斷，持續收到損壞的報文同樣會導致看門狗超時，觸發進入 Reset 狀態。

Master 與 Slave 狀態機的異同

Master 和 Slave 的狀態機在整體結構上高度對稱——五個狀態完全相同，轉換觸發條件也基本對應。ETG.5100 規范分別以 Figure 7 和 Figure 8 給出了兩者的狀態圖。

▲ ETG.5100 Figure 7 – FSoE Master 狀態機。與 Slave（Figure 8）相比，兩者狀態相同但發起權和錯誤回歸路徑存在關鍵差異。

發起權的不對稱。Reset → Session 的躍遷只能由 Master 發起（通過生成 Session ID 并發送 Session 幀）。Slave 在 Reset 狀態下只能被動的響應 Reset 幀，然后等待 Master 發起 Session。這種不對稱反映了 FSoE 的 Master-Slave 體系結構：Master 是通信的管理者，Slave 是響應者。

失敗后的回歸路徑不同。當 Master 在 Session、Connection、Parameter 或 Data 狀態檢測到錯誤時，它會回到 Reset 狀態，然后立即重新生成 Session ID 并發起 Session 幀——即自動嘗試重建連接。而當 Slave 在這些狀態檢測到錯誤時，它回到 Reset 狀態后只是等待。這種差異意味著 Slave 永遠不會"主動出擊"——只有 Master 有重建連接的決定權。

Data 狀態下的自主安全響應。在 Data 狀態下，Slave 的自主性體現在錯誤響應上——如果 Slave 的看門狗超時（DATA_WD），它獨立進入 Reset 狀態并停止所有安全輸出，不依賴 Master 的任何指令。這是黑色通道原理在狀態機層面的核心體現：Slave 不需要知道"通信為什么斷了"，它只需要知道"通信斷了"，然后自行進入安全狀態。

總結：狀態機——安全通信的"憲法"

FSoE 的狀態機不只是五個狀態的簡單切換，它是一部精確到每個事件、每個條件、每個動作的安全通信"憲法"。從 Reset 的全變量清零，到 Session 的隨機數種子，到 Connection 的身份綁定，到 Parameter 的能力協商，再到 Data 的持續監控——每一步都在為最終的 SIL3 安全等級添磚加瓦。

將狀態機與前面四篇文章的知識串聯起來，整體圖景已經非常清晰：黑色通道原理定義了"底層不可信"的前提（第一篇），四道安全防線在邏輯上部署了防御體系（第二篇），多 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