這篇部落格文章最初發表於 cimetrix.com
通訊協定層的目的
通訊協定層負責封裝資料，並在工廠主機與設備的 GEM 介面之間進行可靠的資料傳輸。
通訊協定層定義
通訊協定層負責實作用於在工廠主機與設備 GEM 介面之間，透過線路傳送訊息所需的傳輸技術與資料封裝演算法。
SEMI E5 標準（即 SEMI 設備通訊標準 2 訊息內容，SECS-II）定義了用作資料的 SECS 訊息，並規定了這些訊息如何被封裝到二進位緩衝區中以供傳輸。
SEMI E37 和 E37.1 標準《高速 SECS 訊息服務》（HSMS）定義了一種透過 TCP/IP 連線交換 SECS 訊息的通訊協定。這是 SECS/GEM 中最常使用的傳輸技術。
HSMS 通訊協定堆疊
SEMI E4 標準（SEMI 設備通訊標準 1：訊息傳輸，SECS-I）定義了一種透過 RS-232 交換 SECS 訊息的機制。此機制通常用於較舊的設備，或設備內的某些硬體，例如 EFEM 控制器。
本文其餘部分將聚焦於透過 HSMS 傳輸的 SECS 訊息。
通訊協定層的優勢
GEM 中的協定層負責維持連線，並偵測連線中斷的情況，以便任一方都能採取適當措施，例如啟用緩衝傳輸。
通訊協定層定義了握手機制，以確保在需要時能順利傳遞訊息。
協定層的連線是工廠主機與設備之間的點對點連線。這是一條專用連線，不具備廣播功能。這使得網路負載更易於預測。
資料密度
SECS/GEM 能以極低的開銷和高密度傳輸資料。這意味著針對特定資料集，所需的網路頻寬較少。
為便於說明，讓我們來看看一份事件報告的典型範例，並將 SECS/GEM 訊息與某種程度相當的 XML 及 JSON 訊息進行比較。
以一個典型的 GEM 介面為例，該介面使用 4 位元組的無符號整數作為 ID，且其事件報告包含 8 位元組的浮點數與 4 位元組的整數。下表列出了此訊息的範例，格式依循 E5 規範的 SECS/GEM 格式，以及等效的 JSON 和 XML 格式。
SECS/GEM 二進位訊息在傳輸時佔用 58 位元組，JSON 約佔 206 位元組，XML 則為 175 位元組。JSON 和 XML 的位元組數可能會因金鑰／元素名稱而略有變化，上述僅為眾多可能表示形式之一。
下圖顯示了該範例訊息的資料密度比較。實際資料大小為 2 個 4 位元組整數 + 2 個 8 位元組浮點數 + 1 個 4 位元組事件 ID + 1 個 4 位元組報告 ID = 32 位元組的實際資料。開銷是透過從訊息的總位元組數中減去實際資料大小來計算的。
以下圖表顯示了範例訊息中 SECS 的資料密度百分比。資料密度百分比的計算方式為（實際資料）÷ 開銷 × 100。
現在，如果我們將範例訊息修改為包含 100 個 8 位元組的浮點數，則「資料密度 %」圖表會變成下圖所示的樣子。請注意，JSON 和 XML 的資料密度相對相似，但 SECS/GEM 的資料密度則上升至 78%。
SECS/GEM 編碼的開銷極小。每則訊息的開銷包含 10 位元組用於描述該訊息的標頭，以及 1 至 4 位元組用於表示訊息本體的大小。對於 SECS 訊息中的任何 4 位元組整數或浮點數，傳輸時將傳送 6 位元組：其中 4 位元組為整數值，1 位元組為資料類型，另 1 位元組為資料長度（以位元組為單位）。 同樣地，對於任何 8 位元組的整數或浮點數，將傳送 10 位元組。若為字串值，其長度則為字元數加上 2 至 4 位元組。每當 SECS 訊息中出現清單（如上文可讀範例中的 L）時，訊息長度將增加 2 至 4 位元組。
在 SECS/GEM 中，數字陣列的效率極高。陣列的開銷包含 1 位元組的資料型別空間，加上 1 至 4 位元組的陣列長度空間，以及資料本身的原始大小。舉例來說：一個由 10 個 4 位元組整數組成的陣列，總共會佔用 42 位元組，資料密度高達 95%！
在 JSON 範例中，一個 4 位元組的整數需要 16 位元組，再加上表示該整數所需的字元數，因此總共需要 17 至 28 位元組。浮點數的開銷與此相同，但表示該數值可能需要更多的字元。
在 XML 中，傳輸開銷取決於 XML 元素名稱的大小。以上述範例中的元素名稱為例，對於任何 4 位元組的整數，實際傳輸的位元組數將為 9 加上表示該整數所需的字元數，因此範圍在 10 至 21 位元組之間。至於浮點數，則取決於用來表示該數值的字串格式。
總而言之，若觀察傳輸過程中每個項目的位元組大小，SECS/GEM 的傳輸密度極高。以 4 位元組整數為例：SECS/GEM 的傳輸大小為 6 位元組，JSON 範例為 17 至 28 位元組，而 XML 範例則為 10 至 21 位元組；由此可見，隨著參數數量增加，傳輸開銷將變得至關重要。 預計 300mm 半導體設備每秒需將 1000 個參數從每個製程模組傳輸至主機。以 2 模組的設備為例，僅數據部分的位元組數量如下：SECS/GEM 為 12K 位元組，JSON 為 34K 至 56K 位元組，XML 範例則為 20K 至 42K 位元組。 這些數字尚未計入訊息中其他部分的大小，僅針對與參數值相關的實際部分。若將這些資料分散在大量訊息中傳輸，且每則訊息僅包含少量參數值，則網路負載將更加嚴峻。在任何情況下，傳輸較少但體積較大的訊息總是更為理想。
根據所使用的傳輸協定不同，XML 和 JSON 也可能增加額外的開銷。例如，XML 通常是透過 SOAP 經由 HTTP 傳輸，這會增加兩層額外的開銷，且每則訊息在網路傳輸時會多出更多位元組。SECS/GEM 所顯示的位元組數，是指在 TCP/IP 之上實際透過網路傳輸的資料量。
無資料轉換
在 SECS/GEM 中，數值資料的傳輸不進行任何轉換。數字均以原始格式傳輸。例如：一個 8 位元組的浮點數，將以 8 位元組的原始表示形式傳輸，不會進行任何轉換、截斷或四捨五入。
任何通訊協定（例如 JSON 或 XML）都必須將這些 8 位元組的浮點數轉換為文字表示形式。 這不僅需要運算資源進行編碼與解碼，更會在傳輸過程中佔用顯著更多的位元組。根據 IEEE 754 標準，要將一個 8 位元組的浮點數精確地以字串形式表示，需使用 17 個十進位位元。若再加上正負號、小數點、指數及指數正負號等字元，總計需 21 個字元。這比 SECS/GEM 透過網路傳輸的位元組數還多出兩倍以上。
電路保障
HSMS 定義了一種稱為「鏈路測試」（Link Test）的迴路保障機制。協定層設有計時器，當沒有任何活躍的訊息交換時，該計時器便會啟動。每當計時器超時，系統便會交換一則協定訊息，以確保連線仍然保持開啟狀態。
安全
HSMS 並未定義任何安全性。系統不會驗證連線方身分，連線時亦無需提供憑證或證書。資料並未透過任何常規加密演算法進行加密；然而，資料會透過資料封裝流程進行混淆處理，一般而言無法被人類閱讀。
由於工廠網路與外界隔絕，因此安全性通常不會被視為問題。
結論
採用 HSMS 的 SECS/GEM 協定層，為工廠主機與設備之間交換精確資料提供了極為高效的途徑。